Date: Tue, 14 Feb 2012 08:50:29 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Claudius Herder <claudius@ambtec.de> Cc: freebsd-stable@freebsd.org Subject: Re: problems with AHCI on FreeBSD 8.2 Message-ID: <20120214165029.GA1852@icarus.home.lan> In-Reply-To: <4F3A83DE.3000200@ambtec.de> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote:
>
> Hello,
>
> I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still
> persists on FreeBSD 9.0 release.
>
> Switching from ahci to ataahci resolved the problem for me too.
>
> I'm using gmirror for swap, system is on a zpool and the problem first
> occurred during a zpool scrub, but it is easily reproducible with dd.
>
> The timeouts only occur when writing to disks, dd if=/dev/ada{0|1}
> of=/dev/null is not an issue.
> Sometimes I need to power off the server because after a reboot one disk
> is still missing.
>
> I really would like to help in this issue, so let me know if you need
> any more information.
I find it interesting that, at least so far, the only people reporting
problems of this type with the ahci.ko driver are people using Samsung
disks. The only difference is that your models are F1s while the OPs
are F2s.
The only difference I can think of is that the ahci.ko driver may have
more strict timeouts than the ata driver (ata driver includes ataahci;
ataahci.ko != ahci.ko, as you know).
You may be able to adjust these using loader.conf variables:
kern.cam.ada.default_timeout
kern.cam.ada.retry_count
I also imagine that hint.ahci.X.ccc might have some involvement here,
but it's something I am not familiar with. mav@ would need to comment
on this -- it's outside of my familiarity scope.
Furthermore, in your case, your ada1 disk has serious CRC-related
problems, and your ada0 disk has seen similar just at a much lower rate.
ada1 should probably be replaced (along with cables, dusting out SATA
ports, etc.), but keeping ada0 is probably fine. The statistics for
these are shown in the "smartctl -l sataphy" output, field labelled ID
0x0001, "Command failed due to ICRC error". These are SATA-level
problems or physical problems which will manifest themselves as
anomalies during any kind of I/O.
The counters shown in ID 0x000a and 0x0009 are completely fine; these
don't indicate any problems.
Your drives don't support GP log region 0x04, which is why "smartctl -l
devstat" returns the errors it does. The errors you see coming from the
kernel in this situation are 100% okay/acceptable; the drive itself is
literally returning ABRT status to the inquiry submit to it. Different
drives from different vendors behave differently in this regard.
So, what I'm trying to say is, your problem looks different than the
OPs. Let's not start a big "I have this problem too" thread; that has
happened so many times over the years that when it happens I immediately
bow out + stop participating in the thread.
> smartctl -l sataphy /dev/ada0
>
> SATA Phy Event Counters (GP Log 0x11)
> ID Size Value Description
> 0x000a 2 150 Device-to-host register FISes sent due to a COMRESET
> 0x0001 2 3 Command failed due to ICRC error
> 0x0009 2 173 Transition from drive PhyRdy to drive PhyNRdy
>
> smartctl -l sataphy /dev/ada1
>
> SATA Phy Event Counters (GP Log 0x11)
> ID Size Value Description
> 0x000a 2 155 Device-to-host register FISes sent due to a COMRESET
> 0x0001 2 65535+ Command failed due to ICRC error
> 0x0009 2 178 Transition from drive PhyRdy to drive PhyNRdy
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120214165029.GA1852>