cdrom: dropping to single frame dma

DISCUSSION David Ford 4 participants 7 messages Jul 25, 2004 – Aug 6, 2004 Uniform cdrom driver

Share & tools

David Ford

author

2004-07-25 19:29 UTC #0 lore raw

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

begin:vcard
fn:David Ford
n:Ford;David
email;internet:[email protected]
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Jens Axboe

2004-08-02 13:25 UTC #1 lore raw

Quoted 5 lines · David Ford

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.

Quoted 8 lines

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.

drivers/cdrom/cdrom.c renamed from drivers/cdrom/cdrom.c~ +5 -0

@@ -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;

Signature · 1 line

Jens Axboe

Rogério Brito

2004-08-03 10:00 UTC #2 lore raw

Quoted 7 lines · Jens Axboe

Quoted 4 lines · David Ford
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.

Signature · 3 lines

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [email protected] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Jens Axboe

2004-08-03 10:02 UTC #3 lore raw

Quoted 20 lines · Rogério Brito

Quoted 7 lines · Jens Axboe
Quoted 4 lines · David Ford
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).

Quoted 4 lines

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.

Signature · 1 line

Jens Axboe

David N. Arnold

2004-08-04 00:37 UTC #4 lore raw

In reply to Jens Axboe

Quoted 35 lines · Jens Axboe

Quoted 7 lines · David Ford
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.
drivers/cdrom/cdrom.c renamed from drivers/cdrom/cdrom.c~ +4 -0
@@ -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)

drivers/cdrom/cdrom.c line 2112

Quoted 7 lines

drivers/cdrom/cdrom.c renamed from drivers/cdrom/cdrom.c~ +1 -0

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

Jens Axboe

2004-08-04 05:31 UTC #5 lore raw

Quoted 11 lines · David N. Arnold

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

Quoted 5 lines

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.

Signature · 1 line

Jens Axboe

David N. Arnold

2004-08-06 02:04 UTC #6 lore raw

Quoted 12 lines · Jens Axboe

Quoted 10 lines · David N. Arnold
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

Quoted 9 lines

Quoted 3 lines
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