Hello,
I found this problem when burning DVDs using K3b (it uses growisofs to
do the work) with LG GSA-4167B drive:
Burn process completes without any problems, then K3b ejects and reloads
the tray, then it calculates MD5 checksum from the image. Then it starts
reading the DVD back to calculate MD5 checksum of it. The moment it
starts to read, this appears in dmesg:
hdd: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hdd: DMA disabled
hdd: ATAPI reset complete
And then it slowly reads the DVD in PIO mode. After about a hour, it
finishes with success. When I re-enable DMA mode ("hdparm -d1 /dev/hdd")
immediately after it was disabled, it works fine in - there are no more
errors in the log and the verification completes much sooner. I burnt 10
DVDs and it always does exactly this.
Any ideas why it does this? And why ide-cd disables the DMA?
Kernel is 2.6.13, the drive is (firmware is the latest version):
/dev/hdd:
Model=HL-DT-ST DVDRAM GSA-4167B, FwRev=DL12, SerialNo=7076348C2984
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
Drive conforms to: device does not report version:
* signifies the current active mode
--
Ondrej Zary
On Thu, 12 Jan 2006 22:35:21 +0100, Ondrej Zary wrote:
> Hello,
> I found this problem when burning DVDs using K3b (it uses growisofs to
> do the work) with LG GSA-4167B drive:
> Burn process completes without any problems, then K3b ejects and reloads
> the tray, then it calculates MD5 checksum from the image. Then it starts
> reading the DVD back to calculate MD5 checksum of it. The moment it
> starts to read, this appears in dmesg:
>
> hdd: irq timeout: status=0xd0 { Busy }
> ide: failed opcode was: unknown
> hdd: DMA disabled
> hdd: ATAPI reset complete
>
> And then it slowly reads the DVD in PIO mode. After about a hour, it
> finishes with success. When I re-enable DMA mode ("hdparm -d1 /dev/hdd")
> immediately after it was disabled, it works fine in - there are no more
> errors in the log and the verification completes much sooner. I burnt 10
> DVDs and it always does exactly this.
>
> Any ideas why it does this? And why ide-cd disables the DMA?
I think the drive just takes too long to recongize the disc. My 4163B has
the same problem which is why I always close the tray manually or with
eject -t and wait a while before mounting or burning the disc. Of course
that won't help in your case. I guess the real fix would be to
increase some ide-cd timeout.
--
Ville Syrj?l?
[email protected]
http://www.sci.fi/~syrjala/
Ville Syrj?l? wrote:
> I think the drive just takes too long to recongize the disc. My 4163B has
> the same problem which is why I always close the tray manually or with
> eject -t and wait a while before mounting or burning the disc. Of course
> that won't help in your case. I guess the real fix would be to
> increase some ide-cd timeout.
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.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
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.
Yes! Each time when inserting a faulty CD/DVD, or whenever the drive
gives read errors for whatever reason, the kernel decides to turn DMA
off and try again, fail (again) and leave DMA off. And this after having
successfully used DMA before - so it's not that the device is
DMA-incapable.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Hi,
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?
> Yes! Each time when inserting a faulty CD/DVD, or whenever the drive
> gives read errors for whatever reason, the kernel decides to turn DMA
> off and try again, fail (again) and leave DMA off. And this after having
> successfully used DMA before - so it's not that the device is
> DMA-incapable.
This is a separate issue and is related to retrying failed DMA
commands. Driver doesn't know what was the cause of the timeout
and it shouldn't disable DMA for the device (only the failed request
should be retried in PIO mode).
Any takers? :)
PS1 please don't trim cc: list
PS2 please use [email protected] for ATA problem
Thanks,
Bartlomiej
Bartlomiej Zolnierkiewicz wrote:
> Ondrej, could you fill the bug at
> http://bugzilla.kernel.org so we don't lose it?
>
Here it is http://bugzilla.kernel.org/show_bug.cgi?id=5882
--
Ondrej Zary
On 1/13/06, Rashkae <[email protected]> wrote:
> On Fri, Jan 13, 2006 at 10:19:17AM +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?
>
> Shouldn't whether DMA is restored after reset be governed by keepsettings flag?
settings should always be preserved and keepsettings flag should die
> From the hdparm man page:
>
> -k Get/set the keep_settings_over_reset flag for the
> drive. When this flag is set, the driver will pre?
> serve the -dmu options over a soft reset, (as done
> during the error recovery sequence).
>
> I was a little disapointed that this didn't work as advertised.
AFAIR (2.5/2.6 and probably 2.4 also) it never worked w.r.t. to DMA
as documented in hdparm manual.
Bartlomiej