SATA READ_DMA timeouts - SOLVED?

Reid Linnemann lreid at cs.okstate.edu
Tue Sep 30 16:54:17 UTC 2008


Jeremy Chadwick wrote:
> (I'm not subscribed to freebsd-questions, so please CC me on replies.
> I'm also not sure how I ended up getting this mail in the first place;
> it looks like someone BCC'd my koitsu at freebsd.org address).
> 

Yes, I BCC'd you since you are maintaining a page on the wiki 
documenting SATA DMA problems.

> Furthermore, one of the most common reports on the FreeBSD lists is the
> exact opposite -- users complaining that "their disks are SATA300 but
> only operate at SATA150" (caused by that jumper).  Users are told to
> remove the jumper, and are reminded that the reason the jumper is
> enabled by default is said chipset incompatibilities.
> 
> That said, your mail confuses me for one reason:
> 
> Were you receiving DMA errors with the jumper REMOVED (e.g. SATA300
> operation), or with the jumper ENABLED (SATA150 operation)?  Your below
> description does not state what exactly you did with the jumper to make
> your drives work reliably, only "that the jumper capability on your
> disks was available".
> 

I should have been more clear.

My disks came with no cap on the SATA150 jumper, although FreeBSD 
reported that they were in SATA150 mode. The system would be unusable 
from READ_DMA timeouts if the system was ever powered off and brought 
back up. I had to do some voodoo of booting in single user mode with 
ACPI turned off to repair filesystems and rebuild my gmirror, then load 
ACPI and drop back into multi-user mode. I even had to do this if the 
system was powered off gracefully. So far, since I capped the jumpers 
this has not been the case. I still get them periodically if I do 
something like rebuild a gmirror component, so I can no longer say my 
problem is completely resolved.


More information about the freebsd-questions mailing list