cdrom: dropping to single frame dma

cdrom: dropping to single frame dma

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

I've been trying to rip my CDs onto my HD, and last night after about 7 
CDs I realized I was getting junk and it was taking forever to rip a 
CD.  I'm using 2.6.8-rc2 and I have two different CD-ROMs in my 
machine.  Both are burners.

I got a single "cdrom: dropping to single frame dma" message which 
according to my research is part of the culprit.

See the thread on LKML back on 5/15/2004 titled "dma ripping", and again 
on 6/15 titled "cdrom ripping / dropping to dingle frame dma" -- yes 
that's a "d".

I'm guessing that Jens' patch for this didn't make it into the kernel.

David




[-- Attachment #2: david+challenge-response.vcf --]
[-- Type: text/x-vcard, Size: 183 bytes --]

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: cdrom: dropping to single frame dma

[Jens Axboe]

On Sun, Jul 25 2004, David Ford wrote:
> I've been trying to rip my CDs onto my HD, and last night after about 7 
> CDs I realized I was getting junk and it was taking forever to rip a 
> CD.  I'm using 2.6.8-rc2 and I have two different CD-ROMs in my 
> machine.  Both are burners.
> 
> I got a single "cdrom: dropping to single frame dma" message which 
> according to my research is part of the culprit.
> 
> See the thread on LKML back on 5/15/2004 titled "dma ripping", and again 
> on 6/15 titled "cdrom ripping / dropping to dingle frame dma" -- yes 
> that's a "d".
> 
> I'm guessing that Jens' patch for this didn't make it into the kernel.

Try this.

--- linux-2.6.8-rc2-mm1/drivers/cdrom/cdrom.c~	2004-08-02 14:56:48.259992912 +0200
+++ linux-2.6.8-rc2-mm1/drivers/cdrom/cdrom.c	2004-08-02 15:20:58.326549288 +0200
@@ -2004,6 +2004,8 @@
 	struct packet_command cgc;
 	int nr, ret;
 
+	cdi->last_sense = 0;
+
 	memset(&cgc, 0, sizeof(cgc));
 
 	/*
@@ -2055,6 +2057,8 @@
 	if (!q)
 		return -ENXIO;
 
+	cdi->last_sense = 0;
+
 	while (nframes) {
 		nr = nframes;
 		if (cdi->cdda_method == CDDA_BPC_SINGLE)
@@ -2102,6 +2106,7 @@
 
 		nframes -= nr;
 		lba += nr;
+		ubuf += len;
 	}
 
 	return ret;

-- 
Jens Axboe

Re: cdrom: dropping to single frame dma

[Rogério Brito]

On Aug 02 2004, Jens Axboe wrote:
> On Sun, Jul 25 2004, David Ford wrote:
> > I got a single "cdrom: dropping to single frame dma" message which 
> > according to my research is part of the culprit.
> > 
> > I'm guessing that Jens' patch for this didn't make it into the kernel.
> 
> Try this.

I was having the same problems that David did.

In fact, I noticed that after I received the message "dropping to single
frame dma", everything that the CD drive ripped from that point on was just
digital silence.

With the patch sent by Jens, things seem to work well (just tried
extracting something that *did* generate the "single frame dma" message and
tried ripping another track and this latter track is, happily, not digital
silence).

I'm using an almost plain vanilla 2.6.7 kernel here (with a one-liner patch
to the USB hub controller).

Thanks Jens. I hope that this is included in the final 2.6.8.


Thanks again, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - rbrito@ime.usp.br - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: cdrom: dropping to single frame dma

[Jens Axboe]

On Tue, Aug 03 2004, Rogério Brito wrote:
> On Aug 02 2004, Jens Axboe wrote:
> > On Sun, Jul 25 2004, David Ford wrote:
> > > I got a single "cdrom: dropping to single frame dma" message which 
> > > according to my research is part of the culprit.
> > > 
> > > I'm guessing that Jens' patch for this didn't make it into the kernel.
> > 
> > Try this.
> 
> I was having the same problems that David did.
> 
> In fact, I noticed that after I received the message "dropping to single
> frame dma", everything that the CD drive ripped from that point on was just
> digital silence.
> 
> With the patch sent by Jens, things seem to work well (just tried
> extracting something that *did* generate the "single frame dma" message and
> tried ripping another track and this latter track is, happily, not digital
> silence).
> 
> I'm using an almost plain vanilla 2.6.7 kernel here (with a one-liner patch
> to the USB hub controller).
> 
> Thanks Jens. I hope that this is included in the final 2.6.8.

Thanks for testing, the patch is in current -BK so it will be in 2.6.8.

-- 
Jens Axboe

Re: cdrom: dropping to single frame dma

[David N. Arnold]

Jens Axboe wrote:
> On Sun, Jul 25 2004, David Ford wrote:
> 
>>I've been trying to rip my CDs onto my HD, and last night after about 7 
>>CDs I realized I was getting junk and it was taking forever to rip a 
>>CD.  I'm using 2.6.8-rc2 and I have two different CD-ROMs in my 
>>machine.  Both are burners.
>>
>>I got a single "cdrom: dropping to single frame dma" message which 
>>according to my research is part of the culprit.
>>
>>See the thread on LKML back on 5/15/2004 titled "dma ripping", and again 
>>on 6/15 titled "cdrom ripping / dropping to dingle frame dma" -- yes 
>>that's a "d".
>>
>>I'm guessing that Jens' patch for this didn't make it into the kernel.
> 
> 
> Try this.
> 
> --- linux-2.6.8-rc2-mm1/drivers/cdrom/cdrom.c~	2004-08-02 14:56:48.259992912 +0200
> +++ linux-2.6.8-rc2-mm1/drivers/cdrom/cdrom.c	2004-08-02 15:20:58.326549288 +0200
> @@ -2004,6 +2004,8 @@
>  	struct packet_command cgc;
>  	int nr, ret;
>  
> +	cdi->last_sense = 0;
> +
>  	memset(&cgc, 0, sizeof(cgc));
>  
>  	/*
> @@ -2055,6 +2057,8 @@
>  	if (!q)
>  		return -ENXIO;
>  
> +	cdi->last_sense = 0;
> +
>  	while (nframes) {
>  		nr = nframes;
>  		if (cdi->cdda_method == CDDA_BPC_SINGLE)
> @@ -2102,6 +2106,7 @@
>  
>  		nframes -= nr;
>  		lba += nr;
> +		ubuf += len;
>  	}
>  
>  	return ret;
> 

I don't know if it's a result of upgrading to 2.6.8-rc2 (from 2.6.5) or 
from the patch, but it has changed things.  I still get

hdd: DMA timeout retry
hdd: timeout waiting for DMA
hdd: status timeout: status=0xd0 { Busy }
hdd: status timeout: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
cdrom: dropping to single frame dma

but ripping stays at its normal speed (5.0x instead of 0.6x) and the 
file produced is correct instead of skipping/silence.

It doesn't fix the true issue of why I'm getting DMA timeouts, but it 
does make ripping useable.

P.S. Does anyone know why this:

gst-launch-0.8 cdparanoia ! vorbisenc ! filesink location="music.ogg"

would cause a DMA timeout but this:

gst-launch-0.8 cdparanoia ! queue ! { vorbisenc ! filesink 
location="music.ogg" }

wouldn't?

Thanks,
Dave Arnold

Re: cdrom: dropping to single frame dma

[Jens Axboe]

On Tue, Aug 03 2004, David N. Arnold wrote:
> I don't know if it's a result of upgrading to 2.6.8-rc2 (from 2.6.5) or 
> from the patch, but it has changed things.  I still get
> 
> hdd: DMA timeout retry
> hdd: timeout waiting for DMA
> hdd: status timeout: status=0xd0 { Busy }
> hdd: status timeout: error=0x00
> hdd: drive not ready for command
> hdd: ATAPI reset complete
> cdrom: dropping to single frame dma
> 
> but ripping stays at its normal speed (5.0x instead of 0.6x) and the 
> file produced is correct instead of skipping/silence.
> 
> It doesn't fix the true issue of why I'm getting DMA timeouts, but it 
> does make ripping useable.

After the 'dropping to single frame' message, does it work reliably
after that? And when does the above occur, initially or after some time?
Details, please.

-- 
Jens Axboe

Re: cdrom: dropping to single frame dma

[David N. Arnold]

Jens Axboe wrote:
> On Tue, Aug 03 2004, David N. Arnold wrote:
> 
>>I don't know if it's a result of upgrading to 2.6.8-rc2 (from 2.6.5) or 
>>from the patch, but it has changed things.  I still get
>>
>>hdd: DMA timeout retry
>>hdd: timeout waiting for DMA
>>hdd: status timeout: status=0xd0 { Busy }
>>hdd: status timeout: error=0x00
>>hdd: drive not ready for command
>>hdd: ATAPI reset complete
>>cdrom: dropping to single frame dma
>>
>>but ripping stays at its normal speed (5.0x instead of 0.6x) and the 
>>file produced is correct instead of skipping/silence.
>>
>>It doesn't fix the true issue of why I'm getting DMA timeouts, but it 
>>does make ripping useable.
> 
> 
> After the 'dropping to single frame' message, does it work reliably
> after that? And when does the above occur, initially or after some time?
> Details, please.
> 

After the single frame message it completes the CD rip without any other 
timeouts.  I can't tell if single frame mode impairs the speed, because 
sound-juicer doesn't rip at full CD speed anyway.  The DMA timeout 
usually happens in the first few tracks (it's nondeterministic even on 
the same CD).  The only annoying issue left is that the initial ATAPI 
reset freezes the system for a few seconds until it completes.

I don't know if you're interested, but the DMA timeout only happens in 
certain usage patterns.  If you grab the data one frame at a time with 
pauses in between (for example linking an ogg encoder directly to the 
data stream) it will trigger the DMA timeout.  If you rip the CD at full 
  drive speed (like ripping to WAV) or batch the read requests together, 
it doesn't have any problems.  Also, if you slow the max speed of the 
drive down with 'hdparm -E' so that the drive is operating at max 
(because it's now slower than the encoder) it works fine.

This is all on a JLMS XJ-HD163D DVD drive on the latest firmware.

Thanks,
Dave Arnold