[667] in linux-scsi channel archive
53c810 hangs kernel
daemon@ATHENA.MIT.EDU (Brettski)
Sat Oct 7 09:24:32 1995
Date: Sat, 7 Oct 1995 19:49:31 +1000 (EST)
From: Brettski <n1135350@student.fit.qut.edu.au>
To: linux-scsi@vger.rutgers.edu
cc: linux-kernel@vger.rutgers.edu, drew@colorado.edu
I've been playing with this one for about a week, now, and I'm rather
sick of it.
I've recently made some hardware upgrades, including an ASUSTek
PVI-486SP3 motherboard(SiS chipset) and ASUSTek PCI-SC200 SCSI controller
(NCR53c810 based) and a 1Gb Quantum Fireball 1080S Hard disk drive, and I
wasn't very impressed when DOS would run the drive fine, but my beloved
Linux just decided to hang itself whenever I tried to do anything with
the new drive.
The faults are erratic - ie. it doesn't always fail the same way -
especially when you want to test something, or demonstrate the fault.
The most informative one is a Kernel Panic. Originally I tried stock
1.2.13 and 1.3.29 kernels which would give me (when it wanted to) :-
Kernel Panic: mail drew@Colorado.EDU
In Swapper task - not swapping
or similar. There were no register dumps, etc. At other times, when the
kernel managed to calm itself, it would jusst cause segmentation faults
in mke2fs or when I tried mounting /dev/sda2 after successfully making a
filesystem, mount became a regular file until I unmounted it!!! Go figure...
I've since applied some of the alpha patches. Release 7 (or was it 8)
made a slight improvement - ie. instead of a kernel panic, it just hung
the scsi driver. Thus, I could still change VT's and do anything, as long
as I didn't want to use the scsi drive, or the VT that hung the driver.
This also had the other faults, from time to time, as above.
Release 11 of the patch finally gave me some usefull information... I
think...
Again I got the kernel panic, but this time it came with a code dump, the
details of which are below. Note that these kernel panics do not seem to
be linked to a certain command. I've recreated the error (when it's
gracious enough to occur) using mke2fs, cp, and others. Two instances of
the panic are included
This panic occurred during a cp -a -i /usr/* . ($PWD=/mnt)
I had actually changed VTs and was in the process of logging in to see if
I could watch...
natas login: root
general protection: 0000
EIP: 0010:001aec9e
EFLAGS: 00010006
eax: 00000025 ebx: 00000000 ecx: 001c58fb edx:01dfc000
esi: c0000004 edi: 7838a800 ebp: 001f4a64 esp:001b75b8
ds: 0018 es: 0018 fs: 002b gs: 0018 ss: 0018
Process swapper (pid: 0, process nr:0, stackpage=001b5764)
Stack: 00000000 00000002 001fe800 001f3c9c 00000040 001fsc9c 001aee93 001f3c50
001f4a64 001a74c3 00000000 00000000 001fe800 001f4710 001af4e4 001f3c50
001f3c50 00000000 001a74c3 001f3c50 00000206 001f3c50 001f3c9c 0000032a
Call Trace: 001aee93 001a74c3 001af4e4 001a74c3 001ae6bb 001a08f9 0019ef94
0019ee98 001a0a62 00118708 0011eabe 001106ed 00110018 0010f8fc 00110769
0010f3bf 00117e08
Code: 0f b6 47 09 50 0f b6 47 08 50 68 e4 ea 1a 00 e8 2e b1 f6 ff
Aiee, killing interrupt handler.
kfree of non-kmalloced memory: 001b775c, next=00000000, order=0
task[0] (swapper) killed: unable to recover
Kernel Panic: Trying to free up swapper memory space
In swapper task - not syncing.
I also got the same panic when doing a mke2fs /dev/sda2. It is the same
as above, except for the following fields :-
edx: 01dfe000 ( Not sure - may have copied the first one down wrong, though)
ebp: 0008e084
esp: (This was different, too, of course, but I forgot to write it down )
Stack: 00000000 00000006 0000e800 001f3c9c 00000040 001f3c9c 001aee93 001f3c50
008e084?? 001a74c3 00000000 00000000 0000e800 001f4fcc 001af4e4 001f3c50
001f3c50 001f4b7c 001a74c3 001f3c9c 001f49fc 00000000 fafff000?? 0000032a
Call Trace: 001aee93 001a74c3 001af4e4 001a74c3 001ad467 001acf89 001acf11
001acd53 001acf11 00170203 0017e800 001abf47 00170d01 001ac78e 00170f01
0017e80c 0017e800 00112d4b 0011275f 001b0018 0010f8fc 00110769 0010f3bf
00117e08
Apologies for the Stack - I wrote it pretty fast, and I'm not sure if I
can read it back... The rest of the message was exactly the same.
I checked up in the System.map file for that EIP value. I meant to paste
in an excerpt - but I've since recompiled 1.3.31 since then, and don't
have the System.map. The EIP value was in the function print_dsa, though.
I still have the compressed kernel image. nm doesn't work on compressed
images, but if anyone can tell me how to get the namelist from the
compressed image, I'll be happy to provide a section of it.
I've also managed to get the following fault when doing cp -a -i /usr/* .
as above :-
cp:/usr/X11R6/lib/fonts/100dpi/lubI18.pcf.Z:I/O Error
cp:/usr/X11R6/lib/fonts/100dpi/lubI24.pcf.Z:unknown file type
