Re: 2.6.19-rc5: known regressions

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Nov 08 2006, Alex Romosan wrote:
> Jens Axboe <jens.axboe@oracle.com> writes:
> 
> > On Wed, Nov 08 2006, Adrian Bunk wrote:
> >> Subject    : unable to rip cd
> >> References : http://lkml.org/lkml/2006/10/13/100
> >> Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
> >> Status     : unknown
> >
> > Alex, was/is this repeatable? If so I'd like you to repeat with this
> > debug patch applied, I cannot reproduce it locally.
> >
> > diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> > index bddfebd..ad03e19 100644
> > --- a/drivers/ide/ide-cd.c
> > +++ b/drivers/ide/ide-cd.c
> > @@ -1726,8 +1726,10 @@ static ide_startstop_t cdrom_newpc_intr(
> >  		/*
> >  		 * write to drive
> >  		 */
> > -		if (cdrom_write_check_ireason(drive, len, ireason))
> > +		if (cdrom_write_check_ireason(drive, len, ireason)) {
> > +			blk_dump_rq_flags(rq, "cdrom_newpc");
> >  			return ide_stopped;
> > +		}
> >  
> >  		xferfunc = HWIF(drive)->atapi_output_bytes;
> >  	} else  {
> > @@ -1859,8 +1861,10 @@ static ide_startstop_t cdrom_write_intr(
> >  	}
> >  
> >  	/* Check that the drive is expecting to do the same thing we are. */
> > -	if (cdrom_write_check_ireason(drive, len, ireason))
> > +	if (cdrom_write_check_ireason(drive, len, ireason)) {
> > +		blk_dump_rq_flags(rq, "cdrom_pc");
> >  		return ide_stopped;
> > +	}
> >  
> >  	sectors_to_transfer = len / SECTOR_SIZE;
> >  
> 
> i've tried it again with the above patch applied and when i start
> cdparanoia i get:
> 
> kernel: hdc: write_intr: wrong transfer direction!
> kernel: cdrom_newpc: dev hdc: type=2, flags=114c9
> kernel: 
> kernel: sector 59534648, nr/cnr 0/0
> kernel: bio 00000000, biotail c14b2800, buffer 00000000, data 00000000, len 56
> kernel: cdb: 12 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 

Wonderful! So this is an INQUIRY command, yet the WRITE bit is set. The
drive gets really confused about that, for good reason. The question is
where that write bit comes from, it looks really odd. Additionally, we
have killed ->bio but ->biotail still looks valid. Perhaps it's some of
the error handling that got screwed.

> as for the lock up, the ripping process never completes, it starts and
> then it hangs somewhere in the middle of the track. it could be that
> the disk has some problems. anyway, abort execution doesn't work until
> i physically eject the cd from the drive (which seems to be an
> improvement from a couple of rc's ago). hope this helps.

It helps a lot, thanks! I may ask you to retest with another patch, if
you don't mind.

-- 
Jens Axboe

-
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/