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

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
model: LITEON DVD-ROM LTD163D
driver: ide-cdrom version 4.61

This bug looks the same as #125112

Same here with grip and kernel 2.6.6-1.435.

*** Bug 125112 has been marked as a duplicate of this bug. ***

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

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:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0406.1/1555.html

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.

I have the same problem with my Pioneer DVR-107D, on my P4. I have
experienced the problem using the following kernels:
2.6.5-1.358smp
2.6.6-1.435.2.3smp
2.6.6-1.435.2.3

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.

Reproducible on vanilla 2.6.8-rc2. Fix to problem is in progress.

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;

fixed in current erratum

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
<1x...

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

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 2.6.8.1 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"

Hi,

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 2.6.8.1 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 (2.6.8.1??):
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,
ascq=0x00)
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!

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?