Bug 74976 - Burning a CD slows the system clock to a crawl
Burning a CD slows the system clock to a crawl
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-03 07:21 EDT by Thais Smith
Modified: 2008-08-01 12:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thais Smith 2002-10-03 07:21:49 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):  
kernel-2.4.18-14  
  
How Reproducible:  
100% 
  
Steps to Reproduce:  
1. Start burning an ISO image to CD 
2. Watch the clock 
3.   
  
Actual Results:  
  
  
Expected Results:  
  
  
Additional Information:  
The burn command line is "mkisofs -quiet -R /local/backup.tar | cdrecord -v 
-eject speed=8 dev=0,1,0 -"
Comment 1 Thais Smith 2002-10-03 07:59:47 EDT
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.
Comment 2 Thais Smith 2002-10-03 11:19:20 EDT
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  
-------------------drive0----drive1----drive2----drive3-----  
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  
  
Comment 3 Need Real Name 2002-10-15 04:23:40 EDT
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. 


Comment 4 Brian Stretch 2002-12-04 23:22:30 EST
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.) 
Comment 5 Brian Stretch 2002-12-24 11:32:14 EST
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. 
Comment 6 Ben LaHaise 2002-12-24 14:15:21 EST
If your cd burner has to operate in PIO mode, you can try enabling unmask irq
mode with hdparm -u1 on the cdrom device.
Comment 7 Matt McClure 2003-01-09 18:24:15 EST
I see the same symptoms as in comment 3 on a 600 MHz PIII.  Also never saw this
under 7.3.
Comment 8 Craig Lawson 2003-02-19 15:00:12 EST
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.
Comment 9 Craig Lawson 2003-05-02 13:26:24 EDT
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
interfere)?
Comment 10 Bugzilla owner 2004-09-30 11:39:58 EDT
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
persists.

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/

Note You need to log in before you can comment on or make changes to this bug.