Red Hat Bugzilla – Bug 74976
Burning a CD slows the system clock to a crawl
Last modified: 2008-08-01 12:22:52 EDT
Description of Problem:
While burning a CD using an HP CD-writer 9300 driven by ide-scsi, the system
clock slows to a crawl. On my Athlon 1300, it takes about 3 seconds to
increment by 1 second. ntpd gives up trying to keep this synchronised. After a
long CD backup, my clock is now 1hr 45mins slow...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start burning an ISO image to CD
2. Watch the clock
The burn command line is "mkisofs -quiet -R /local/backup.tar | cdrecord -v
-eject speed=8 dev=0,1,0 -"
This is of course with the default settings wrt DMA and IRQ unmasking.
However, the timer should be able to work out when it's missed a few ticks
surely, and keep itself at least close enough that ntpd can do the rest.
Setting hdparm -u /dev/hdc doesn't help. If I turn on dma it just gets turned
off again at the first error.
Incidentally, this problem did not happen with RH 7.3
cat /proc/ide/via gives
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.35
South Bridge: VIA vt82c686b
Revision: ISA 0x40 IDE 0x6
Highest DMA rate: UDMA100
BM-DMA base: 0xd800
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: yes no
Post Write Buffer: yes no
Enabled: yes yes
Simplex only: no no
Cable Type: 80w 40w
Transfer Mode: UDMA PIO PIO PIO
Address Setup: 30ns 120ns 30ns 30ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery: 30ns 30ns 30ns 30ns
Data Active: 90ns 330ns 90ns 90ns
Data Recovery: 30ns 270ns 30ns 30ns
Cycle Time: 20ns 600ns 120ns 120ns
Transfer Rate: 99.9MB/s 3.3MB/s 16.6MB/s 16.6MB/s
i see the same behavior on my 2.14 GHz P4 when i hit the cdrom hard with
cdparanoia. it's using the ide-scsi layer for access and the settings are the
defaults (DMA on, umaskirq off). after ripping a 75 minute cd the system clock
will be over 10 minutes slow. the panel clock is also visibly slower when data
ia being ripped from cd. i also had never seen anything like this in 7.3. system
resposiveness does remain good during the ripping process, though.
Same here, kernel 2.4.18-18.8.0smp on my Asus A7M266-D board with Pioneer
DVR-104 (firmware 1.33). This kernel also claims that it's for the i686, not
athlon, and yes I even reinstalled it with --force just to make sure I didn't
install i686 by accident.
In addition, with DMA turned on (hdparm -d 1 /dev/hdc), dvdrecord requires
multiple attempts before it successfully starts a burn (fortunately without
trashing the DVD-R disc), with opening/closing the tray and perhaps dvdrecord
-reset dev=0,0,0 required between attempts. (Merely adding options ide-cd dma=1
to /etc/modules.conf is insufficient to enable DMA when using IDE-SCSI
emulation, btw, which I think is a feature and not a bug.)
Ignore my previous commend about DMA trouble. It turns out that the Pioneer
DVR-104 burner only works properly with AMD chipsets in PIO mode. Bad Pioneer!
Otherwise, yes, same problem with system clock slowing to a crawl as everyone
else, burning in PIO and DMA mode.
If your cd burner has to operate in PIO mode, you can try enabling unmask irq
mode with hdparm -u1 on the cdrom device.
I see the same symptoms as in comment 3 on a 600 MHz PIII. Also never saw this
I see this problem with RH 7.3, however I am using the 2.4.18-17.7.x kernel.
Writing a full audio CD results in a loss of 4 minutes on the system clock. I
have a Plextor ATAPI CD-RW accessed with SCSI emulation, and 933 Mhz P3.
My CD-RW drive settings are similar to Tim's, except I am using DMA, not PIO.
I upgraded my system to Red Hat 9.0, and I see the same clock-slowing behavior.
Kernel: 2.4.20-9, cdrecord 2.0.
This time, I tried something different. When running cdrecord as root, the clock
slows. When run as non-root, cdrecord complains that it cannot increase the task
priority and it may be detrimental to the CD writing procedure, and the clock
does not slow. Could it be possible that when run as root, cdrecord schedules
itself at a higher priority than the system clock (or at least high enough to
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/