Date: Thu, 22 Mar 2012 07:48:49 -0400 From: John Baldwin <jhb@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Jung-uk Kim <jkim@freebsd.org> Subject: Re: svn commit: r233249 - head/sys/amd64/acpica Message-ID: <201203220748.49635.jhb@freebsd.org> In-Reply-To: <4F6AF1CB.80902@FreeBSD.org> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, March 22, 2012 5:32:59 am Andriy Gapon wrote: > on 21/03/2012 21:02 Jung-uk Kim said the following: > > On Wednesday 21 March 2012 01:57 pm, Andriy Gapon wrote: > >> on 21/03/2012 19:41 Jung-uk Kim said the following: > >>> I am well aware of the problem. In fact, that's why I had to > >>> merge ACPICA 20120320 rather quickly, which added a new flag to > >>> not execute _GTS method. Both _GTS and _BFS are turned off by > >>> default. You can control them with a new tunable > >>> "debug.acpi.sleep_flags" if you want. > >> > >> But the bug still has to be fixed, right? > >> Even if it takes a non-default sysctl value to give the bug a > >> chance. > > > > Ideally, yes. However, I am not so sure if we can call it a "bug" > > because AcpiEnterSleepState() must be called with interrupt disabled > > and there is no way to change that API without breaking other OSes. > > We can only work around it locally or persuade upstream to find a > > better way to do this in ACPICA itself. Either way, it will be > > pretty hackish. :-( > > I see. Thank you. > Maybe the code could be somehow tricked into using M_NOWAIT in this context... That still wouldn't be good enough. We don't want to try to acquire any regular mutexes either (we can't safely block to let the lock owner run, or the lock owner might be a suspended thread on another CPU, etc.). The only proper way to fix this would be to use pre-allocated storage in this particular case, but given that Windows doesn't invoke these methods on suspend/resume, it's doubtful that we will ever need to do so. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203220748.49635.jhb>