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:
Created attachment 90810 [details] system specifics
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.
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 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/
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.