Date: Thu, 28 Jan 2010 22:08:08 +0200 From: Alexander Motin <mav@FreeBSD.org> To: pluknet <pluknet@gmail.com> Cc: freebsd-current@freebsd.org, Yamagi Burmeister <lists@yamagi.org> Subject: Re: Pack of CAM improvements Message-ID: <4B61EEA8.7030503@FreeBSD.org> In-Reply-To: <a31046fc1001281149o3ba48986ped8c68e0e76c59e4@mail.gmail.com> References: <4B55D9D4.1000008@FreeBSD.org> <alpine.OSX.2.00.1001232228180.2800@idate.home.yamagi.org> <alpine.BSF.2.00.1001281701530.29385@screw.home.yamagi.org> <4B61C688.2050609@FreeBSD.org> <a31046fc1001281149o3ba48986ped8c68e0e76c59e4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
pluknet wrote: > On 28 January 2010 20:16, Alexander Motin <mav@freebsd.org> wrote: >> Yamagi Burmeister wrote: >>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>> 00000000 >>> ahcich0: Timeout on slot 0 >> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. > > Sorry for hijacking your thread. > Can this help on my similar issue as well? It's hardly reproducible for me. > (it's reported while back: > http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053372.html) I am not sure. "ss ffffffff" there means that none of 32 sent NCQ commands are completed. So it may be a real timeout. But you may try it, if that virtual controller supports MSI at all and there is something to disable. The other possible option is to try AHCI_Q_EDGEIS quirk. It helps some controllers to avoid lost interrupts under high load. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B61EEA8.7030503>