Bug 36642 - 7.1 incorrectly disables DMA on KT7 Athlon system causing drive corruption
Summary: 7.1 incorrectly disables DMA on KT7 Athlon system causing drive corruption
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-19 13:25 UTC by Need Real Name
Modified: 2014-03-17 02:20 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-04-19 15:59:46 UTC

Attachments (Terms of Use)

Description Need Real Name 2001-04-19 13:25:43 UTC
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 15:46:33 UTC
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 15:59:42 UTC
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 16:06:40 UTC
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.