From owner-svn-src-all@FreeBSD.ORG Thu Mar 22 14:14:46 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C2ED1065670; Thu, 22 Mar 2012 14:14:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 702798FC17; Thu, 22 Mar 2012 14:14:45 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2MEEbYR015702; Thu, 22 Mar 2012 16:14:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2MEEa4i063855; Thu, 22 Mar 2012 16:14:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2MEEaTk063854; Thu, 22 Mar 2012 16:14:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Mar 2012 16:14:36 +0200 From: Konstantin Belousov To: John Baldwin Message-ID: <20120322141436.GC2358@deviant.kiev.zoral.com.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201203211502.14353.jkim@FreeBSD.org> <4F6AF1CB.80902@FreeBSD.org> <201203220748.49635.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gLcqQrOcczDba7nC" Content-Disposition: inline In-Reply-To: <201203220748.49635.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Jung-uk Kim , Andriy Gapon Subject: Re: svn commit: r233249 - head/sys/amd64/acpica X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:14:46 -0000 --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--