lkml.org 
[lkml]   [2009]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: linux-next-20090225: ide-cd triggers BUG at arch/x86/mm/ioremap.c:80!
    Date
    On Monday 02 March 2009, Borislav Petkov wrote:
    > Hi,
    >
    > > Borislav Petkov wrote:
    > >> Can you also apply the following patch and send us the output?
    > > I applied the patch after "git bisect reset" since I couldn't apply from this
    > > state.
    > >
    > > [ 3.419143] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    > > [ 3.424508] ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
    > > [ 3.429658] ide-gd driver 1.18
    > > [ 3.433879] ide-cd driver 5.00
    > > [ 3.440135] mapping rq to sg: dev hda: type=a, flags=82640
    > > [ 3.441873] sector 4294967295, nr/cnr 0/0
    > > [ 3.445288] bio (null), biotail (null), buffer (null), data f700fbc4, len 24
    > > [ 3.452602] ide-cd: hda: ATAPI 1X CD-ROM drive, 32kB Cache
    > > [ 3.456659] Uniform CD-ROM driver Revision: 3.20
    > > [ 3.460913] mapping rq to sg: dev hda: type=a, flags=8a640
    > > [ 3.464697] sector 4294967295, nr/cnr 0/0
    > > [ 3.465881] bio (null), biotail (null), buffer (null), data (null), len 0
    > > [ 3.472354] Pid: 1, comm: swapper Not tainted 2.6.29-rc6-next-20090227-dirty #10
    > > [ 3.476790] Call Trace:
    > > [ 3.477860] [<c02ef9bd>] ide_cd_do_request+0x12d/0x170
    > > [ 3.480496] [<c02e1d28>] start_request+0xa8/0x160
    > > [ 3.481883] [<c015d92b>] ? trace_hardirqs_on+0xb/0x10
    > > [ 3.485680] [<c02e1f7b>] do_ide_request+0x16b/0x250
    > > [ 3.489231] [<c025e5a5>] ? blk_remove_plug+0x75/0xf0
    > > [ 3.492817] [<c025f770>] blk_start_queueing+0x20/0x30
    > > [ 3.495475] [<c025d2be>] elv_insert+0x17e/0x1b0
    > > [ 3.497088] [<c025e458>] ? blk_plug_device+0x88/0x120
    > > [ 3.499681] [<c025d372>] __elv_add_request+0x82/0xc0
    > > [ 3.501428] [<c0263ad0>] blk_execute_rq_nowait+0x60/0xb0
    > > [ 3.504214] [<c0263bb6>] blk_execute_rq+0x96/0xd0
    > > [ 3.505802] [<c0263a40>] ? blk_end_sync_rq+0x0/0x30
    > > [ 3.508392] [<c025f59c>] ? get_request_wait+0x2c/0x160
    > > [ 3.509883] [<c0160429>] ? __lock_acquired+0x109/0x1c0
    > > [ 3.512691] [<c025f6f4>] ? blk_get_request+0x24/0x80
    > > [ 3.515239] [<c02ef196>] ide_cd_queue_pc+0xb6/0x140
    >
    > ok, if I read the stack dump correctly, we map an rq with rq->data = NULL to an
    > sg. Code path starts at cdrom_check_status() and actually, we don't need a
    > buffer here since we send a TEST_UNIT_READY and we're only interested in the
    > sense returned. And this won't trigger if we haven't enabled
    > CONFIG_DEBUG_VIRTUAL. Yep, I know that this is a dirty hack but it fixes it
    > here. Tetsuo, does the following fix your problem?
    >
    > diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
    > index 481fb1b..e6ac4cc 100644
    > --- a/drivers/ide/ide-io.c
    > +++ b/drivers/ide/ide-io.c
    > @@ -238,6 +238,8 @@ void ide_map_sg(ide_drive_t *drive, struct ide_cmd *cmd)
    > sg_init_one(sg, rq->buffer, rq->nr_sectors * SECTOR_SIZE);
    > cmd->sg_nents = 1;
    > } else if (!rq->bio) {
    > + if (!rq->data)
    > + rq->data = &rq->data;
    > sg_init_one(sg, rq->data, rq->data_len);
    > cmd->sg_nents = 1;
    > } else
    >
    > @Bart: I'm open for suggestions wrt to a more elegant solution :).

    Seems like we should check for blk_fs_request(fs) || rq->data_len
    instead of unconditionally sg mapping all requests in ->do_request.

    [ Sigh, I thought it is harmless to always call sg_init_one()...
    probably because it was true back when I added this helper :) ]

    Thanks,
    Bart


    \
     
     \ /
      Last update: 2009-03-02 16:31    [W:0.050 / U:90.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site