2002-09-09 18:31:05

by Frederik Himpe

[permalink] [raw]
Subject: 2.4.19: Oops, probably related to SCSI?

Hi,

I have an Agfa SnapScan 1236s connected to an Adaptec AVA-1505AE ISA
SCSI card (using the aha150x driver). When I try to scan something with
xsane, the kernel (Linux 2.4.19 with XFS patches) oopses.

I have analysed the oops with ksymoops. Here is the output:

ksymoops 2.4.5 on i686 2.4.19-xfs. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.19-xfs/ (default)
-m /boot/System.map-2.4.19-xfs (default)

Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.

Sep 9 18:41:57 Jupiter kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000001b
Sep 9 18:41:57 Jupiter kernel: d08f22a0
Sep 9 18:41:57 Jupiter kernel: *pde = 00000000
Sep 9 18:41:57 Jupiter kernel: Oops: 0000
Sep 9 18:41:57 Jupiter kernel: CPU: 0
Sep 9 18:41:57 Jupiter kernel: EIP:
0010:[keybdev:__insmod_keybdev_O/lib/modules/2.4.19-xfs/kernel/drivers/in+-1678688/96] Not tainted
Sep 9 18:41:57 Jupiter kernel: EIP: 0010:[<d08f22a0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Sep 9 18:41:57 Jupiter kernel: EFLAGS: 00010002
Sep 9 18:41:57 Jupiter kernel: eax: 00000000 ebx: c5ca3000 ecx:
cec32000 edx: c5528500
Sep 9 18:41:57 Jupiter kernel: esi: cf6df400 edi: 00000004 ebp:
c5d83d88 esp: c5d83d6c
Sep 9 18:41:57 Jupiter kernel: ds: 0018 es: 0018 ss: 0018
Sep 9 18:41:57 Jupiter kernel: Process xsane (pid: 2478,
stackpage=c5d83000)
Sep 9 18:41:57 Jupiter kernel: Stack: cfffc0c0 00000020 c010d098
00000297 00000293 c7f7e514 c5ca3000 c5d83da4
Sep 9 18:41:57 Jupiter kernel: d08f23c0 c5ca3000 00000000
00000000 00000000 d08d9f70 c5d83de0 d08d9684
Sep 9 18:41:57 Jupiter kernel: c5ca3000 d08d9f70 d08de760
00000004 c7f7e576 c7f7e4c0 c7f7e514 cf8971a0
Sep 9 18:41:57 Jupiter kernel: Call Trace: [IRQ0x7c_interrupt+8/16]
[keybdev:__insmod_keybdev_O/lib/modules/2.4.19-xfs/kernel/drivers/in+-1678400/96] [keybdev:__insmod_keybdev_O/lib/modules/2.4.19-xfs/kernel/drivers/in+-1777808/96] [keybdev:__insmod_keybdev_O/lib/modules/2.4.19-xfs/kernel/drivers/in+-1780092/96] [keybdev:__insmod_keybdev_O/lib/modules/2.4.19-xfs/kernel/drivers/in+-1777808/96]
Sep 9 18:41:57 Jupiter kernel: Call Trace: [<c010d098>] [<d08f23c0>]
[<d08d9f70>] [<d08d9684>] [<d08d9f70>]
Sep 9 18:41:57 Jupiter kernel: [<d08de760>] [<d08e22ce>] [<d23e9628>]
[<d08e1765>] [<d08e17f9>] [<d08d9a7a>]
Sep 9 18:41:57 Jupiter kernel: [<d23ea2e0>] [<d23e90b2>] [<d23ea2e0>]
[<d23e8df3>] [<d23e8bd7>] [<c013ce3c>]
Sep 9 18:41:57 Jupiter kernel: [<c0109307>]
Sep 9 18:41:57 Jupiter kernel: Code: 0f b6 50 1b 8b 14 95 d8 b5 30 c0
2b 82 9c 00 00 00 c1 f8 02


>>EIP; d08f22a0 <[scsi_mod].bss.end+251d/b2dd> <=====

>>ebx; c5ca3000 <_end+597013c/1059d19c>
>>ecx; cec32000 <_end+e8ff13c/1059d19c>
>>edx; c5528500 <_end+51f563c/1059d19c>
>>esi; cf6df400 <_end+f3ac53c/1059d19c>
>>ebp; c5d83d88 <_end+5a50ec4/1059d19c>
>>esp; c5d83d6c <_end+5a50ea8/1059d19c>

Trace; c010d098 <call_do_IRQ+5/d>
Trace; d08f23c0 <[scsi_mod].bss.end+263d/b2dd>
Trace; d08d9f70 <[scsi_mod]scsi_done+0/d0>
Trace; d08d9684 <[scsi_mod]scsi_dispatch_cmd+124/390>
Trace; d08d9f70 <[scsi_mod]scsi_done+0/d0>
Trace; d08de760 <[scsi_mod]scsi_times_out+0/d0>
Trace; d08e22ce <[scsi_mod]scsi_request_fn+18e/310>
Trace; d23e9628 <[sg]sg_ioctl+4e8/c60>
Trace; d08e1765 <[scsi_mod]__scsi_insert_special+55/80>
Trace; d08e17f9 <[scsi_mod]scsi_insert_special_req+29/30>
Trace; d08d9a7a <[scsi_mod]scsi_do_req+da/1c0>
Trace; d23ea2e0 <[sg]sg_cmd_done_bh+0/370>
Trace; d23e90b2 <[sg]sg_common_write+202/290>
Trace; d23ea2e0 <[sg]sg_cmd_done_bh+0/370>
Trace; d23e8df3 <[sg]sg_new_write+1c3/280>
Trace; d23e8bd7 <[sg]sg_write+2f7/350>
Trace; c013ce3c <sys_write+9c/130>
Trace; c0109307 <system_call+33/38>

Code; d08f22a0 <[scsi_mod].bss.end+251d/b2dd>
00000000 <_EIP>:
Code; d08f22a0 <[scsi_mod].bss.end+251d/b2dd> <=====
0: 0f b6 50 1b movzbl 0x1b(%eax),%edx <=====
Code; d08f22a4 <[scsi_mod].bss.end+2521/b2dd>
4: 8b 14 95 d8 b5 30 c0 mov 0xc030b5d8(,%edx,4),%edx
Code; d08f22ab <[scsi_mod].bss.end+2528/b2dd>
b: 2b 82 9c 00 00 00 sub 0x9c(%edx),%eax
Code; d08f22b1 <[scsi_mod].bss.end+252e/b2dd>
11: c1 f8 02 sar $0x2,%eax


1 warning issued. Results may not be reliable.


2002-09-10 15:02:58

by Frederik Himpe

[permalink] [raw]
Subject: Re: 2.4.19: Oops -> problem with aha152x driver

On Mon, 2002-09-09 at 20:35, Frederik Himpe wrote:
<snip kernel oops with aha152x driver for Adaptec AVA-1505AE ISA card)

