Date: Wed, 16 Mar 2011 18:22:17 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: "Ilya A. Arhipov" <micro@heavennet.ru>, freebsd-acpi@freebsd.org, "Moore, Robert" <robert.moore@intel.com> Subject: Re: Panic after update kernel Message-ID: <201103161822.40131.jkim@FreeBSD.org> In-Reply-To: <4D80D340.6080804@freebsd.org> References: <20110316115254.59f8b6f7@heavennet.ru> <AANLkTinhLwcB=PO72vKHVcCfMireBXAoopG6SxrUdWNK@mail.gmail.com> <4D80D340.6080804@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 16 March 2011 11:12 am, Andriy Gapon wrote: > on 16/03/2011 16:18 Ilya A. Arhipov said the following: > > 2011/3/16 Andriy Gapon <avg@freebsd.org <mailto:avg@freebsd.org>> > > > > on 16/03/2011 10:52 Ilya A. Archipov said the following: > > > and see: > > > http://imm.io/4nzZ > > > > > > what information still needs to provide? > > > > 'bt' command output please (a screenshot is fine). > > > > -- > > Andriy Gapon > > > > > > boot: > > http://imm.io/4nTZ > > bt: > > http://imm.io/4nTS <-first > > http://imm.io/4nUd <-last > > So the panic is that we acquire a regular (non-spin) mutex in an > interrupt context. Not sure if this is a FreeBSD issue > (implementation of ACPI semaphore) or some ACPICA issue (e.g. doing > something wrong in an interrupt handler). > > Jung-uk, Robert, can you please take a look? _GL_ creates a semaphore and this semaphore is exclusively used in interrupt context. Also, it is always used to wait forever if it cannot acquire the necessary global lock. This is really bad for us because a semaphore requires a lock object to prevent sleeping forever without being waken up. Only workaround I can think of is to turn AcpiOsWaitSemaphore() & AcpiOsSignalSemaphore() into tsleep(9) & wakeup(9) because that's exactly what it wants to do, it seems. JK
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103161822.40131.jkim>