I'm adding missing cc:, I hope I didn't forget about anybody this time.
There is now bugzilla entry for this bug (thanks Ondrej):
http://bugzilla.kernel.org/show_bug.cgi?id=5882
Jens, could you take a look at the part related to ide-cd timeouts?
On 1/13/06, Ville Syrjälä <[email protected]> wrote:
> On Fri, Jan 13, 2006 at 10:49:22AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On 1/13/06, Ville Syrjälä <[email protected]> wrote:
> > > On Fri, Jan 13, 2006 at 10:21:44AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > On 1/13/06, Volker Kuhlmann <[email protected]> wrote:
> > > > > On Fri 13 Jan 2006 17:40:33 NZDT +1300, Robert Hancock wrote:
> > > > >
> > > > > > I'm thinking the IDE code is too aggressive in assuming that the failure
> > > > > > is because of a DMA problem and disabling it.. Most likely all that's
> > > > > > happening is the drive is taking a long time to complete the current
> > > > > > command.
> > > >
> > > > What actually happened is that normal command timed out
> > > > and because of that driver reset the device which caused
> > > > it to loose DMA:
> > > >
> > > > ->ide_atapi_error()
> > > > ->ide_do_reset()
> > > > ->pre_reset()
> > > > ->check_dma_crc()
> > > > ->__ide_dma_off()
> > > >
> > > > Somebody needs to investigate why __ide_dma_off() is called
> > > > et all and if we need to restore DMA after reset (don't count ATM
> > > > on me, I'm buried by bugreports). Ondrej, could you fill the bug at
> > > > http://bugzilla.kernel.org so we don't lose it?
> > >
> > > It looks like this has been fixed recently. In 2.6.14-rc4-mm1
> > > check_dma_crc() used to call __ide_dma_off() when no CRC errors were
> > > registered. The bug has been fixed before 2.6.15-rc5-mm1. I'm still
> > > running 2.6.14-rc4-mm1 on my burning system so I haven't actually tested
> > > this on a recent kernel.
> >
> > I don't see it being fixed, could you point me at the patch?
>
> It seems the patch was carried along during the 2.6.15-rc-mm series but
> was later dropped.
>
> Here it is:
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/ide-promise-flushing-hang-fix.patch
>
> There's a bunch of other stuff in that patch besides the __ide_dma_off()
> change. Maybe that approach isn't correct and just increasing some
> timeout value would work. LG burners are just really slow recognizing
> discs.
The patch was NACK-ed by Alan Cox and I agree with him (this should be
done differently). This __ide_dma_off() chunk looks sensible but does it fix
the issue? I was under impression that after a reset drive looses its DMA
xfer mode and needs to be reprogrammed (ATA spec has the answer).
> I just took some random discs from my colletion and measured the time it
> took for the drive to recognize them.
>
> ~12 seconds for CD-R
> ~15 seconds for some DVD+R
> ~27 seconds for some DVD+R
>
> I'm not sure why it takes so long for some discs. I know they aren't
> bad burns because my laptop DVD-ROM drive, which is more sensitive to
> disc quality than the LG, can read them without any problems and it
> recognizes them in a few seconds.
I'll let Jens comment on this one. :)
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
