Re: [FWD] SCSI error handling bug in 2.3.36pre3?

Simon Kirby (sim@stormix.com)
Sun, 2 Jan 2000 11:10:52 -0800


On Sun, Jan 02, 2000 at 01:43:31PM -0500, Eric Youngdale wrote:

> [Doug, Simon]:
> The stack trace you sent me doesn't make sense. A lot of the
> functions that appear there don't call the next function on the chain, but
> some of the offsets are quite large which would suggest that the functions
> aren't the right ones.

Aha, it wasn't reading my current System.map for some reason (grumble,
older versions did). Here is a trace that makes more sense (except for
the current EIP, I guess, as it was produced from the NMI oopser):

NMI Watchdog detected LOCKUP on CPU0, registers:
CPU: 0
EIP: 0010:[<c0245bbd>]
EFLAGS: 00000002
eax: 00000000 ebx: c0329b44 ecx: ffffff1a edx: c02aac88
esi: c7dafa64 edi: c7fab000 ebp: c6d0dcf4 esp: c6d0dcb8
ds: 0018 es: 0018 ss: 0018
Process w (pid: 9013, stackpage=c6d0d000)
Stack: 00000282 00000082 c7fab000 c7dafa40 c6d0dcec 000003e8 00000005 c0329b44
00000000 00000282 c4babe00 c6d0dcec 00005401 0000001e 00000001 c4babe00
c02127c1 c7dafa40 00000000 00000000 c4babc98 c7dafa64 00000282 c7fab000
Call Trace: [<c02127c1>] [<c0211efa>] [<c020a8f1>] [<c020d6db>] [<c020d574>] [<c020dfa8>] [<c0158e56>]
[<c0212889>] [<c01d4795>] [<c013c8e2>] [<c0159b36>] [<c0159d0f>] [<c0147c23>] [<c0147e78>] [<c0147f3e>]
[<c0144089>] [<c010bf54>]
Code: 75 f7 e9 4a 41 fc ff f6 03 01 75 fb e9 60 42 fc ff f6 05 70

>>EIP; c0245bbd <stext_lock+4605/6ca4> <=====
Trace; c02127c1 <scsi_request_fn+115/36c>
Trace; c0211efa <scsi_insert_special_cmd+ae/104>
Trace; c020a8f1 <scsi_do_cmd+165/190>
Trace; c020d6db <ioctl_internal_command+10f/2f0>
Trace; c020d574 <scsi_ioctl_done+0/58>
Trace; c020dfa8 <scsi_ioctl+2c0/3c0>
Trace; c0158e56 <ext2_getblk+66/d8>
Trace; c0212889 <scsi_request_fn+1dd/36c>
Trace; c01d4795 <unplug_device+61/b4>
Trace; c013c8e2 <__wait_on_buffer+26e/37c>
Trace; c0159b36 <ext2_find_entry+14e/2f0>
Trace; c0159d0f <ext2_lookup+37/90>
Trace; c0147c23 <real_lookup+8b/14c>
Trace; c0147e78 <lookup_dentry+10c/1ac>
Trace; c0147f3e <__namei+26/88>
Trace; c0144089 <sys_newstat+65/130>
Trace; c010bf54 <system_call+34/38>
Code; c0245bbd <stext_lock+4605/6ca4>
00000000 <_EIP>:
Code; c0245bbd <stext_lock+4605/6ca4> <=====
0: 75 f7 jne fffffff9 <_EIP+0xfffffff9> c0245bb6 <stext_lock+45fe/6ca4> <=====
Code; c0245bbf <stext_lock+4607/6ca4>
2: e9 4a 41 fc ff jmp fffc4151 <_EIP+0xfffc4151> c0209d0e <scsi_allocate_device+66/584>
Code; c0245bc4 <stext_lock+460c/6ca4>
7: f6 03 01 testb $0x1,(%ebx)
Code; c0245bc7 <stext_lock+460f/6ca4>
a: 75 fb jne 7 <_EIP+0x7> c0245bc4 <stext_lock+460c/6ca4>
Code; c0245bc9 <stext_lock+4611/6ca4>
c: e9 60 42 fc ff jmp fffc4271 <_EIP+0xfffc4271> c0209e2e <scsi_allocate_device+186/584>
Code; c0245bce <stext_lock+4616/6ca4>
11: f6 05 70 00 00 00 00 testb $0x0,0x70

Does that make any sense? :) The offsets look smaller now, and I forced
the correct System.map.

Simon-

[ Stormix Technologies Inc. ][ NetNation Communcations Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]

-
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/