Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Mar 2005 09:32:32 +0100
From:      Anthony Atkielski <atkielski.anthony@wanadoo.fr>
To:        freebsd-questions@freebsd.org
Subject:   Re: Serious issue with SATA disks again
Message-ID:  <88453814.20050320093232@wanadoo.fr>
In-Reply-To: <20050319112231.GA35477@Grumpy.DynDNS.org>
References:  <583197724.20050319103813@wanadoo.fr> <20050319112231.GA35477@Grumpy.DynDNS.org>

next in thread | previous in thread | raw e-mail | index | archive | help
David Kelly writes:

> Its impossible to _prove_ the software is _not_ at fault just as its
> impossible to prove the hardware is not at fault. When software works
> for others but not on your hardware then one can only conclude there is
> _something_ about your hardware.

It doesn't work for others.  I found lots of messages complaining about
this on various platforms, but no explanations.

> With seemingly random timeouts such as you are seeing I would suspect
> the SATA cable. SATA runs gigabits/sec and could be very sensitive. Try
> a different cable from another source.

I don't want suspicions, I want answers.  Who generates the message, and
exactly what does it mean?

I see the string in ata-queue.c, and references in a couple of other
modules, but as usual, there are no comments at all, so there's no way
to figure out what's going on.

> Also run the HD manufacturer's test utility.

I don't think Western Digital has one (?).  If it does, where can I find
it?

> "smartctl" from ports was also quite useful at reading the error log
> maintained by the HD firmware. Interesting reading, such as my drive
> temperature was 35, lifetime max/min was 19/45 (Celsius).

I tried running the offline self-test, but it didn't seem to do
anything.

> It means the driver asked the HD to fill a buffer, but it didn't
> complete the task within alloted time. Either the drive didn't begin, or
> data was lost and fell short.

Or there's a bug in the code.

> A few years ago one of my then-new machines could not write a floppy in
> FreeBSD but could in NT4. Tried lots of things, also got the attention
> of the floppy driver maintainer. A few weeks later got the idea to
> "Reset to Defaults" in the BIOS. Then reset the few specific things I
> needed back the way they were. Magic. There was something undocumented
> being set by BIOS at boot that didn't bother NT.

Or that NT was programmed to handle (i.e., a better driver in NT than in
FreeBSD).

> More recently, in 5.2.1, I had no problems with a parallel ATA drive
> with Hyperthreading enabled on my P4. No problems running sysinstall to
> prep the new SATA drives. But the SATA drives locked the kernel solid
> moments after first use. Disabled HT and all was fine. Something about
> HT and the new Geom framework used for SATA (but not for PATA, at least
> then) didn't work.

Or something about the way FreeBSD handled this situation contained a
bug.

-- 
Anthony




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88453814.20050320093232>