Bug 29315

Summary: Promise ATA100 UDMA5 works incorrectly
Product: Base System Reporter: Chih-Chang Hsieh <cch>
Component: i386Assignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.3-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.dat
none
chkcp.sh none

Description Chih-Chang Hsieh 2001-07-30 03:40:01 UTC 
	When I copy a lager file about 600MB from the HD which
ataches on ATA100 to itself under UDMA5, the new copied file
is different from the original one (checked by md5). But when I
use sysctl to switch the ATA driver from dma mode to pio mode,
the same cp command works correctly. Is this the problem of
ata driver?

Fix: 

Sorry, I am not able to fix it.
How-To-Repeat: 
	Everytime when you copy a lager file about 600MB from the HD 
which ataches on ATA100 to itself under UDMA5 mode.
Comment 1 cch 2001-07-31 02:09:50 UTC 
I'm very sorry!
I have got another machine with the same hardware configuration
only with different number of hardisks.
It works correctly. Maybe it's a hardware problem.
I will do more tests.
Sorry for producing "noise".
Comment 2 Jonathan Chen freebsd_committer freebsd_triage 2001-08-02 21:00:03 UTC 
State Changed
From-To: open->feedback

Pending results from originator's tests.
Comment 3 kachun 2001-08-08 00:35:47 UTC 
In article <9kni83$11oj$1@FreeBSD.csie.NCTU.edu.tw>, you say...
> I have done several tests by the script in attachment.
> The results of these tests show that: (simply checked by "grep MD5
> chkcp.txt")
> 
> 1. Intel ICH2 ATA driver (UDMA5 mode) + Seagate-ST320413A -> OK
> please see:
> http://cc.kmu.edu.tw/~cch/FreeBSD/ata/intel-ich2-udma5-hd.txt
> 
> 2.Promise ATA100 driver (UDMA5 mode) + IBM-DTLA-307030 -> FAIL
> (It sometimes works correctly,  but incorrectly at most time.)
> please see: http://cc.kmu.edu.tw/~cch/FreeBSD/ata/promise-udma5-hd.txt
> [snip]

I believe this was the same problem described in:

  http://www.FreeBSD.org/cgi/query-pr.cgi?pr=29045

Plus, if the below article was correct...

http://groups.google.com/groups?hl=en&safe=off&th=127674b89a58577c,7&seekm=PaV9
7.311316%24XL1.5437943%40nlnews00.chello.com#p

then the problem was with the IBM-DTLA drives. That was what I was afraid of... 
we have quite a few of those drives.

The google article stated the data was always corrupted at the end of a 0x1000 
block. Will that offer some insight to the problem? It will be nice there is a 
work around beside running the drives at U33. I send an email to IBM harddrive 
support and see if they reply.

Regards
Comment 4 Jeroen Ruigrok van der Werven freebsd_committer freebsd_triage 2001-11-15 17:43:17 UTC 
State Changed
From-To: feedback->closed

The DTLA-307030 is a Deskstar 75GXP.  You have tripped the electronics 
failing.  Contact IBM to get a replacement.