Bug 87678 - data corruption using Promise Ultra100 TX2
Summary: data corruption using Promise Ultra100 TX2
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-01 04:55 UTC by jim feldman
Modified: 2007-04-18 16:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-30 15:40:43 UTC

Attachments (Terms of Use)
system specifics (6.80 KB, text/plain)
2003-04-01 04:56 UTC, jim feldman
no flags Details

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):

How reproducible:

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

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.

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