Messages in this thread | | | Date | Thu, 13 May 1999 10:44:38 -0400 (EDT) | From | Eric Benoit <> | Subject | PROBLEM: oopses w/ 2.2.x, HD iface related? |
| |
Hello all,
I wanted to make sure this was a genuine problem that continually occured before I reported it. I think at least a dozen times in the past two weeks justifies a bug report.
I've had this problem with the 2.2.x series kernels, but didn't have it with 2.1.x or 2.0.x. In fact, it's only been cropping up recently. I can recall 11 day uptimes with earlier 2.2.x releases. I've had it occur with 2.2.1, 2.2.3, 2.2.4, 2.2.5, 2.2.7 and just now, 2.2.8.
It tends to occur during disk activity, such as loading programs (loading ps caused it once), updating the locate database, and during fscks. It is most likely to occur during the latter, where I must reboot without cleaning unmounting. It'll often Oops again during the following fsck (the example I've pasted occured at this time). I can, however, reboot after the Oops and it'll continue to fsck and eventually finish, assuming it doesn't Oops again. In other words, there's really no strict pattern, except that fscks tend to trigger it the most often (because of high disk activity). The problem seems to be sporadic yet definite. Attempts to recreate it manually have been unsuccessful.
The actual Oops, while running 2.2.8:
Unable to handle kernel paging request at virtual address c023a004 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 000000e3 *pte = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c01076a0>] EFLAGS: 00010246 eax: 00000000 ebx: 00000001 ecx: c0012000 edx: c020cea0 esi: c0228000 edi: 000039bb edp: 00000e00 esp: c0229fa4 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, process nr: 0, stackpage=c0229000) Stack: c0106000 c01076c4 00000000 c0108da4 00000000 00000000 00000001 0009e200 c0106000 00000e00 00000070 00000018 00000018 00000070 c010607b 00000010 00000296 c022ac1c 00000000 c0106000 05c839bc c020eaa0 c0100176 Call trace: [<c0106000>] [<c01076c4>] [<c0108da4>] [<c0106000>] [<c010607b>] [<c0106000>] [<c0100176>] Code: f4 8b 5e 14 e8 f3 88 00 00 e8 2a 18 01 00 eb b8 b8 00 e0 ff Kernel panic: Attempted to kill the idle task! In swapper task - not syncing hda: lost interrupt
That's the typical message. Sometimes (once, at least) it'll have, instead of the first five lines (right before CPU: 0):
segment not present: 0003
So as the documentation says, I ran this through ksymoops. This is my first time using it, so I hope I got it right:
>>EIP: c01076a0 <cpu_idle+5c/6c> Trace: c0106000 <get_options+0/74> Trace: c01076c4 <sys_idle+14/24> Trace: c0108da4 <system_call+34/40> Trace: c0106000 <get_options+0/74> Trace: c010607b <cpu_idle+7/18> Trace: c0106000 <get_options+0/74> Trace: c0100176 <L6+0/2> Code: c01076a0 <cpu_idle+5c/6c> 00000000 <_EIP>: <=== Code: c01076a0 <cpu_idle+5c/6c> 0: f4 hlt <=== Code: c01076a1 <cpu_idle+5d/6c> 1: 8b 5e 14 movl 0x14(%esi),%ebx Code: c01076a4 <cpu_idle+60/6c> 4: e8 f3 88 00 00 call c010ff9c <schedule+0/280> Code: c01076a9 <cpu_idle+65/6c> 9: e8 2a 18 01 00 call c0118ed8 <check_pgt_cache+0/18> Code: c01076ae <cpu_idle+6a/6c> e: eb b8 jmp c0107668 <cpu_idle+24/6c> Code: c01076b0 <sys_idle+0/24> 10: b8 00 e0 ff 00 movl $0xffe000,%eax
The two relevant (apparently relevant) pieces of hardware involved are a Quantum Fireball SE 6.4g HD, and an EPoX 51MVP3E motherboard. I know EPoX motherboards have rather high failure rates. In fact, the one previous to this (which was replaced with this one, the same model) was causing all sorts of problems with the HD, and prevented a successful install.
If there's any more information needed to fully diagnose this problem, email me, of course. I'm hoping that this is a kernel bug that can be squished, and not some failing piece of hardware.
Thanks for your support.
--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |