Bug 87678 - data corruption using Promise Ultra100 TX2
data corruption using Promise Ultra100 TX2
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-31 23:55 EST by jim feldman
Modified: 2007-04-18 12:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
system specifics (6.80 KB, text/plain)
2003-03-31 23:56 EST, jim feldman
no flags Details

  None (edit)
Description jim feldman 2003-03-31 23:55:14 EST
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-03-31 23:56:53 EST
Created attachment 90810 [details]
system specifics
Comment 2 jim feldman 2003-04-03 01:18:23 EST
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 02:14:28 EST
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 01:30:12 EST
mainboard is FIC 2013, bios JI4333 using the VP3 chipset
Comment 5 Bugzilla owner 2004-09-30 11:40:43 EDT
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-07-31 23:22:42 EDT
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.