From owner-freebsd-questions@FreeBSD.ORG Mon Sep 20 20:03:31 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB7BD16A4CE for ; Mon, 20 Sep 2004 20:03:31 +0000 (GMT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD8C43D45 for ; Mon, 20 Sep 2004 20:03:31 +0000 (GMT) (envelope-from leblanc@keyslapper.org) Received: from localhost ([68.160.146.60]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040920200330.PVMI8960.out008.verizon.net@localhost> for ; Mon, 20 Sep 2004 15:03:30 -0500 Received: from keyslapper.org (localhost [127.0.0.1]) by localhost (8.12.11/8.12.11) with ESMTP id i8KK3Q6h036157 for ; Mon, 20 Sep 2004 16:03:26 -0400 (EDT) (envelope-from leblanc@keyslapper.org) Received: (from leblanc@localhost) by keyslapper.org (8.12.11/8.12.11/Submit) id i8KK3PUQ036156 for freebsd-questions@FreeBSD.org; Mon, 20 Sep 2004 16:03:25 -0400 (EDT) (envelope-from leblanc) Date: Mon, 20 Sep 2004 16:03:25 -0400 From: Louis LeBlanc To: FreeBSD Questions Message-ID: <20040920200325.GB31158@keyslapper.org> Mail-Followup-To: FreeBSD Questions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6i X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [68.160.146.60] at Mon, 20 Sep 2004 15:03:27 -0500 Subject: More ata/UDMA disk write questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-questions@FreeBSD.org List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 20:03:32 -0000 Hey again everyone. I had a problem recently with "TIMEOUT - WRITE_DMA" errors, often followed by a complete lockup and data loss, sometimes enough to require a complete reinstall. There were a number of recommendations, some of which, however well intentioned, and definitely appreciated nonetheless, caused more trouble and not less. One thing that wasn't suggested was simply turning off write caching in the ata(4) driver itself. This is done by setting hw.ata.wc="0" in /boot/loader.conf. Well, I've read through the ata(4) manpage and the atacontrol(8) manpage a little more thoroughly, and looked at the /var/run/dmesg.boot log a lot more. I've noticed a couple things: * The ICH5 SATA 150 controller is correctly recognized as such by the kernel. * The Intel ICH5 controller is listed as supported in ata(4), and in the 4.10 hardware list (http://www.freebsd.org/releases/4.10R/hardware-i386.html#AEN34), but not in the 5.2.1 hardware list (http://www.freebsd.org/releases/5.2.1R/hardware-i386.html#AEN65). That's still a little confusing to me. And, the ICH5 SATA 150 controller is supposed to be capable of a 150M/sec transfer rate, but the atacontrol(8) manpage only mentions UDMA2 (aka UDMA33), UDMA4 (aka UDMA66), UDMA5 (aka UDMA100) and UDMA6 (aka UDMA133), which, if I understand these names right, don't provide the full 150M/s transfer rate. The atacontrol utility indicates the drive controller in question is currently using UDMA100. I'm not really familiar with these protocols/standards, so if anyone knows where a 25 cent tour of these can be found, I'd appreciate the pointer. Assuming I am correct about the meaning of the 33/66/100/133 values, does anyone on this list know if (or when) the ata driver will support the full 150M/s transfer rate? Is it possible that the ata(4) write caching could be incompatible with the disks hardware caching mechanisms? I've turned off hw.ata.wc, rebooted, and am currently executing a full port rebuild/reinstall (portupgrade -afR) which should be done some time next year (well, maybe tomorrow). So far so good. I'm going to guess that the disk activity incurred in this would be likely to indicate that the problem is either still around or has been fixed by turning off write caching. I have put the drive through a bios level diagnostic built into newer Dell MoBos (CTRL-ALT-D at the Dell startup logo) and it passed just fine. There is a WDC diagnostic tool I have downloaded and will find a way to use if this happens again, but I think the drive must be fine. Any thoughts, pointers, etc. on ata, atacontrol, UDMA150 support, etc. would be appreciated. Thanks Lou -- Louis LeBlanc FreeBSD@keyslapper.org Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ share, n.: To give in, endure humiliation.