More ata/UDMA disk write questions

Louis LeBlanc FreeBSD at
Mon Sep 20 13:03:32 PDT 2004

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

* The Intel ICH5 controller is listed as supported in ata(4), and in
  the 4.10 hardware list
  but not in the 5.2.1 hardware list
  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

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

Any thoughts, pointers, etc. on ata, atacontrol, UDMA150 support, etc.
would be appreciated.

Louis LeBlanc               FreeBSD at
Fully Funded Hobbyist, KeySlapper Extrordinaire :)                     Ô¿Ô¬

share, n.:
  To give in, endure humiliation.

More information about the freebsd-questions mailing list