Panic after update kernel
robert.moore at intel.com
Wed Mar 16 23:49:16 UTC 2011
The latest version of acpica released today (20110316) should fix this issue for you.
>From: Jung-uk Kim [mailto:jkim at FreeBSD.org]
>Sent: Wednesday, March 16, 2011 3:22 PM
>To: Andriy Gapon
>Cc: Ilya A. Arhipov; Moore, Robert; freebsd-acpi at freebsd.org
>Subject: Re: Panic after update kernel
>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 at freebsd.org <mailto:avg at 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.
More information about the freebsd-acpi