Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jan 2006 12:05:16 GMT
From:      Mike M <mmcg@yahoo.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   i386/91214: Disk corruption with Asus K8S-LA: board doesn't support UDMA133
Message-ID:  <200601021205.k02C5GHk078182@www.freebsd.org>
Resent-Message-ID: <200601021210.k02CA6MN044779@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         91214
>Category:       i386
>Synopsis:       Disk corruption with Asus K8S-LA: board doesn't support UDMA133
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 02 12:10:06 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Mike M
>Release:        6.0-RELEASE
>Organization:
>Environment:
6.0-RELEASE-GENERIC (from install CD)              
>Description:
Machine is an HP Pavilion a1007w - also sold as a Compaq Presario SR1511NX - running an athlon 64 3200+, 1G ram.  Memory is rock-solid.

/dev/ad0 is a Samsung SP1203N, which can run at UDMA133 with the right motherboard.

The motherboard is an Asus K8S-LA.  According to its documentation, it supports UDMA 33/66/100 - but not UDMA133.  Note that the controller itself (SiS 964) supports UDMA133.

When 6.0-CURRENT (GENERIC) boots, it sets the ad0 channel to UDMA133, which results in random disk write errors when the disk is under load - about 1 bit in 10000 is flipped (usually from 1 to 0) en route to the disk drive on my machine.  These errors usually won't show up until the system has been rebooted (hence memory cleared).  Note that there are no apparent read errors at this speed - the system can be rebooted multiple times after this, and reliably reads back the erroneous files (generates the same md5 sum every time).

Manually setting the device to UDMA100 (via atacontrol) cures the problem (though not any prior corruption).

The write corruption becomes orders of magnitude rarer if you are _only_ writing to the device (not simultaneously reading) - so there is a good chance that sysinstall will build a reasonably clean install, which will start to become corrupted immediately you boot multi-user.

Cheers :)

    Mike.

ps: Interestingly enough, there is a distinct pattern to the flipped bits (particular bits per 8-byte chunk are flipped hundreds of times more often than others) - this probably specific to my motherboard and/or drive terminators.


>How-To-Repeat:
Create a random binary file, around 2G
Set ata mode to UDMA6
Copy the file
Diff the two files
>Fix:
To get a clean FreeBSD install on a new machine: temporarily install a 40-wire IDE cable, install system, compile or configure kernel to force UDMA100, replace 80-wire cable.

>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601021205.k02C5GHk078182>