Date: Wed, 16 Nov 2011 12:39:22 +0200 From: Alexander Motin <mav@FreeBSD.org> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: ATA/Cdrom(?) panic Message-ID: <4EC392DA.2030302@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1111160640370.4603@ai.fobar.qr> References: <alpine.BSF.2.00.1111160640370.4603@ai.fobar.qr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On 11/16/11 08:43, Bjoern A. Zeeb wrote: > we have seen this or a very similar panic for about 1 year now once in > a while and I think I reported it before; this is FreeBSD as guest on > vmware. Seems it was a double panic this time. Could someone please > see what's going on there? It was on 8.x-STABLE in the past and this > is 8.2-RELEASE-p4. The part of code reporting "completing request directly" is IMHO broken by design. It returns request completion before request will actually be completed by lower levels without any knowledge of what's going on there. There is kind of protection against double request completion, but it looks like not always working. May be because that part of code is not locked and nothing prevents that semaphore timeout and normal request timeout/completion to happen simultaneously. It is surprising to see even two traps same time, not sure what synchronized them so precisely. Simple removing that semaphore timeout is not an option, because it will cause deadlock when this wait happen within taskqueue thread that is used to handle requests completion and abort that wait. Avoid waiting inside taskqueue is also impossible without major rewrite. That's why ATA_CAM drops that code completely. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC392DA.2030302>