From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: Please excusemy bad english, but I try my very best! I have a HD connected with a Promise Ultra100 to my System. When I copy large files via samba or from another HD to this 250GB disk the System-Log shows the following: Jul 25 01:46:03 familix kernel: hdf: dma_timer_expiry: dma status == 0x40 Jul 25 01:46:03 familix kernel: hdf: DMA timeout retry Jul 25 01:46:03 familix kernel: PDC202XX: Primary channel reset. Jul 25 01:46:03 familix kernel: PDC202XX: Secondary channel reset. Jul 25 01:46:03 familix kernel: hdf: timeout waiting for DMA Jul 25 01:46:23 familix kernel: hdf: dma_timer_expiry: dma status == 0x41 Jul 25 02:58:12 familix kernel: hdf: DMA timeout error Jul 25 02:58:12 familix kernel: hdf: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest } Jul 25 02:58:12 familix kernel: Jul 25 02:58:12 familix kernel: hdf: status timeout: status=0xd0 { Busy } Jul 25 02:58:12 familix kernel: Jul 25 02:58:12 familix kernel: PDC202XX: Primary channel reset. Jul 25 02:58:12 familix kernel: PDC202XX: Secondary channel reset. Jul 25 02:58:12 familix kernel: hdf: drive not ready for command Jul 25 02:58:12 familix kernel: ide2: reset: master: error (0x00?) Sometimes, the hd turns into WRITE-PROTECTED. The only thing is to reboot the computer. Version-Release number of selected component (if applicable): any of 2.6.x released by Fedora How reproducible: Always Steps to Reproduce: 1. copy a large file (>700MB) 2. 3. Actual Results: The problem as described Expected Results: Copying the file very fast without an error. Additional info: On Fedora-Core 1 with kernel 2.4.whatever, the system worked properly. After updating the system, I have this above mentioned behavior.
Same here. After adding a new disk (200GB Seagate Barracuda ST3200822A) replacing and older IBM DTLA, dms timeouts occur under heavy load. With USE_DMA and -X69 in /etc/sysconfig/harddisks, the controller seems to go into readonly mode as soon as it happens. -X68 doesn't seem to be as bad, it made these log entries survive: kernel: hdf: DMA timeout error kernel: hdf: dma timeout error: status=0xd0 { Busy } kernel: kernel: hde: DMA disabled kernel: hdf: DMA disabled kernel: PDC202XX: Primary channel reset. kernel: PDC202XX: Secondary channel reset. kernel: ide2: reset: master: error (0x00?) kernel: hdf: dma_timer_expiry: dma status == 0x41 kernel: hdf: DMA timeout error kernel: hdf: dma timeout error: status=0xd0 { Busy } kernel: kernel: hdf: DMA disabled kernel: PDC202XX: Primary channel reset. kernel: PDC202XX: Secondary channel reset. kernel: ide2: reset: master: error (0x00?) kernel: end_request: I/O error, dev hdf, sector 272714424 kernel: Buffer I/O error on device dm-1, logical block 34089303 It didn't happen again after I removed USE_DMA and EXTRA_PARAMS=-X69 from /etc/sysconfig/harddisks although hdparm still reports the disk to be using dma and udma5. It might me unrelated to the drive though, I was also upgrading to kernel 2.6.8-1.521 and using xfs with evms at the same time.
Created attachment 105350 [details] /proc/ide/pdc202xx of the WORKING configuration This is the output of `cat /proc/ide/pdc202xx` in the configuration where the lockup does NOT seem to happen.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.