"ad0: TIMEOUT - WRITE_DMA" type errors with 7.0-RC1
koitsu at FreeBSD.org
Fri Jan 25 08:29:41 PST 2008
On Fri, Jan 25, 2008 at 08:58:41AM -0700, Joe Peterson wrote:
> I've seen mention of this kind of issue before, but I never saw a
> solution, except that someone reported that a certain version of 6.x
> seemed to make it go away - accounts of this problem are a bit vague. I
> am running 7.0-RC1, and I am seeing the errors periodically, and I am
> wondering if this is a known issue. Note that smartctl does not report
> errors logged and gives a "PASSED" to the drive. I am running at
> UDMA100 ATA. Also, if it matters, I am using ZFS.
What you've shown is usually the sign of a disk-related problem. It's
very obvious when it's just one disk reporting DMA errors. You use ZFS,
so chances are you have more than one disk in a pool/volume -- there's
no indication ad1, ad4, ad6, etc. are failing, so this seems to indicate
something specific to ad0.
Manufacturers pick very passive (non-aggressive) thresholds for error
conditions on disks, so disks which are failing very commonly show
"PASSED" during SMART analysis. To make matters worse, most users I
know read SMART stats incorrectly (they're easy to misinterpret).
Can you please provide output of the following:
* smartctl -a /dev/ad0
* atacontrol cap ad0
* atacontrol info <ata0, ata1, etc. -- any controller used by ZFS>
* Relevant dmesg output that indicates what kind of ATA controller
these disks are attached to. Start with output from 'ad0:' and
work backwards. For example, ad0 on this machine is using an Intel
atapci0: <Intel ICH6 SATA150 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.2 on pci0
ata0: <ATA channel 0> on atapci0
ad0: 238475MB <WDC WD2500KS-00MJB0 02.01C03> at ata0-master SATA150
SMART stats which are labelled "Offline" are only updated when a short
or long offline test is performed. Have you tried using "smartctl -t
short /dev/ad0" and "smartctl -t long /dev/ad0" to see if any of the raw
values on the far right column increment?
Have you tried using "zpool scrub" on the ZFS pool, then "zpool status"
to see if READ/WRITE/CHKSUM counters increment or if the "scrub" line
states there were errors?
Other things which have fixed problems in the past for others:
* BIOS updates
* Change of motherboards (sometimes replacing board with same model,
other times going with a completely different vendor (implies weird
implementation issues or BIOS problems))
* Changing SATA cables
* Getting a larger power supply (usually when lots of disk are involved)
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable