Skip site navigation (1)Skip section navigation (2)
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>