From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Description of problem: See bugs 39689 and 40085. Boot parameter "ide=nodma" was processed by kernel but not effective. Adding "hdparm -d 0 /dev/hda" to rc.sysinit worked fine. System configuration: AMD K7, VIA, Maxtor 92048D8. I understand this has been fixed in RawHide; but I'm not currently in a position to download and try the RawHide stuff. I'm filing bug as service to Red Hat developers and other bugzilla readers, since the cited bug reports are not quite the same as this one. One was resolved by "ide=nodma"; the other had some drive/controller peculiarities. Please feel free to close this report immediately. How reproducible: Always Steps to Reproduce: 1. Obtain relevant hardware 2. Install RH 7.1 3. Boot system and observe /var/log/messages Actual Results: May 10 16:40:02 athlon kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } May 10 16:40:02 athlon kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC } Expected Results: No error messages Additional info: Attachment to follow
Created attachment 18186 [details] Relevant messages from /var/log/messages
BadCRC indicates a UDMA 33/66/100 cable problem. Check the cables are under 18" long and that for UDMA 66/100 you have 80wire cable. The actual important bit of this bug report is - which IDE controller nodma was ignored for
According to the system docs, the IDE controller is a VIA 686A. Just to be clear, I'm not concerned about the BadCRC messages. It is possible that the PC has an incorrect cable or something--I haven't checked. But, the ide=nodma boot parameter should have suppressed DMA operation. It appears not to have done so. I get similar messages and behavior on an old P166 PC. Both PCs functioned without error messages with RHL 6.2. It seems that RHL 7.1 really wants DMA. I suppose you can't blame it for trying <grin>.