Date: Thu, 22 Mar 2012 16:14:36 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> 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>, Jung-uk Kim <jkim@freebsd.org>, Andriy Gapon <avg@freebsd.org> Subject: Re: svn commit: r233249 - head/sys/amd64/acpica Message-ID: <20120322141436.GC2358@deviant.kiev.zoral.com.ua> In-Reply-To: <201203220748.49635.jhb@freebsd.org> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--gLcqQrOcczDba7nC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > > >=20 > > > Ideally, yes. However, I am not so sure if we can call it a "bug"=20 > > > because AcpiEnterSleepState() must be called with interrupt disabled= =20 > > > and there is no way to change that API without breaking other OSes. = =20 > > > We can only work around it locally or persuade upstream to find a=20 > > > better way to do this in ACPICA itself. Either way, it will be=20 > > > pretty hackish. :-( > >=20 > > I see. Thank you. > > Maybe the code could be somehow tricked into using M_NOWAIT in this=20 > context... >=20 > That still wouldn't be good enough. We don't want to try to acquire any= =20 > regular mutexes either (we can't safely block to let the lock owner run, = or=20 > the lock owner might be a suspended thread on another CPU, etc.). The on= ly=20 > proper way to fix this would be to use pre-allocated storage in this=20 > particular case, but given that Windows doesn't invoke these methods on= =20 > 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 %cr= 2, since we might, for instance, preemt page fault handler with suspend IPI. --gLcqQrOcczDba7nC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9rM8wACgkQC3+MBN1Mb4gnpQCeK/+dLY/ihNsbDZoK/vEN5j6D udkAoKxKG4zXP2TmK7igqhqlZARm1rfH =6gO6 -----END PGP SIGNATURE----- --gLcqQrOcczDba7nC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120322141436.GC2358>