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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site