Bug 124567 - cdrom: dropping to single frame dma & cd ripping
Summary: cdrom: dropping to single frame dma & cd ripping
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
: 125112 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-27 15:49 UTC by juha.heljoranta
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-05 12:29:35 UTC

Attachments (Terms of Use)

Description juha.heljoranta 2004-05-27 15:49:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040518 Firefox/0.8

Description of problem:
I cannot rip cds after kernel message

kernel: cdrom: dropping to single frame dma

after this, cdparanoia and cdda2wav reports heavy jitter and output is
total silence.

<http://www.uwsg.iu.edu/hypermail/linux/kernel/0405.1/1626.html> has a
nice thread about the problem. 

it would be _very_ nice if you would apply patch
into next fc2 kernel update :)

quick sollution is to restart the computer...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start ripping cds
2. wait for a kernel message (might take 1 track or few albums)
(3. restart computer to continue ripping)

Additional info:
in case it matters:
hdc: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 4096kB Cache, UDMA(33)

Comment 1 Robert G. Werner 2004-06-05 23:17:45 UTC
I'm also experiencing this same behavior:
using a Plexwriter 8/4/32a CD/CD-ROM CD-R/RW drive

same behavior in 2.6.6

Comment 2 David Arnold 2004-06-13 07:42:05 UTC
I have the same trouble using sound-juicer.  Eventually I will get the
"dropping to single frame dma" message from the kernel.  Ripping then
slows to a crawl and the file produced is mostly popping and clicking.

kernel: 2.6.5-1.358
driver: ide-cdrom version 4.61

This bug looks the same as #125112

Comment 3 Radu Cornea 2004-06-18 05:55:30 UTC
Same here with grip and kernel 2.6.6-1.435.

Comment 4 Jef Spaleta 2004-06-22 21:33:28 UTC
*** Bug 125112 has been marked as a duplicate of this bug. ***

Comment 5 d Forrest 2004-06-24 22:57:10 UTC
Me too.

# uname -a
Linux hob.private 2.6.6-1.435 #1 Mon Jun 14 09:09:07 EDT 2004 i686
athlon i386 GNU/Linux

Chunk of dmesg:

 USB Mass Storage device found at 7
 updfstab: Using deprecated /dev/sg mechanism instead of SG_IO on the
actual device
 usb 3-2: USB disconnect, address 7
 cdrom: dropping to single frame dma

Comment 6 David Arnold 2004-07-05 19:16:55 UTC
Just as an additional note, none of these helped:
* The latest kernel (2.6.7-bk17)
* Enable / disable ACPI, APIC, APM
* Rearranging IDE cables
* Updating BIOS and CD firmware

So far it looks like "dropping to single frame dma" is a symptom of a
deeper problem reading the CD.  In my case, there's something going
wrong with DMA, which once it filters up to the CD driver, it detects
the error and switches to single frame dma.

There are two ways to resolve this:
1) Figure out what's going wrong deeper in the I/O system and fix
that.  (If an error never gets to the CD driver, it won't try to
switch to single frame mode)
2) Disable switching to single frame if there have been successful
multi frame transfers.  Jens Axboe (current cdrom.c maintainer) says
he plans to make a patch to do this:

I have no clue what to do to further diagnose my dma problem, so I
guess Jens needs to be contacted to see if he's made the patch yet.

Comment 7 Russell Keith-Magee 2004-07-09 13:03:08 UTC
I have the same problem with my Pioneer DVR-107D, on my P4. I have
experienced the problem using the following kernels:

I believe I also have a reliable test case - the CD "Movement in Still
Life" by BT fails seems to reliably during a rip of Track 11.

Comment 8 juha.heljoranta 2004-08-02 12:34:05 UTC
Reproducible on vanilla 2.6.8-rc2. Fix to problem is in progress.

