Red Hat Bugzilla – Bug 87678
data corruption using Promise Ultra100 TX2
Last modified: 2007-04-18 12:52:38 EDT
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
Version-Release number of selected component (if applicable):
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
Created attachment 90810 [details]
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
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.
mainboard is FIC 2013, bios JI4333 using the VP3 chipset
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
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/
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.