Re: IDE-SCSI oops in 2.6.0-test11

ross.alexander_at_uk.neceur.com
Date: 12/03/03

  • Next message: Aron Rubin: "Re: SII 3512+Seagate on Athlon64 system"
    To: Linus Torvalds <torvalds@osdl.org>
    Date:	Wed, 3 Dec 2003 12:25:45 +0000
    
    

    Linus,

    Cool bananas. I have applied the patch and it has fixed the oops. Many
    thanks for the quick reply and patch.

    Cheers,

    Ross

    PS: How about "The Beaver has left the Priory" (or for non UK, "The Beaver
    has left the clinic").

    ---------------------------------------------------------------------------------
    Ross Alexander "We demand clearly defined
    MIS - NEC Europe Limited boundaries of uncertainty and
    Work ph: +44 20 8752 3394 doubt."

    Linus Torvalds <torvalds@osdl.org>
    02/12/2003 06:37 p.m.
     
            To: ross.alexander@uk.neceur.com
            cc: Ed Sweetman <ed.sweetman@wmich.edu>, Kernel Mailing List
    <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@suse.de>
            Subject: Re: IDE-SCSI oops in 2.6.0-test11

    On Tue, 2 Dec 2003 ross.alexander@uk.neceur.com wrote:
    >
    > I can't get the source, otherwise I would have compiled it against
    > 2.6.0. However I don't find this point particularly relevant since
    > 2.6.0 should be backward compatible with 2.4,0, atleast at the binary
    > level.
    >
    > I tried the earlier versions of dvdrtools and cdrtools and their didn't
    > like ide-cd. This version (cdrecord-dvdpro) does but it still don't
    > alter the fact that while using ide-scsi is no longer recommended, it
    > still should work.

    Well, we're trying, but nobody has had a lot of luck with it.

    However, your particular case looks pretty straightforward:

    > Here the the oops again.
    >
    > Dec 2 12:02:46 mig27 kernel: Unable to handle kernel NULL pointer
    dereference at virtual address 00000000
    > Dec 2 12:02:46 mig27 kernel: printing eip:
    > Dec 2 12:02:46 mig27 kernel: 00000000

    Somebody jumped through a NULL pointer, and it was:

    > Dec 2 12:02:46 mig27 kernel: Process cdrecord-prodvd (pid: 369,
    threadinfo=e4160000 task=f65d4100)
    > Dec 2 12:02:46 mig27 kernel: Call Trace:
    > Dec 2 12:02:46 mig27 kernel: [<f9859b1b>]
    idescsi_transfer_pc+0x11b/0x120 [ide_scsi]

    That's the code that does:

                     ...
            if (test_bit (PC_DMA_OK, &pc->flags)) {
                    set_bit (PC_DMA_IN_PROGRESS, &pc->flags);
                    (void) (HWIF(drive)->ide_dma_begin(drive));
            }
                     ...

    and it looks like the PC_DMA_OK flag is incorrect.

    Doing a bit more digging shows that "idescsi_issue_pc()" seems to use some
    variables without ever actually _initializing_ them. How about this
    trivial one-liner? Does that make it work for you?

    Jens? Comments?

                                                     Linus

    ---
    ===== drivers/scsi/ide-scsi.c 1.33 vs edited =====
    --- 1.33/drivers/scsi/ide-scsi.c                 Tue Nov 18 23:40:45 2003
    +++ edited/drivers/scsi/ide-scsi.c               Tue Dec  2 10:36:33 2003
    @@ -516,6 +516,7 @@
                     pc->actually_transferred=0;   /* We haven't transferred 
    any data yet */
                     pc->current_position=pc->buffer;
                     bcount.all = IDE_MIN(pc->request_transfer, 63 * 1024);    
    /* Request to transfer the entire buffer at once */
    +                feature.all = 0;
                     if (drive->using_dma && rq->bio) {
                                     if (test_bit(PC_WRITING, &pc->flags))
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Aron Rubin: "Re: SII 3512+Seagate on Athlon64 system"

    Relevant Pages