Hello,
I'm running 2.4.2 with KDB patch on an SMP system. I have an Adaptec
2940 SCSI card that my CD burner is connected to. When this happened, I
was not using the CD at all. This is on a Tyan Tiger 133 motherboard
(with the Via Apollo Pro 133a chipset). I'm running with "noapic" due
to the Via PCI IRQ routing problem, so that I can use USB devices.
I'm not very good with debuggers or hunting down kernel bugs, so I
apologize in advance. Here's what I found:
Stack traceback for pid 448
EBP EIP Function(args)
0xe68f1f6c 0xc011524a schedule+0x41e (0xe76021c0, 0xe68f0000)
kernel .text 0xc0100000 0xc0114e2c 0xc0115460
0xe68f1f9c 0xc0107bb8 __down_interruptible+0x94
kernel .text 0xc0100000 0xc0107b24 0xc0107c24
0xe68f1fac 0xc0107c96 __down_failed_interruptible+0xa (0x100, 0xe694dd14, 0xe694dd6c, 0xe68f1fd8, 0x0)
kernel .text 0xc0100000 0xc0107c8c 0xc0107c9c
0xe8f4edbf [scsi_mod].text.lock+0x1fb
scsi_mod .text.lock 0xe8f4ebc4 0xe8f4ebc4 0xe8f4eee8
0xe68f1fec 0xe8f4a2bf [scsi_mod]scsi_error_handler+0x107
scsi_mod .text 0xe8f45060 0xe8f4a1b8 0xe8f4a330
0xc0107547 kernel_thread+0x23
kernel .text 0xc0100000 0xc0107524 0xc010755c
[0]kdb> id 0xe8f4eba0
0xe8f4eba0 scan_scsis_single+0x594cmp $0x1,%dl
0xe8f4eba3 scan_scsis_single+0x597jne 0xe8f4ebaf scan_scsis_single+0x5a3
0xe8f4eba5 scan_scsis_single+0x599testb $0xf,0x3(%eax)
0xe8f4eba9 scan_scsis_single+0x59dje 0xe8f4e6f5 scan_scsis_single+0xe9
0xe8f4ebaf scan_scsis_single+0x5a3mov $0x1,%eax
0xe8f4ebb4 scan_scsis_single+0x5a8lea 0xffffff68(%ebp),%esp
0xe8f4ebba scan_scsis_single+0x5aepop %ebx
0xe8f4ebbb scan_scsis_single+0x5afpop %esi
0xe8f4ebbc scan_scsis_single+0x5b0pop %edi
0xe8f4ebbd scan_scsis_single+0x5b1mov %ebp,%esp
0xe8f4ebbf scan_scsis_single+0x5b3pop %ebp
0xe8f4ebc0 scan_scsis_single+0x5b4ret
0xe8f4ebc1 scan_scsis_single+0x5b5nop
0xe8f4ebc2 scan_scsis_single+0x5b6nop
0xe8f4ebc3 scan_scsis_single+0x5b7nop
0xe8f4ebc4 .text.lockcall 0xc0107cac __up_wakeup
[0]kdb> id 0xe8f4ebb0
0xe8f4ebb0 scan_scsis_single+0x5a4add %eax,(%eax)
0xe8f4ebb2 scan_scsis_single+0x5a6add %al,(%eax)
0xe8f4ebb4 scan_scsis_single+0x5a8lea 0xffffff68(%ebp),%esp
0xe8f4ebba scan_scsis_single+0x5aepop %ebx
0xe8f4ebbb scan_scsis_single+0x5afpop %esi
0xe8f4ebbc scan_scsis_single+0x5b0pop %edi
0xe8f4ebbd scan_scsis_single+0x5b1mov %ebp,%esp
0xe8f4ebbf scan_scsis_single+0x5b3pop %ebp
0xe8f4ebc0 scan_scsis_single+0x5b4ret
0xe8f4ebc1 scan_scsis_single+0x5b5nop
0xe8f4ebc2 scan_scsis_single+0x5b6nop
0xe8f4ebc3 scan_scsis_single+0x5b7nop
0xe8f4ebc4 .text.lockcall 0xc0107cac __up_wakeup
0xe8f4ebc9 .text.lock+0x5jmp 0xe8f450ae scsi_wait_done+0x22
0xe8f4ebce .text.lock+0xacmpb $0x0,0xe8f58af4
0xe8f4ebd5 .text.lock+0x11repz nop
[0]kdb> id 0xe8f4edbf
0xe8f4edbf .text.lock+0x1fbjmp 0xe8f4a2bf scsi_error_handler+0x107
0xe8f4edc4 .text.lock+0x200call 0xc0107cac __up_wakeup
0xe8f4edc9 .text.lock+0x205jmp 0xe8f4a320 scsi_error_handler+0x168
0xe8f4edce .text.lock+0x20acmpb $0x0,0xc027d140
0xe8f4edd5 .text.lock+0x211repz nop
0xe8f4edd7 .text.lock+0x213jle 0xe8f4edce .text.lock+0x20a
0xe8f4edd9 .text.lock+0x215jmp 0xe8f4a33b scsi_old_times_out+0xb
0xe8f4edde .text.lock+0x21acmpb $0x0,0xc027d140
0xe8f4ede5 .text.lock+0x221repz nop
0xe8f4ede7 .text.lock+0x223jle 0xe8f4edde .text.lock+0x21a
0xe8f4ede9 .text.lock+0x225jmp 0xe8f4a4d1 scsi_old_times_out+0x1a1
0xe8f4edee .text.lock+0x22acmpb $0x0,0xc027d140
0xe8f4edf5 .text.lock+0x231repz nop
0xe8f4edf7 .text.lock+0x233jle 0xe8f4edee .text.lock+0x22a
0xe8f4edf9 .text.lock+0x235jmp 0xe8f4aa71 scsi_old_done+0x501
0xe8f4edfe .text.lock+0x23acmpb $0x0,0xc027d140
Is this a known problem that's been fixed in the AC or test line? Is
there any more information I can provide about my system? Any tips on
better information to grab next time something like this happens?
Thanks,
pete
This archive was generated by hypermail 2b29 : Sat Mar 10 2001 - 20:18:30 EST