Bug 74976

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  
-------------------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  
  

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
under 7.3.

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
interfere)?

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/