Date: Tue, 14 Feb 2012 12:00:07 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Victor Balada Diaz <victor@bsdes.net> Cc: freebsd-stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 Message-ID: <4F3A30A7.1000601@FreeBSD.org> In-Reply-To: <mailpost.1329211201.7519916.54394.mailing.freebsd.stable@FreeBSD.cs.nctu.edu.tw> References: <mailpost.1329211201.7519916.54394.mailing.freebsd.stable@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/14/12 11:19, Victor Balada Diaz wrote: > We're having some troubles with AHCI under FreeBSD 8.2 and 8-STABLE. The error is: > > ahcich0: Timeout on slot 8 > ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr 00000000 > ahcich0: AHCI reset... > ahcich0: SATA connect time=0ms status=00000123 > ahcich0: ready wait time=18ms > ahcich0: AHCI reset done: device found > (ada0:ahcich0:0:0:0): Request requeued > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Command timed out > (ada0:ahcich0:0:0:0): Retrying command > ahcich0: Timeout on slot 8 > ahcich0: is 00000000 cs 007ff000 ss 007fff00 rs 007fff00 tfd c0 serr 00000000 > ahcich0: AHCI reset... > ahcich0: SATA connect time=0ms status=00000123 > ahcich0: ready wait time=84ms > ahcich0: AHCI reset done: device found > (ada0:ahcich0:0:0:0): Request requeued > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Command timed out > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Request requeued > [...] > > If we use old ATA driver we have no problems. If we just use the first disk (ada0) with ahci, > no problems either. If we use both disks (ada0 and ada1) in gmirror setup with ahci, we > got the above error. If we use both disks in gmirror with old ata driver, no problems. In both cases controller reports command status as 0xc0, that means device is busy with the command. For NCQ commands it means that device in in stage of processing command itself, not a head positioning or data transfer. Enabling AHCI enables NCQ for the devices. That increases load on both devices and the controller, and it is difficult to say who's fault is here. SAMSUNG HD154UI disks AFAIR have 4k sectors that may have big performance penalties when accessing small/misaligned data. I am not sure how big that penalty can be in the worst case, especially since disks by default cache writes, hiding the real load level. Relations with gmirror is harder to explain. Depending on how you created it and partitions it could cause more misaligned I/Os during rebuild. Using gmirror also double concurrent load on the controller, but at this point I have nothing to blame it for. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3A30A7.1000601>