Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Nov 2011 15:45:26 +0100
From:      Joel Dahl <joel@vnode.se>
To:        Alexander Motin <mav@FreeBSD.org>
Cc:        "Bjoern A. Zeeb" <bz@FreeBSD.org>, freebsd-stable@freebsd.org
Subject:   Re: ATA/Cdrom(?) panic
Message-ID:  <20111116144526.GV83971@goofy01.vnodelab.local>
In-Reply-To: <4EC3C99C.8020203@FreeBSD.org>
References:  <alpine.BSF.2.00.1111160640370.4603@ai.fobar.qr> <4EC392DA.2030302@FreeBSD.org> <alpine.BSF.2.00.1111161414150.4603@ai.fobar.qr> <4EC3C99C.8020203@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 16-11-2011 16:33, Alexander Motin wrote:
> On 11/16/11 16:14, Bjoern A. Zeeb wrote:
> > On Wed, 16 Nov 2011, Alexander Motin wrote:
> > 
> >> 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.
> > 
> > So the bottom line of what you are saying is:
> > 1) it's hard to fix right in 8
> > 2) it's not an issue in 9 anymore at all?
> 
> Right.

Hmm. We're running many FreeBSD 8.2 machines as guests in VMware but have
never encountered the panic described above. Should I be worried?  :-)

-- 
Joel



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