Date: Thu, 24 May 2001 15:06:37 -0700 (PDT) From: Richard Hodges <rh@matriplex.com> To: hackers@FreeBSD.ORG Subject: Knob for ATA maximum UDMA? Message-ID: <Pine.BSF.4.10.10105241440210.76082-100000@mail.matriplex.com>
next in thread | raw e-mail | index | archive | help
I was just testing out a new configuration, when I get two of
these about an hour apart, and then another today:
ts8 /kernel: ad4: READ command timeout tag=0 serv=0 - resetting
ts8 /kernel: ata2: resetting devices .. done
Needless to say, this is a problem. Here is the boot info:
ts8 /kernel: ad0: 29311MB <Maxtor 53073H6> [59554/16/63] at ata0-master UDMA66
ts8 /kernel: ad3: 29311MB <Maxtor 53073H6> [59554/16/63] at ata1-slave UDMA66
ts8 /kernel: ad4: 29311MB <Maxtor 53073H6> [59554/16/63] at ata2-master UDMA100
ts8 /kernel: ad5: 29311MB <Maxtor 53073H6> [59554/16/63] at ata2-slave UDMA100
The first two are on a VIA 82C686 bridge, the second two are HPT370.
I am wondering if UDMA100 is just too much for the cabling, and am
interested in finding out whether running them all at UDMA33 would
provide an extra safety margin.
I see in dev/ata/ata-dma.c, ata_dmainit() checks some cable flag, and
reduces the UDMA capability to UDMA33 if neccessary. This seems like
a decent place to hardwire it for testing. Is there any other place
that also needs to be changed?
If there actually is a difference in stability, would anyone favor
a new sysctl to put an arbitrary cap on the UDMA capabilities? As
far as I can tell, there should not be ANY performance difference
between UDMA100 and UDMA66, or even with UDMA33 if there is only
one drive per cable.
Comments and suggestions are appreciated :-)
-Richard
-------------------------------------------
Richard Hodges | Matriplex, inc.
Product Manager | 769 Basque Way
rh@matriplex.com | Carson City, NV 89706
775-886-6477 | www.matriplex.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10105241440210.76082-100000>