While using gentoo-dev-sources 2.6.8-r3, CD burning causes the entire system to "stutter" and lock up for 0.5-1.5 seconds at a time. The problem only starts after the burn has been going for 30-45 seconds (several tracks into an audio CD burn) and continues until the burn finishes. When this happens suddenly the system will start to stutter (as if it was thrashing, except there is no swap activity) and multiple buffer-underruns will be triggered (typically 20-30 per burn). This happens every time I attempt an audio CD burn, including simulation writes. There is no significant system load going on in the background. This started with 2.6.8-gentoo-r3, I've had no problems with 2.6.7-*. It bears repeating that there is no background load (system is 99-100% idle) and this happens every time I burn a CD. Reproducible: Always Steps to Reproduce: 1. 2. 3. - System: Athlon XP 2600+, 768MB RAM - Kernel: 2.6.8-gentoo-r3, preemptible kernel, CFQ IO scheduler - XOrg 6.7.0-r2 - GNOME 2.6.2 - XCDRoast 0.98_alpha15-r3 - cdrtools 2.01_alpha28-r1 - Generic MMC CD-R/RW drive, writing via ATAPI driver (not SCSI emulation)
I should add that there's nothing in either dmesg or syslog that indicates anything going wrong.
The use of DMA-commands have changed inside the kernel and cdrtools. Could you please upgrade to the cdrtools-2.01_alpha37 and test with that version? It's known to work better with the 2.6.8-kernels.
I just tested and this also happens with cdrtools-2.01_alpha37 I tested cdrecord on the console directly as well as with xcdroast and the symptoms were the same. The cdrecord binary was made SUID prior to console test. The writer and media are 52x, this happens when writing at 52x but NOT at 24x. My CPU is at or near max utilization throughout all tests. No background load. When issuing the following command, the stuttering starts at about track 8 out of 14 total, 12 buffer-underruns predicted: cdrecord dev="ATAPI:0,0,0" fs=4096k driveropts=burnfree -v -useinfo speed=52 -dao -dummy -pad -audio ./*.wav
I have a somewhat similar problem: When burning an audio cd w/gentoo-dev-sources-2.6.8-r4 the burn starts at around 23x and my whole system slows to a crawl, basically unusable. After a couple of tracks speed drops down to 16x and load lightens a bit but not much. Data ISOs burn flawlessly at full speed (drive is a 52x24x52) with no load on system. cdrtools-2.01_alpha37 I've tried the following w/cdrecord: cdrecord -v dev=ATAPI:0,0,0 fs=4m driveropts=burnfree -sao -audio -pad cdrecord -v dev=ATA:1,0,0 fs=4m driveropts=burnfree -sao -audio -pad cdrecord -v dev=/dev/hdc fs=4m driveropts=burnfree -sao -audio -pad Also tried options -tao, changing FIFO size-it never gets less than 97% even at 4m. Out of frustration I even tried using the scsi-emulation with the same results. Today I tried using my everything always work kernel-gentoo-dev-sources-2.6.5-r1, audio cd burns perfectly full speed w/no load on system.
Sorry to be a nuisance but is there any progress on this? I realize it's upstream but it would probably take days scanning thru the kernel.org mailing list to find out. Thanks, Jeff
Is this still valid for gentoo-dev-sources 2.6.9? Could you upgrade to cdrtools-2.01? As (quite) any prior version works only for kernel <2.6.7.
I use gentoo-dev-sources-2.6.9-r1 and cdrtools-2.01, but the problem still exists... This only happens when burning audio-cds btw. Data-cds burn like a charm.
Ditto what enkil said: gentoo-dev-sources-2.6.9-r1 cdrtools-2.01 The problem is definitely still there.
I can verify that this bug still exists with gentoo-dev-sources 2.6.9-r4 and cdrtools 2.01.
I have the same problem here with gentoo-dev-sources-2.6.9-r13 and cdrecord 2.01. The initial bug seems to be the problem with the memory leak that was present in 2.6.8 and 2.6.8.1. There seems to be a second problem however. Additional information: http://bugs.kde.org/show_bug.cgi?id=95509 http://sourceforge.net/mailarchive/forum.php?thread_id=6260166&forum_id=1927 http://bugzilla.kernel.org/show_bug.cgi?id=3550 Can you confirm that the high CPU load is created in the hardware interrupts (look at the CPU line of 'top')? As a workaround you can try burning the audio CDs in raw mode (not DAO or TAO).
What's the state of this bug with current cdrtools and current kernel?
It's still there. 44% hi load burning 10x on an AMD 2200+. cdrtools 2.01-r2 gentoo-sources-2.6.11-r6
Yes, the bug is still there. I've noticed now that it's sporadic and related to DMA at least on my machine. Sometimes DMA will be mysteriously disabled ("cdrom: dropping to single frame dma" in /var/log/messages) during either a burn or an audio CD rip and I can't re-enable it without doing a full device reset. When DMA is disabled in this manner the high load bug is present.
I do not see any messages in my syslog, DMA is and stays enabled, but audio CDs are definitely burned in PIO mode. I installed oprofile to check where the CPU load goes and it's all spent in 'ide_outsl' which does the PIO output operation.
Still have this issues ? Can you please test cdrtools-2.01.01_alpha03 and report if you got the same issues.
Just tested with cdrtools-2.01.01_alpha03 and kernel 2.6.12-gentoo-r9 -> the problem seems indeed solved
Closing then.