From jacke@valhalla.bofh.pl  Fri Sep 24 15:21:53 2004
Return-Path: <jacke@valhalla.bofh.pl>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1304616A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 24 Sep 2004 15:21:53 +0000 (GMT)
Received: from valhalla.bofh.pl (valhalla.bofh.org [80.55.205.181])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A9BA743D2F
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 24 Sep 2004 15:21:51 +0000 (GMT)
	(envelope-from jacke@valhalla.bofh.pl)
Received: from valhalla.bofh.pl (jacke@localhost.bofh.pl [127.0.0.1])
	by valhalla.bofh.pl (8.13.1/8.13.1) with ESMTP id i8OFLf33046041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Sep 2004 17:21:41 +0200 (CEST)
	(envelope-from jacke@valhalla.bofh.pl)
Received: (from jacke@localhost)
	by valhalla.bofh.pl (8.13.1/8.12.10/Submit) id i8OFLfhB046040;
	Fri, 24 Sep 2004 17:21:41 +0200 (CEST)
	(envelope-from jacke)
Message-Id: <200409241521.i8OFLfhB046040@valhalla.bofh.pl>
Date: Fri, 24 Sep 2004 17:21:41 +0200 (CEST)
From: Jakub Klausa <jacke@bofh.pl>
Reply-To: Jakub Klausa <jacke@bofh.pl>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Soren Schmidt <sos@DeepCore.dk>
Subject: Inconsistency of large files on RAID1 with HPT372.	
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         72062
>Category:       kern
>Synopsis:       Inconsistency of large files on RAID1 with HPT372.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 24 15:30:20 GMT 2004
>Closed-Date:    Tue Sep 28 09:43:07 GMT 2004
>Last-Modified:  Tue Sep 28 09:43:07 GMT 2004
>Originator:     Jakub Klausa
>Release:        FreeBSD 5.2.1-RELEASE-p8 i386
>Organization:
PRIVATE	
>Environment:
System: FreeBSD 5.3-BETA5
>Description:

A problem exists in the HPT372 driver probably, which causes unconsistency
while reading/writing large files (500M+?) off of RAID1 array. When 
reading/writing from/to a single disk connected to the very same controller 
(degraded array), everything works fine.

Tested on several KD7-RAID boards from Abit, with different disks.

ad4: 114498MB <SAMSUNG SV1203N/TQ100-23> [232632/16/63] at ata2-master UDMA100
ad6: 114498MB <SAMSUNG SV1203N/TQ100-23> [232632/16/63] at ata3-master UDMA100
ar0: 114498MB <ATA RAID1 array> [14596/255/63] status: READY subdisks:
 disk0 READY on ad4 at ata2-master
 disk1 READY on ad6 at ata3-master

[17:06:58] [ttypb] [101] off:jacke:/home/jacke# atacontrol cap 2 0
ATA channel 2, Master, device ad4:

Protocol              ATA/ATAPI revision 7
device model          SAMSUNG SV1203N
serial number         0727J2FW814861
firmware revision     TQ100-23
cylinders             16383
heads                 16
sectors/track         63
lba supported         234493056 sectors
lba48 supported       234493056 sectors
dma supported
overlap not supported

Feature                      Support  Enable    Value   Vendor
write cache                    yes      yes
read ahead                     yes      yes
dma queued                     no       no      0/0x00
SMART                          yes      no
microcode download             yes      yes
security                       yes      no
power management               yes      yes
advanced power management      no       no      0/0x00
automatic acoustic management  yes      no      0/0x00  254/0xFE

Behaves almost the same under RELENG_4.

>How-To-Repeat:

[17:10:34] [ttypc] [106] off:jacke:/var/ftp/incoming> repeat 2 md5 5.2.1-RELEASE-i386-disc*
MD5 (5.2.1-RELEASE-i386-disc1.iso) = f52f43819d7211d0370a0c652c15a8f1
MD5 (5.2.1-RELEASE-i386-disc2.iso) = 99d8a5925fd0b0bacb1365c80187a931
MD5 (5.2.1-RELEASE-i386-disc1.iso) = 9a1c764680504f5b7d2fb8c2d07de8e0
MD5 (5.2.1-RELEASE-i386-disc2.iso) = 2c53b627c9848f487d2feaf83b21f933
	
>Fix:

	Waiting for one ;>

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: sos 
State-Changed-When: Tue Sep 28 09:34:26 GMT 2004 
State-Changed-Why:  

You definitly have HW problems, I've hooked up a '372 here and have 
banged on it to no avail, it just works (se below). 
At any rate since UDMA uses CRC on the transfer from disk to memory 
you should be getting ICRC errors if there was corruption underways. 
Now since you dont state that, I'm 99.9% certain that your motherboard 
has severe busmaster problems. We have seen corruption issues like this 
before on badly designed boards, but it could also be a one of.  
Please try other controllers in there and check if that eventually works 
(experience shows that this makes a significant difference), you might be 
lucky to find a combo that works, but my advise would be to get the  
board RMA'd or maybe try a BIOS update. 

pizzabox> md5 * 
MD5 (xx_CD1.avi) = 13bd1c548bd540b82e5152bc29912094 
MD5 (xx_CD2.avi) = a7942d255f0500b7d1233695c56375b6 
MD5 (xx_CD3.avi) = 1d5517fa2ea2d2147bf74b7e95ca8d75 
MD5 (xx_CD4.avi) = ee0d00b76f584fa16367841174d74454 
pizzabox> md5 * 
MD5 (xx_CD1.avi) = 13bd1c548bd540b82e5152bc29912094 
MD5 (xx_CD2.avi) = a7942d255f0500b7d1233695c56375b6 
MD5 (xx_CD3.avi) = 1d5517fa2ea2d2147bf74b7e95ca8d75 
MD5 (xx_CD4.avi) = ee0d00b76f584fa16367841174d74454 
pizzabox> md5 * 
MD5 (xx_CD1.avi) = 13bd1c548bd540b82e5152bc29912094 
MD5 (xx_CD2.avi) = a7942d255f0500b7d1233695c56375b6 
MD5 (xx_CD3.avi) = 1d5517fa2ea2d2147bf74b7e95ca8d75 
MD5 (xx_CD4.avi) = ee0d00b76f584fa16367841174d74454 
pizzabox> md5 * 
MD5 (xx_CD1.avi) = 13bd1c548bd540b82e5152bc29912094 
MD5 (xx_CD2.avi) = a7942d255f0500b7d1233695c56375b6 
MD5 (xx_CD3.avi) = 1d5517fa2ea2d2147bf74b7e95ca8d75 
MD5 (xx_CD4.avi) = ee0d00b76f584fa16367841174d74454 


http://www.freebsd.org/cgi/query-pr.cgi?pr=72062 
>Unformatted:
