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