From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686) Problem is that the kernel (during load) sees the KT7 based motherboard and announces it is disabling IDE DMA, once the system boots however, hdparm returns USING_DMA is enabled, and any attempt at large file copies will result in the system freezing, and the IDE subsystem locked. Problem with the initscripts is rc.sysinit. It specifically checks to make sure that USE_DMA from /etc/sysconfig/harddisks is a non blank or 0 entry... Meaning you cannot override through /etc/sysconfig/harddisks by setting USE_DMA=0... It simply will not be passed through. Reproducible: Always Steps to Reproduce: 1.Attempt to copy a large (500+ meg file) on a KT7 motherboard using standard install 2.System locks, if you are in console mode, you will get IDE seekscan errors and CRC Checksum errors 3.Disable USE_DMA for drive and problem goes away Actual Results: 1&2: Corrupted root partition, and partially copied data 3: System has stabalized even while copying large amounts of data Expected Results: Setting USE_DMA=0 in /etc/sysconfig/harddisks SHOULD have forced hdparm to set USE_DMA to off, overriding defaults. Instead, it ignores USE_DMA= or USE_DMA=0 and accepts defaults. Defaults on the KT7 system is USE_DMA=1 resulting in file system corruption. This script change fixes rc.sysinit to at least allow me to override the system and manually disable USE_DMA, but there is still an underlying problem in why the kernel announced: KT7 series board detected. Disabling IDE DMA. Yet, the USE_DMA mode was still enabled.... Modified section of rc.sysinit looks like... if [ -n "$USE_DMA" ]; then HDFLAGS[$device]="${HDFLAGS[$device]} -q -d$USE_DMA" fi
I don't see how what you said happen can happen in initscripts; if you don't have USE_DMA set to non-zero, the initscripts will *not* turn it on.
The problem is not that the initscripts "turn it on". The problem comes from the fact that left to itself the drive defaults to USE_DMA = true. That is where the corruption comes from. The script checks /etc/sysconfig/harddisks and only performs the -d option if USE_DMA is not blank or not 0. A quick summary, /dev/hda is defaulting to DMA on, it's corrupting data, rc.sysinit does not honor (as installed) a request in /etc/sysconfig/harddisks to disable DMA mode.
OK, I see. This is fixed in CVS, will be in 5.84-1 when it's released. You might want to open a bug on the kernel as to it getting enabled when it's supposedly disabled.