More ata/UDMA disk write questions

From: Louis LeBlanc (FreeBSD_at_keyslapper.org)
Date: 09/20/04

  • Next message: Tom Connolly: "Resolution problems" 
    Date: Mon, 20 Sep 2004 16:03:25 -0400
To: FreeBSD Questions <freebsd-questions@FreeBSD.org>

    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.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
  • Next message: Tom Connolly: "Resolution problems"

    Relevant Pages