[conspire] Kernel failure

[Rick Moen]

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.