Hide Forgot
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 <http://www.uwsg.iu.edu/hypermail/linux/kernel/0403.0/0559.html> into next fc2 kernel update :) quick sollution is to restart the computer... Version-Release number of selected component (if applicable): kernel-2.6.5-1.358 How reproducible: Always 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)
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?