Date: Mon, 20 Sep 2004 16:03:25 -0400 From: Louis LeBlanc <FreeBSD@keyslapper.org> To: FreeBSD Questions <freebsd-questions@FreeBSD.org> Subject: More ata/UDMA disk write questions Message-ID: <20040920200325.GB31158@keyslapper.org>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040920200325.GB31158>