Panic after update kernel

[Moore, Robert]

The latest version of acpica released today (20110316) should fix this issue for you.

Bob


>-----Original Message-----
>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.
>
>JK