Date: Thu, 22 Mar 2012 15:13:28 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@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>, Andriy Gapon <avg@freebsd.org> Subject: Re: svn commit: r233249 - head/sys/amd64/acpica Message-ID: <201203221513.32171.jkim@FreeBSD.org> In-Reply-To: <201203220748.49635.jhb@freebsd.org> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 22 March 2012 07:48 am, John Baldwin wrote: > 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. FYI, I filed an upstream PR to track this issue: http://acpica.org/bugzilla/show_bug.cgi?id=950 Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203221513.32171.jkim>