Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 36642 - 7.1 incorrectly disables DMA on KT7 Athlon system causing drive corruption
7.1 incorrectly disables DMA on KT7 Athlon system causing drive corruption
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-04-19 09:25 EDT by Need Real Name
Modified: 2014-03-16 22:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-19 11:59:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-04-19 09:25:43 EDT
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
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"
Comment 1 Bill Nottingham 2001-04-19 11:46:33 EDT
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.
Comment 2 Need Real Name 2001-04-19 11:59:42 EDT
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.
Comment 3 Bill Nottingham 2001-04-19 12:06:40 EDT
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.

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