ad0: FAILURE - WRITE_DMA

[Neil Hoggarth]

On 8th October, Mikhail P. <miha at ghuug.org> reported the error:

ad0: FAILURE - WRITE_DMA status=51<READY,DSC,ERROR> error=10<NID_NOT_FOUND> LBA=268435455

On Sun, 10 Oct 2004, Søren Schmidt wrote:

> so that leaves the disks for scrutiny. One thing to try is change the
> tripping point where we switch from 28bit mode to 48 bit mode, could be
> a 1 off error in the firmware...

This sounds very possible to me. I have been experiencing the same
error, on a system that I've been trying to set up using 5.3-RC1 and
a new 160Gbyte SATA drives My hardware is:

atapci0: <SiI 3112 SATA150 controller> port 0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem 0xdf081000-0xdf0811ff irq 18 at device 11.0 on pci1
ad4: 152627MB <ST3160023AS/3.18> [310101/16/63] at ata2-master SATA150

(I notice that Michail and I both have Seagate drives ...).

I had problems with a filesystem on a partition which crossed the
LBA=268435455 threshold. After googling and reading this thread and
Søren's posting, I tried removing the filesystem and making a little
1000 sector partition which straddled the lba48 transition sector - I was
able to get read and write failure messages of the above form
reproducibly, by dd-ing between the test partition and /dev/zero.

I edited the /usr/src/sys/dev/ata/ata-lowlevel.c file and reduced the
48-bit trigger level by one:

--- ata-lowlevel.c.orig Fri Oct 29 12:06:09 2004
+++ ata-lowlevel.c      Fri Oct 29 12:05:38 2004
@@ -700,7 +700,7 @@
     ATA_IDX_OUTB(atadev->channel, ATA_ALTSTAT, ATA_A_4BIT);

     /* only use 48bit addressing if needed (avoid bugs and overhead) */
-    if ((lba > 268435455 || count > 256) && atadev->param &&
+    if ((lba > 268435454 || count > 256) && atadev->param &&
        atadev->param->support.command2 & ATA_SUPPORT_ADDRESS48) {

        /* translate command into 48bit version */

and built a new kernel (I'm using the stock GENERIC configuration).

The resulting kernel was able to dd to and from the test partition
without error. I've now created a new filesystem that uses this part
of the disk and restored the contents from backup, and have been
actively using the filesystem for the last day without observing any
further problems.

Regards,
-- 
Neil Hoggarth                                Departmental Computing Manager
<neil.hoggarth at physiol.ox.ac.uk>                   Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/                  University of Oxford, UK