Bug 87678

Summary: data corruption using Promise Ultra100 TX2
Product: [Retired] Red Hat Linux Reporter: jim feldman <jmf>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 7.3CC: trevor
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
system specifics none

Description jim feldman 2003-04-01 04:55:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i586; U;) Gecko/20020913

Description of problem:
when I create files of 100mb or larger, the data is corrupted.  I was attempting
to download an iso (knoppix), and could never get a copy that  agreed with the
md5sum.  I tried the same thing from a FreeBSD box (4.8 rc2) and got a good copy
first time.  when i tried to use either ftp or nfs to move the 678 mb file to
the RH box (from the bsd box), it would always have the correct byte count, but
wouldn't md5sum.  I then started using split to create smaller files.  Any split
under 100mb would work fine, 100 and greater would have bad data. I even moved
the 99mb files to the linux box and tried to reassemble them.  Again, a bad
check sum


Version-Release number of selected component (if applicable):
vmlinuz-2.4.18-27.7.x

How reproducible:
Always

Steps to Reproduce:
1.create a greater than 100mb file on another platfrom
2.md5sum the file
3.move file to problem system
4.sum the file again, and you won't get a match
    

Actual Results:  data corruption

Expected Results:  good data

Additional info:

Comment 1 jim feldman 2003-04-01 04:56:53 UTC
Created attachment 90810 [details]
system specifics

Comment 2 jim feldman 2003-04-03 06:18:23 UTC
I upgraded the bios of the promise card to 2.20, but the problem remains.
contacted promise, but they don't have any open problems with data corruption on
this bd.

Comment 3 jim feldman 2003-04-03 07:14:28 UTC
I couldn't boot using the ide=nodma bootparam.  It wouldn't init the controller.
 I did boot up all the way, and used "hdparm -d0 /dev/hdf" to turn off dma to
the 40 gig drive.  I then pulled the 678meg file over and it checksummed
correctly.  I then re-enabled dma "hdparm -d1 /dev/hdf", re-ran the md5sum, and
still got the correct value.  It seems that this driver/controller can't handle
large files using DMA during writes.  Needless to say, disabling DMA impacted
system performence drasticly.

BTW, I'm using the 40pin/80 wire ide cable for the drives.

Comment 4 jim feldman 2003-04-04 06:30:12 UTC
mainboard is FIC 2013, bios JI4333 using the VP3 chipset

Comment 5 Bugzilla owner 2004-09-30 15:40:43 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/


Comment 6 Trevor Cordes 2005-08-01 03:22:42 UTC
Anyone looking at this bug now (years later): I've been running an Ultra TX2 for
over a year with huge files and massive utilization and it's 100% rock solid.