Sorry, the oops I sent was not complete, here is a complete one. It
seems that the aha152x driver is the problem. If I compile the aha152x
module from 2.4.18, I don't get the oops.

ksymoops 2.4.5 on i686 2.4.19-xfs. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.19-xfs/ (default)
-m /boot/System.map-2.4.19-xfs (default)

Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.

cpu: 0, clocks: 1002236, slice: 501118
SGI XFS snapshot 2.4.19-2002-08-03_04:15_UTC with ACLs, realtime, quota, no debug enabled
Unable to handle kernel NULL pointer dereference at virtual address 0000001b
d08f22a0
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<d08f22a0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000000 ebx: c5db5000 ecx: cedb8000 edx: c5a0caa0
esi: cf6e0400 edi: 00000004 ebp: c5c65d88 esp: c5c65d6c
ds: 0018 es: 0018 ss: 0018
Process xsane (pid: 2196, stackpage=c5c65000)
Stack: cfffc0c0 00000020 c010d098 00000297 00000293 c12e0ab4 c5db5000 c5c65da4
d08f23c0 c5db5000 00000000 00000000 00000000 d08d9f70 c5c65de0 d08d9684
c5db5000 d08d9f70 d08de760 00000004 c12e0b16 c12e0a60 c12e0ab4 ceba4ca0
Call Trace: [<c010d098>] [<d08f23c0>] [<d08d9f70>] [<d08d9684>] [<d08d9f70>]
[<d08de760>] [<d08e22ce>] [<d08e1765>] [<d08e17f9>] [<d08d9a7a>] [<d23ea2e0>]
[<d23e90b2>] [<d23ea2e0>] [<d23e8df3>] [<d23e8bd7>] [<c013ce3c>] [<c0109307>]
Code: 0f b6 50 1b 8b 14 95 d8 b5 30 c0 2b 82 9c 00 00 00 c1 f8 02


