Messages in this thread | | | Date | Sun, 21 Feb 1999 20:50:45 -0500 | From | Douglas Gilbert <> | Subject | oopses in SCSI mid-level, 1 source |
| |
I was doing some stress testing on a sg driver that I'm writing and was able to oops the SCSI mid-level several times.
The oops log post-processed by ksymoops is at the bottom of this email. It seems to be coming from line 1925 of scsi.c . The function scsi_build_commandblocks() calls scsi_init_malloc() and _assumes_ it returns a valid pointer. That function calls either kmalloc() or __get_free_pages() with GFP_ATOMIC (perhaps or-ed with GFP_DMA if an ISA adapter is being used). Those calls seem a lot more likely to return 0 in 2.2 than the did in 2.0 :-( Hence the oops. It's my guess that several emails to this newsgroup reporting oopses in the scsi sub-system are related to this particular problem.
It is not clear to me what that code should do when 'SCpnt' gets 0 assigned to it. Could the queue_length be shortened to that value, perhaps panic-ing if that yields a zero queue_length? Could not the scsi_dma_pool be used? In any case, that code should change.
While on the subject of oops-es, I can get a repeatable "rock solid" oops using the following sequence of pathological code: "insmod sg; sg_close_early; rmmod sg" The 'sg_close_early' write()s off a scsi command but closes the file descriptor before the matching read(). [This roughly simulates an unexpected CTRL-C.] It is pretty obvious what is going on: the mid-level bh handler finally gets an "interrupt" and then calls sg but it's no longer there. The scsi mid-level no longer allows a high-level module (eg sg) to abort a command "in flight". What to do?
Oops printout for scsi mid-level oops follows:
Feb 21 10:48:14 frig kernel: Detected scsi CD-ROM sr0 at scsi1, channel 0, id 4, lun 0 Feb 21 10:48:15 frig kernel: Detected scsi generic sge at scsi1, channel 0, id 5, lun 0
Warning in compare_ksyms_lsmod, module sg is in lsmod but not in ksyms, probably no symbols exported Feb 21 10:48:15 frig kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000058 Feb 21 10:48:15 frig kernel: current->tss.cr3 = 016df000, `r3 = 016df000 Feb 21 10:48:15 frig kernel: *pde = 00000000 Feb 21 10:48:15 frig kernel: Oops: 0002 Feb 21 10:48:15 frig kernel: CPU: 0 Feb 21 10:48:15 frig kernel: EIP: 0010:[<c01bf9fb>] Feb 21 10:48:15 frig kernel: EFLAGS: 00010246 Feb 21 10:48:15 frig kernel: eax: 00000000 ebx: c0094c00 ecx: 00000005 edx: 00000000 Feb 21 10:48:15 frig kernel: esi: 00000002 edi: 00000058 ebp: c0006000 esp: c170bf14 Feb 21 10:48:15 frig kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 10:48:15 frig kernel: Process insmod (pid: 970, process nr: 67, stackpage=c170b000) Feb 21 10:48:15 frig kernel: Stack: c484addc ffffffea c484addc c01c0ef1 c0094c00 c484addc 00000000 c484804b Feb 21 10:48:15 frig kernel: c01c1014 c484addc c4848000 c48496e6 00000004 c484addc c0113693 c170a000 Feb 21 10:48:15 frig kernel: 0804e698 c4848000 bffffdc8 c1556000 c484ae68 c484ae78 00000002 c1556000 Feb 21 10:48:15 frig kernel: Call Trace: [<c484addc>] [<c484addc>] [<c01c0ef1>] [<c484addc>] [<c484804b>] [<c01c1014>] [<c484addc>] Feb 21 10:48:15 frig kernel: [<c4848000>] [<c48496e6>] [<c484addc>] [<c0113693>] [<c4848000>] [<c484ae68>] [<c484ae78>] [<c4843000>] Feb 21 10:48:15 frig kernel: [<c4848048>] [<c0107b0c>] [<c4848000>] Feb 21 10:48:15 frig kernel: Code: f3 ab 89 2a 89 5a 08 8a 43 1c 88 42 40 8a 43 1d 88 42 41 8a
>>EIP: c01bf9fb <scsi_build_commandblocks+5b/f0> Trace: c484addc <END_OF_CODE+174d4/????> Trace: c484addc <END_OF_CODE+174d4/????> Trace: c01c0ef1 <scsi_register_device_module+9d/c8> Trace: c484addc <END_OF_CODE+174d4/????> Trace: c484804b <END_OF_CODE+14743/????> Trace: c01c1014 <scsi_register_module+4c/5c> Trace: c484addc <END_OF_CODE+174d4/????> Trace: c4848000 <END_OF_CODE+146f8/????> Trace: c4848048 <END_OF_CODE+14740/????> Code: c01bf9fb <scsi_build_commandblocks+5b/f0> 00000000 <_EIP>: Code: c01bf9fb <scsi_build_commandblocks+5b/f0> 0: f3 ab repz stosl %eax,%es:(%edi) Code: c01bf9fd <scsi_build_commandblocks+5d/f0> 2: 89 2a movl %ebp,(%edx) Code: c01bf9ff <scsi_build_commandblocks+5f/f0> 4: 89 5a 08 movl %ebx,0x8(%edx) Code: c01bfa02 <scsi_build_commandblocks+62/f0> 7: 8a 43 1c movb 0x1c(%ebx),%al Code: c01bfa05 <scsi_build_commandblocks+65/f0> a: 88 42 40 movb %al,0x40(%edx) Code: c01bfa08 <scsi_build_commandblocks+68/f0> d: 8a 43 1d movb 0x1d(%ebx),%al Code: c01bfa0b <scsi_build_commandblocks+6b/f0> 10: 88 42 41 movb %al,0x41(%edx) Code: c01bfa0e <scsi_build_commandblocks+6e/f0> 13: 8a 00 movb (%eax),%al
2 warnings issued. Results may not be reliable.
------------------------------------------------------------------ Douglas Gilbert [dgilbert@interlog.com or dougg@triode.net.au] 48 Windsor Court Road Web: www.interlog.com/~dgilbert Thornhill, Ontario L3T 4Y5, Canada Tel: +1 905 771 6151
- 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/
| |