Comment 9 juha.heljoranta 2004-08-03 08:53:08 UTC
File attachments does not seem to work :( ...

Jean Axboe wrote: "The problem seems to be that for single frame dma,
the user pointer isn't incremented appropriately so it's basically a
one-liner fix. Try this one."

I adjusted patch line numbers so that it will apply cleanly against
2.6.6-1.435.2.3. Jean also said that the patch will be in offical 2.6.8.

I gave this patch some heavy testing, so.. would it be possible to get
this into next fc2 kernel update?

--- linux-2.6.6-1.435.2.3/drivers/cdrom/cdrom.c.orig    2004-07-01
15:25:01.000000000 +0300
+++ linux-2.6.6-1.435.2.3/drivers/cdrom/cdrom.c 2004-08-02
22:55:36.056897728 +0300
@@ -1890,6 +1890,8 @@
        struct packet_command cgc;
        int nr, ret;
+       cdi->last_sense = 0;
        memset(&cgc, 0, sizeof(cgc));
@@ -1941,6 +1943,8 @@
        if (!q)
                return -ENXIO;
+       cdi->last_sense = 0;
        while (nframes) {
                nr = nframes;
                if (cdi->cdda_method == CDDA_BPC_SINGLE)
@@ -1985,6 +1989,7 @@
                nframes -= nr;
                lba += nr;
+               ubuf += len;
        return ret;

Comment 10 Arjan van de Ven 2004-08-05 12:29:35 UTC
fixed in current erratum

Comment 11 kpearsall 2004-08-18 05:56:54 UTC
Er, dumb question, but what exactly is fixed, and how do i use this
fix?  I tried installing the patch above (from comment #9) on an FC2
system, and i no longer get the jitter problem as originally
described, but the device still operates INSANELY SLOW.

Even if I force the device back in to multiword DMA (hdparm -d 1 -X 34
devicename) it still operates slow.  Like dropping from about 12x to

What does this fix in current erratum do, and how can i get it?

Comment 12 juha.heljoranta 2004-08-18 11:41:10 UTC
AFAIK, some cdrom drives make errors when using multiframe dma. when
such error is detected, kernel changes into single frame dma.
Naturally sigle frame mode is bit slower that multiframe.

Generally, if this error occurs only while ripping scratched cds, then
it would be very reasonable to implement recovery mechanism (eg.
return to multiframe after, say 10, succesful single frame reads). I
think that fix would be only a few lines of code.

However, I think that the recovery fix would be dirty solution. This
issue needs further investigation to be addressed correctly.

My advice would be: send a mail to Jean Axboe. Before that read lkml
howto (for a writing style guidelines). In short, be polite, concise
and cooperative. Before that, try kernel or later to confirm
that the problem exists.

For me the above patch works fine.

I dont see any difference in performance after kernel changes into
single frame mode (riping speed is always about 2x for me).

AFAIK, the hdparm does not help you on this. It is not able to set
cdrom back into multiframe dma mode.

"In current erratum" means probably that the patch is in RedHats (or
in Linus') kernel tree.

From ChangeLog-2.6.8: "fix cdrom cdda rip single frame dma fall back"

Comment 13 kpearsall 2004-08-19 02:42:51 UTC

Many thanks for the advice.  I've been having -some- success with this
since I last commented...:

- 2.6.4-rc1 with longer patch from initial bug description: 
no corruption, but slower rip(1x-2x) after dma fallback.
- 2.6.6 with simple patch from comment #9: 
no corruption, but insanely slow rip(<1x) after dma fallback
- 2.6.8-1.520 (is this or 2.6.8?):
I seem to remember seeing dma fallback and/or jitter, but this was a
few days ago and I had consumed several beers.
- 2.6.8-1.521 (
Wow, looking good so far, instead of getting dma fallback I seem to
get more sensical mmc errors like so:
Aug 18 19:41:50 jagon kernel: ATAPI device hda:
Aug 18 19:41:50 jagon kernel:   Error: Aborted command -- (Sense key=0x0b)
Aug 18 19:41:50 jagon kernel:   (reserved error code) -- (asc=0x4e,
Aug 18 19:41:50 jagon kernel:   The failed "Read CD" packet command was:
Aug 18 19:41:50 jagon kernel:   "be 04 00 00 08 eb 00 00 08 f8 00 00
00 00 00 00

It's been a real bummer because I have several thousand more CDs to
rip, and having to reboot after 3-4 discs makes it take heinously
longer...  With any luck 2.6.8-1.521 is solving my problem and I can
finally finish this project.  Many, many thanks!

Comment 14 kpearsall 2004-08-21 04:29:14 UTC
This is still happening with 2.6.8-1.521.  I'm not getting corruption,
but still, the drive never returns to multi-frame dma after it drops.
 It's seriously annoying and causing massive amounts of wasted time.

Should I file a separate bug for the speed drop?

Note You need to log in before you can comment on or make changes to this bug.