Date: Thu, 22 Mar 2012 15:29:51 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "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>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r233249 - head/sys/amd64/acpica Message-ID: <201203221529.56045.jkim@FreeBSD.org> In-Reply-To: <20120322141436.GC2358@deviant.kiev.zoral.com.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203220748.49635.jhb@freebsd.org> <20120322141436.GC2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 22 March 2012 10:14 am, Konstantin Belousov wrote: > On Thu, Mar 22, 2012 at 07:48:49AM -0400, 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. > > I already noted this to Jung-uk, I think that current suspend > handling is (somewhat) wrong. We shall not stop other CPUs for > suspension when they are executing some random kernel code. Rather, > CPUs should be safely stopped at the kernel->user boundary, or at > sleep point, or at designated suspend point like idle loop. > > We already are engaged into somewhat doubtful actions like > restoring of %cr2, since we might, for instance, preemt page fault > handler with suspend IPI. And as I noted to you, a proper fix isn't trivial and I need help in this area. :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203221529.56045.jkim>