>>EIP; d08f22a0 <[aha152x]aha152x_internal_queue+100/1f0> <=====

>>ebx; c5db5000 <_end+5a8213c/1059d19c>
>>ecx; cedb8000 <_end+ea8513c/1059d19c>
>>edx; c5a0caa0 <_end+56d9bdc/1059d19c>
>>esi; cf6e0400 <_end+f3ad53c/1059d19c>
>>ebp; c5c65d88 <_end+5932ec4/1059d19c>
>>esp; c5c65d6c <_end+5932ea8/1059d19c>

Trace; c010d098 <call_do_IRQ+5/d>
Trace; d08f23c0 <[aha152x]aha152x_queue+30/40>
Trace; d08d9f70 <[scsi_mod]scsi_done+0/d0>
Trace; d08d9684 <[scsi_mod]scsi_dispatch_cmd+124/390>
Trace; d08d9f70 <[scsi_mod]scsi_done+0/d0>
Trace; d08de760 <[scsi_mod]scsi_times_out+0/d0>
Trace; d08e22ce <[scsi_mod]scsi_request_fn+18e/310>
Trace; d08e1765 <[scsi_mod]__scsi_insert_special+55/80>
Trace; d08e17f9 <[scsi_mod]scsi_insert_special_req+29/30>
Trace; d08d9a7a <[scsi_mod]scsi_do_req+da/1c0>
Trace; d23ea2e0 <[sg]sg_cmd_done_bh+0/370>
Trace; d23e90b2 <[sg]sg_common_write+202/290>
Trace; d23ea2e0 <[sg]sg_cmd_done_bh+0/370>
Trace; d23e8df3 <[sg]sg_new_write+1c3/280>
Trace; d23e8bd7 <[sg]sg_write+2f7/350>
Trace; c013ce3c <sys_write+9c/130>
Trace; c0109307 <system_call+33/38>

Code; d08f22a0 <[aha152x]aha152x_internal_queue+100/1f0>
00000000 <_EIP>:
Code; d08f22a0 <[aha152x]aha152x_internal_queue+100/1f0> <=====
0: 0f b6 50 1b movzbl 0x1b(%eax),%edx <=====
Code; d08f22a4 <[aha152x]aha152x_internal_queue+104/1f0>
4: 8b 14 95 d8 b5 30 c0 mov 0xc030b5d8(,%edx,4),%edx
Code; d08f22ab <[aha152x]aha152x_internal_queue+10b/1f0>
b: 2b 82 9c 00 00 00 sub 0x9c(%edx),%eax
Code; d08f22b1 <[aha152x]aha152x_internal_queue+111/1f0>
11: c1 f8 02 sar $0x2,%eax


1 warning issued. Results may not be reliable.


2002-09-10 17:19:33

by Juergen E. Fischer

[permalink] [raw]
Subject: Re: 2.4.19: Oops -> problem with aha152x driver

Hi Frederik,

On Tue, Sep 10, 2002 at 17:07:35 +0200, Frederik Himpe wrote:
> Sorry, the oops I sent was not complete, here is a complete one. It
> seems that the aha152x driver is the problem. If I compile the aha152x
> module from 2.4.18, I don't get the oops.

Upgrade to 2.4.20pre5 or above.


J?rgen

--
"I hear that if you play the NT 4.0 CD backwards, you get a satanic message".
"That's nothing. If you play it forward, it installs NT 4.0!"
-- unknown