Date: Wed, 16 Mar 2011 16:49:14 -0700 From: "Moore, Robert" <robert.moore@intel.com> To: Jung-uk Kim <jkim@FreeBSD.org>, Andriy Gapon <avg@freebsd.org> Cc: "Ilya A. Arhipov" <micro@heavennet.ru>, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: RE: Panic after update kernel Message-ID: <4911F71203A09E4D9981D27F9D830858CAD03779@orsmsx503.amr.corp.intel.com> In-Reply-To: <201103161822.40131.jkim@FreeBSD.org> References: <20110316115254.59f8b6f7@heavennet.ru> <AANLkTinhLwcB=PO72vKHVcCfMireBXAoopG6SxrUdWNK@mail.gmail.com> <4D80D340.6080804@freebsd.org> <201103161822.40131.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
The latest version of acpica released today (20110316) should fix this issu= e for you. Bob >-----Original Message----- >From: Jung-uk Kim [mailto:jkim@FreeBSD.org] >Sent: Wednesday, March 16, 2011 3:22 PM >To: Andriy Gapon >Cc: Ilya A. Arhipov; Moore, Robert; freebsd-acpi@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@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?4911F71203A09E4D9981D27F9D830858CAD03779>