[conspire] Kernel failure

[Margaret Wendall]

I just want to put in my two cents worth on this thread: at least Linux
tries to tell us what's going on when it happens in a way that we can copy
and study. I also think this feature is one reason why bugs are fixed as
fast as they usually are. Knowledge is power!

Margaret Wendall

On Sat, Oct 15, 2011 at 2:18 PM, Rick Moen <rick at linuxmafia.com> wrote:

> Now that I'm not falling over with fatigue, a little more analysis:
>
> > Pid: 2723, comm: popularity-cont Not tainted (2.6.32-5-686-bigmem #1)
> > System Product Name
> > EIP: 0060:[<c10ecadf>] EFLAGS: 00010286 CPU: 0
> > EIP is at m_stop+0xe/0x3f
> > EAX: ea52ff60 EBX: ea4ebf64 ECX: c1292404 EDX: fffffff3
> > ESI: f6946bc0 EDI: fffffff3 EBP: fffffff3 ESP: ea4ebf3c
> >  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > Process popularity-cont (pid: 2723, ti=ea4ea000 task=f6565940
> task.ti=ea4ea000)
>
> See that?  That's the running process, 'popularity-cont', AKA
> popularity-contest, which is a cronjob that sends anonymous e-mail to
> the Debian developers periodically with statistics about your most used
> Debian packages, aiding the developers make decisions about what
> packages belong on Disk 1 of the Debian CD set, and which ones should be
> installed by default.
>
> > Call Trace:
> > [<c10ce917>] ? seq_read+0x249/0x360
> > [<c10bdd9f>] ? sys_fstat64+0x1e/0x23
> > [<c110a350>] ? security_file_permission+0xc/0xd
> > [<c10ce6ce>] ? seq_read+0x0/0x360
> > [<c10bb596>] ? vfs_read+0x7b/0xd3
> > [<c10bb686>] ? sys_read+0x3c/0x63
> > [<c100821c>] ? syscall_call+0x7/0xb
>
> That's the seven most recent system calls processed by your kernel,
> latest first.  'syscall_call' is some sort of kernel call to the system
> call table.  'sys_read' is a function to read that table.  'vfs_read' is
> a read operation performed on the Linux Virtual FileSystem intermediate
> layer that is above filesystem drivers.  'seq_read' is a function that
> gives access to read elements in the /proc virtual filesystem of
> information your system maintains about itself.
> 'security_file_permissions' is a security-check function to verify
> whether the current process has authorisation to perform an intended
> read or write operation.  sys_fstat64 is a 64-bit system call to return
> file status (ID of device containing the file, inode number, protection
> mode, number of hard links, owning UID, owning GID, device ID for
> special files, total bye count, blocksize, number of blocks, atime,
> mtime, and ctime).
>
> So, no 'Ah, I see what the problem is' smoking gun.  The
> popularity-contest cronjob was just doing routine lookups of everyday
> information on your hard disk.  However, that brings me back to the
> possibility I'd initially dismissed.  Sometimes, hardware problems
> underlie and cause kernel oopses.  One might wonder if you might have a
> hardware-level problem with some area on your hard disk or with your
> mass-storage controller chip or related cabling.
>
>
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>



-- 
Margaret Wendall
mwendall-at-gmail-dot-com
"Quis custodiet ipsos custodes?" - Juvenal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20111015/c6c1fcf3/attachment.html>