Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 124567
Summary: | cdrom: dropping to single frame dma & cd ripping | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | juha.heljoranta |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | christoph_lorenz, kpearsall, tjb |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-08-05 12:29:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
juha.heljoranta
2004-05-27 15:49:49 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 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? |