lkml.org 
[lkml]   [1999]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPROBLEM: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.074 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site