From owner-freebsd-acpi@freebsd.org Thu Sep 17 03:51:06 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F8669CEEFD for ; Thu, 17 Sep 2015 03:51:06 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCE311189 for ; Thu, 17 Sep 2015 03:51:05 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=to:from:subject:mime-version:content-type:content-transfer-encoding; s=smtpapi; bh=CKhzfl3S/FD2SlE6LAObWw2JjR8=; b=Z+unFzIsdqz5e3AjKT L5bl60CIXsno3rADtP5e4QGCoBMpjSsMb3PvYsqgWWQ0oBv2Y6bPv543W6cT8H3i M7vid2abRJN6wkaAquGU7oIRiIs2Ki7fHLPemJtu1tiwFXoLC9wSNHe5vAUKKh3S qhecd8CBsL3/KBMaPgzw+Hc4Q= Received: by filter-389.sjc1.sendgrid.net with SMTP id filter-389.26777.55FA38A633 2015-09-17 03:51:02.870555405 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id QBwifaJTRui0rrCSlkxS4w for ; Thu, 17 Sep 2015 03:51:02.591 +0000 (UTC) Received: (qmail 4116 invoked from network); 17 Sep 2015 03:51:00 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 17 Sep 2015 03:51:00 -0000 Received: (qmail 44691 invoked from network); 17 Sep 2015 03:49:28 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 17 Sep 2015 03:49:28 -0000 To: "freebsd-acpi@freebsd.org" From: Colin Percival Subject: disabling sleep when shutting down X-Enigmail-Draft-Status: N1110 Message-ID: <55FA3848.7090802@freebsd.org> Date: Wed, 16 Sep 2015 20:49:28 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCsbdiZynaa9pClUWubtrrDzYvA0YDVgBdXe/9 ub4NcbnY6K0onlwFovhH/U823ZXAsS3BbOdzAJVpDzDKipKLDCWywOwu9OmsCmLx9b9WifBE0ulCPn fVtwkYJfUF5OFmY= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 03:51:06 -0000 Hi ACPI people, I ran into an interesting glitch recently: I told my laptop to shut down, then closed the lid... and it promptly went into S3. When I opened the lid a couple days later, it resumed... and then finished the shutdown which it had started 2 days earlier. Meanwhile with two days of sitting in S3 instead of S5, the battery had almost completely drained. The obvious answer here is to disable Suspend if we're in the shutdown path. My first thought was to make rc.suspend slightly smarter, but that isn't good enough since there's a 10 second timeout after which the suspend will happen even if rc.suspend doesn't send the expected acknowledgment. So I think we need to get the kernel ACPI bits to disable Suspend. It looks to me like adding a sysctl to dev/acpica/acpi.c and checking it in acpi_ReqSleepState would work; then we just need a line in /etc/rc.shutdown to set the sysctl. But ACPI code scares me, so I figured I should check with you guys first... am I missing anything? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-acpi@freebsd.org Thu Sep 17 08:52:39 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2794D9CEB3E for ; Thu, 17 Sep 2015 08:52:39 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BFA3141A; Thu, 17 Sep 2015 08:52:38 +0000 (UTC) (envelope-from dan@obluda.cz) X-SubmittedBy: id 100000045929 subject /C=CZ/O=Univerzita+20Karlova+20v+20Praze/CN=Dan+20Lukes/unstructuredName=100000045929 issued by /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA+20Personal+20CA+202 auth type TLS.MFF Received: from [100.89.115.44] (ip-37-188-230-53.eurotel.cz [37.188.230.53]) (authenticated) by smtp1.ms.mff.cuni.cz (8.14.9/8.14.9) with ESMTP id t8H8qTYm047796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 17 Sep 2015 10:52:34 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: disabling sleep when shutting down To: Colin Percival , "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> From: Dan Lukes Message-ID: <55FA7F47.6050508@obluda.cz> Date: Thu, 17 Sep 2015 10:52:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <55FA3848.7090802@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 08:52:39 -0000 Colin Percival wrote: > I ran into an interesting glitch recently: I told my laptop to shut down, > then closed the lid... and it promptly went into S3. When I opened the > lid a couple days later, it resumed... and then finished the shutdown > which it had started 2 days earlier. Yes, it's well known behavior to me. > I think we need to get the kernel ACPI bits to disable Suspend. I consider it is suboptimal solution. I wish the suspend still happen if shutdown will not complete for any reason. All I want is that lid close doesn't trigger any action during shutdown. So what about hw.acpi.lid_switch_state just to be set to NONE during shutdown ? Dan From owner-freebsd-acpi@freebsd.org Thu Sep 17 11:31:33 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4A3C9CD98C for ; Thu, 17 Sep 2015 11:31:33 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BA3A19E7; Thu, 17 Sep 2015 11:31:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8HBVQnm034309; Thu, 17 Sep 2015 21:31:27 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 17 Sep 2015 21:31:26 +1000 (EST) From: Ian Smith To: Dan Lukes cc: Colin Percival , "freebsd-acpi@freebsd.org" Subject: Re: disabling sleep when shutting down In-Reply-To: <55FA7F47.6050508@obluda.cz> Message-ID: <20150917211219.M29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 11:31:33 -0000 On Thu, 17 Sep 2015 10:52:23 +0200, Dan Lukes wrote: > Colin Percival wrote: > > I ran into an interesting glitch recently: I told my laptop to shut down, > > then closed the lid... and it promptly went into S3. When I opened the > > lid a couple days later, it resumed... and then finished the shutdown > > which it had started 2 days earlier. > > Yes, it's well known behavior to me. News to me, but I never suspend on lid down .. well I tested it once. > > I think we need to get the kernel ACPI bits to disable Suspend. > > I consider it is suboptimal solution. I wish the suspend still happen if > shutdown will not complete for any reason. All I want is that lid close > doesn't trigger any action during shutdown. > > So what about hw.acpi.lid_switch_state just to be set to NONE during > shutdown ? That sounds sensible and likely much easier to accomplish. It needs to happen early enough in shutdown to beat the fastest of lid-slammers :) cheers, Ian From owner-freebsd-acpi@freebsd.org Thu Sep 17 19:47:46 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABCE99CF7A5 for ; Thu, 17 Sep 2015 19:47:46 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FE751BA4 for ; Thu, 17 Sep 2015 19:47:45 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=subject:to:references:cc:from:mime-version:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=BVESU7YFQkcXkulyXXz7lR2iF0Y=; b=mAKkhx7CIbizq9yc2b JnKNtgB6ExMtGDLcY6rpdufNzS9r4dd2iydcGHsvTfmj0fHFQtAawcNRcaevIPSC n94L8UkWHvTib06wIaxLlzRuA+zcdAeNOSYPVxKZhnbFepZXLg7tlWKGYVqG93Jb +WHSqvbZ5jr0gBX2dZ2THzEsw= Received: by filter0601p1mdw1.sendgrid.net with SMTP id filter0601p1mdw1.16686.55FB18DF13 2015-09-17 19:47:43.457740424 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id 8caVgGPySbubEIlTEZnUvw for ; Thu, 17 Sep 2015 19:47:43.543 +0000 (UTC) Received: (qmail 41188 invoked from network); 17 Sep 2015 19:47:40 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 17 Sep 2015 19:47:40 -0000 Received: (qmail 49265 invoked from network); 17 Sep 2015 19:46:07 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 17 Sep 2015 19:46:07 -0000 Subject: Re: disabling sleep when shutting down To: Ian Smith , Dan Lukes References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> Cc: "freebsd-acpi@freebsd.org" From: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <55FB187F.2090000@freebsd.org> Date: Thu, 17 Sep 2015 12:46:07 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150917211219.M29510@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCsY6W3IcldreKT8XAXWHzEg3dtBwSylw2s+qb xgDY+w+xS4tB0AcEDz+9aS81xaEpWnUxr0ZOUkqVnUKq+s/PhUNir0AqxcPnlFHN1Q2dQClkdFhigM BAxzSHglXPAkBBMKvjWQCdiBJMopa0jR2goq X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 19:47:46 -0000 On 09/17/15 04:31, Ian Smith wrote: > On Thu, 17 Sep 2015 10:52:23 +0200, Dan Lukes wrote: > > Colin Percival wrote: > > > I think we need to get the kernel ACPI bits to disable Suspend. > > > > I consider it is suboptimal solution. I wish the suspend still happen if > > shutdown will not complete for any reason. All I want is that lid close > > doesn't trigger any action during shutdown. This doesn't make any sense to me. If the shutdown fails, how likely is it that suspend will work? > > So what about hw.acpi.lid_switch_state just to be set to NONE during > > shutdown ? > > That sounds sensible and likely much easier to accomplish. It needs to > happen early enough in shutdown to beat the fastest of lid-slammers :) I considered that option but thought that disabling suspend completely would be better in case it was triggered by something else -- for example, power management which autosuspends based on battery level or inactivity. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-acpi@freebsd.org Thu Sep 17 20:31:58 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9440A9CEC82 for ; Thu, 17 Sep 2015 20:31:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 834901FF9; Thu, 17 Sep 2015 20:31:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 2A89517BF; Thu, 17 Sep 2015 20:31:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: disabling sleep when shutting down To: Colin Percival , "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> From: Jung-uk Kim Message-ID: <55FB233D.2080000@FreeBSD.org> Date: Thu, 17 Sep 2015 16:31:57 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FA3848.7090802@freebsd.org> Content-Type: multipart/mixed; boundary="------------040101010504090901040306" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:31:58 -0000 This is a multi-part message in MIME format. --------------040101010504090901040306 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/16/2015 23:49, Colin Percival wrote: > Hi ACPI people, > > I ran into an interesting glitch recently: I told my laptop to shut > down, then closed the lid... and it promptly went into S3. When I > opened the lid a couple days later, it resumed... and then finished > the shutdown which it had started 2 days earlier. Meanwhile with > two days of sitting in S3 instead of S5, the battery had almost > completely drained. > > The obvious answer here is to disable Suspend if we're in the > shutdown path. My first thought was to make rc.suspend slightly > smarter, but that isn't good enough since there's a 10 second > timeout after which the suspend will happen even if rc.suspend > doesn't send the expected acknowledgment. So I think we need to > get the kernel ACPI bits to disable Suspend. > > It looks to me like adding a sysctl to dev/acpica/acpi.c and > checking it in acpi_ReqSleepState would work; then we just need a > line in /etc/rc.shutdown to set the sysctl. But ACPI code scares > me, so I figured I should check with you guys first... am I missing > anything? Please try the attached patch. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV+yM4AAoJEHyflib82/FGxSUH/3Aw2bk+fDxyLIZHxidyxDRo jbNwkm8CIPGOOshQy8R/nMULPnCoVkLAuXA9O7rNK4G+PB96FoHHUEp/UoDnZfDF exINmGs6DM0scx2ioVtXM50+lC1SzMfFtb5VaS5t7lAyLwYFtE2bQaUWINethUW7 WpsJ5eyyyoMwTTnRxIQcaYC9I+8oqjC4W6KOO1VeTxaj8kvnacYtCxoXbEU7NHHX 9IprjpopHz9tNlTWuh+gX2SsgaRD7PhWSAekNcN1okYa6Jj1QGAiBIsNvc0GLmUZ hYv4GIPjxG1ZwYfu9HDCXp8Yiz3i44GIpC6EKuO2y0WO36DTM4vUYKK0OFjNdbw= =PVmk -----END PGP SIGNATURE----- --------------040101010504090901040306 Content-Type: text/x-patch; name="acpi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi.diff" Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 287922) +++ sys/dev/acpica/acpi.c (working copy) @@ -2574,10 +2574,9 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat if (!acpi_sleep_states[state]) return (EOPNOTSUPP); - /* If a suspend request is already in progress, just return. */ - if (sc->acpi_next_sstate != 0) { + /* If a reboot or suspend request is already in progress, just return. */ + if (rebooting || sc->acpi_next_sstate != 0) return (0); - } /* Wait until sleep is enabled. */ while (sc->acpi_sleep_disabled) { --------------040101010504090901040306-- From owner-freebsd-acpi@freebsd.org Thu Sep 17 21:39:55 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 395F79CEBAD for ; Thu, 17 Sep 2015 21:39:55 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C45F13C3; Thu, 17 Sep 2015 21:39:53 +0000 (UTC) (envelope-from dan@obluda.cz) X-SubmittedBy: id 100000045929 subject /C=CZ/O=Univerzita+20Karlova+20v+20Praze/CN=Dan+20Lukes/unstructuredName=100000045929 issued by /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA+20Personal+20CA+202 auth type TLS.MFF Received: from [172.20.1.29] (fw.ax.cz [77.240.102.126]) (authenticated) by smtp1.ms.mff.cuni.cz (8.14.9/8.14.9) with ESMTP id t8HLdckw079313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 17 Sep 2015 23:39:46 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: disabling sleep when shutting down To: Colin Percival , Ian Smith Cc: "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> From: Dan Lukes Message-ID: <55FB331A.4010908@obluda.cz> Date: Thu, 17 Sep 2015 23:39:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <55FB187F.2090000@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 21:39:55 -0000 Colin Percival wrote: > I considered that option but thought that disabling suspend completely > would be better in case it was triggered by something else You has been affected by LID issue - and here I'm with you. Suspend triggered by exhausted battery case needs to be evaluated carefully. Battery may be so exhausted so shutdown will not be completed. Note that some system (hardware) require no power to maintain suspend context, thus suspend may save system. And what about other reasons for suspends ? I can tell nothing about all those cases. Suspend may be triggered for any reason, thus so many possible causes. I can't claim all of them are illegitimate and can be safely ignored. I wish we should have stronger reason for system global behavior change than just feeling (no offense!). Just my $0.02. If system behavior will be changed, I will take it :-) Dan From owner-freebsd-acpi@freebsd.org Thu Sep 17 23:14:19 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B1829CF8E1 for ; Thu, 17 Sep 2015 23:14:19 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31E6519D5 for ; Thu, 17 Sep 2015 23:14:19 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=subject:to:references:from:mime-version:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=J0P1wN3L5CXd1k1+fwJMfJ+g/XQ=; b=N+cmF7FKQJLPnHMscI tChN0cTVLn1+Sjnn9rmLtctzeDW7BNgWbL/FIbmmmXvUgWKRgalJeLf2R8pKcgLt iwYXiDTmHbsy4IVhgCIJ/Y/QnDWnxp9SNYwqgc2acUFZ7SRXvu+9JX864Fmxt6Th OmprQNokum8GjiIn5cOp3yOpY= Received: by filter0504p1mdw1.sendgrid.net with SMTP id filter0504p1mdw1.27375.55FB494326 2015-09-17 23:14:11.459744336 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id B90NUccCT0u2HBua571owQ for ; Thu, 17 Sep 2015 23:14:11.523 +0000 (UTC) Received: (qmail 48385 invoked from network); 17 Sep 2015 23:14:08 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 17 Sep 2015 23:14:08 -0000 Received: (qmail 50125 invoked from network); 17 Sep 2015 23:12:35 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 17 Sep 2015 23:12:35 -0000 Subject: Re: disabling sleep when shutting down To: Jung-uk Kim , "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> From: Colin Percival X-Enigmail-Draft-Status: N1010 Message-ID: <55FB48E3.20401@freebsd.org> Date: Thu, 17 Sep 2015 16:12:35 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55FB233D.2080000@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCsiuhUvctHCO607hi8lR6x4yjaZe+LDNaLU+I lJcdGQpUf3Kl0tI9xyyY/zQfsQaGloR9gVKxiwJcp2sZltyeGDCSdPtkpxLAHV/P6KiO33yjZjRHx+ zo3i9JIg06rFyMzfF6S3ZbWhjYRJyALjIJLO X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 23:14:19 -0000 On 09/17/15 13:31, Jung-uk Kim wrote: > On 09/16/2015 23:49, Colin Percival wrote: >> I ran into an interesting glitch recently: I told my laptop to shut >> down, then closed the lid... and it promptly went into S3. When I >> opened the lid a couple days later, it resumed... and then finished >> the shutdown which it had started 2 days earlier. > > Please try the attached patch. No, this doesn't do what I wanted. It might be a good idea anyway, but your patch only disables suspend once the kernel is trying to reboot; what I want is to disable suspend a bit earlier -- once rc.shutdown is running and the userland is trying to shut down, because at that point unless something breaks horribly we're *about to* tell the kernel to shut down even though we haven't gotten there quite yet. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-acpi@freebsd.org Thu Sep 17 23:24:35 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B49C9CFF6A for ; Thu, 17 Sep 2015 23:24:35 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11A9E1E60 for ; Thu, 17 Sep 2015 23:24:34 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=subject:to:references:cc:from:mime-version:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=zoaAe2tZeYIkl9Kk+FljaZfbE2s=; b=c+pescJtPxPmv+sqm0 lM4HsgLELwzCO5R8EE+iJJq1Ptq3x12FDpSgRgakEclwszN/jHMRb/9P65B8CGsW Ihdc+7mM6JHhUha9MlCVFiyYNSD7d23tWGqrZCvXX6wkfif9UL5qMF2uMlDHP5bM 7kfLjv7kd+iaipCDq7Hm4gTRs= Received: by filter0643p1mdw1.sendgrid.net with SMTP id filter0643p1mdw1.8650.55FB4BB0B 2015-09-17 23:24:32.177003854 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id SYKS_HrUSMOWDVxSQeD6hA for ; Thu, 17 Sep 2015 23:24:32.266 +0000 (UTC) Received: (qmail 48744 invoked from network); 17 Sep 2015 23:24:29 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 17 Sep 2015 23:24:29 -0000 Received: (qmail 50156 invoked from network); 17 Sep 2015 23:22:55 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 17 Sep 2015 23:22:55 -0000 Subject: Re: disabling sleep when shutting down To: Dan Lukes , Ian Smith References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> <55FB331A.4010908@obluda.cz> Cc: "freebsd-acpi@freebsd.org" From: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <55FB4B4F.2080700@freebsd.org> Date: Thu, 17 Sep 2015 16:22:55 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55FB331A.4010908@obluda.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCtpxtdtzD42i4YSLVNknqyRAGwXrZMyRrGJYN f3YTL+QBq4Z0kBlJIZOt2U1o0vbuBUrqKu9sjvfGLqFGOFrDT+WctyP+FuJQhqX/VIX517MAch/yzm pcNnP8VcCeAryUU= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 23:24:35 -0000 On 09/17/15 14:39, Dan Lukes wrote: > Colin Percival wrote: >> I considered that option but thought that disabling suspend completely >> would be better in case it was triggered by something else > > You has been affected by LID issue - and here I'm with you. Ok. But adjusting the sysctl might not be enough; KDE has a "suspend when lid closed" setting which seems to be broken right now, but if it worked we would need to figure out how to disable that as well. > Suspend triggered by exhausted battery case needs to be evaluated > carefully. Battery may be so exhausted so shutdown will not be > completed. Note that some system (hardware) require no power to maintain > suspend context, thus suspend may save system. > > And what about other reasons for suspends ? I can tell nothing about all > those cases. Suspend may be triggered for any reason, thus so many > possible causes. I can't claim all of them are illegitimate and can be > safely ignored. I wish we should have stronger reason for system global > behavior change than just feeling (no offense!). The example of a system which can usefully suspend but doesn't have enough battery life left to allow it to complete a normal shutdown seems a bit implausible, but I'll concede that it's theoretically possible. Maybe we should have an rc.d script which checks an rc.conf setting? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-acpi@freebsd.org Fri Sep 18 07:51:29 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 608889CF9D6 for ; Fri, 18 Sep 2015 07:51:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B95F11CF9; Fri, 18 Sep 2015 07:51:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8I7pGKt076251; Fri, 18 Sep 2015 17:51:17 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 18 Sep 2015 17:51:16 +1000 (EST) From: Ian Smith To: Colin Percival cc: Dan Lukes , jkim@freebsd.org, "freebsd-acpi@freebsd.org" Subject: Re: disabling sleep when shutting down In-Reply-To: <55FB4B4F.2080700@freebsd.org> Message-ID: <20150918161310.U29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> <55FB331A.4010908@obluda.cz> <55FB4B4F.2080700@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 07:51:29 -0000 On Thu, 17 Sep 2015 16:22:55 -0700, Colin Percival wrote: > On 09/17/15 14:39, Dan Lukes wrote: > > Colin Percival wrote: > >> I considered that option but thought that disabling suspend completely > >> would be better in case it was triggered by something else > > > > You has been affected by LID issue - and here I'm with you. > > Ok. But adjusting the sysctl might not be enough; KDE has a "suspend > when lid closed" setting which seems to be broken right now, but if it > worked we would need to figure out how to disable that as well. If our KDE isn't using FreeBSD methods to manage suspend and/or shutdown (given it's generally pretty linux-centric), presumably acpiconf -S{3,5} or in the case of shutdown, perhaps invoking 'shutdown -p now [message]' then that's a separate issue that needs fixing in KDE. I wouldn't even consider trawling through KDE power management code, if I could find it. I think Dan's right, deal with the LID issue by disabling suspend-on-lid in shutdown.c, which needs adding a sysctl handler for it, and just set it to 'NONE' after validating options etc. This won't need to consider any of the other possible circumstances, just disabling a convenience. And then there's what type of shutdown has been issued? -p powerdown? -r reboot? -h halt? No switches to drop to single user? With any delay, or 'now'? And there's the chance that someone has set hw.acpi.disable_on_reboot .. things could get messy, but early disabling of hw.acpi.lid_switch_state sounds pretty safe to me, and you can see by LEDs if the system hasn't suspended after closing the lid, or whether it's shut down, or rebooted. > > Suspend triggered by exhausted battery case needs to be evaluated > > carefully. Battery may be so exhausted so shutdown will not be > > completed. Note that some system (hardware) require no power to maintain > > suspend context, thus suspend may save system. My X200 runs for something like a week suspended from full charge, but I do miss the control APM offered, running scripts at every 10% graduation and on critical low power, charging or discharging. I've managed to get devd to run a script on CMBAT events that logs (among other things) the battery state via acpiconf -i0. The X200 does so on power loss/returned and at 80% and 20%, charging or discharging, but I've yet to add code to parse those looking for capacity less than say 10% to invoke suspend, or critical low power to invoke shutdown, but it's functionality I'd like. > > And what about other reasons for suspends ? I can tell nothing about all > > those cases. Suspend may be triggered for any reason, thus so many > > possible causes. I can't claim all of them are illegitimate and can be > > safely ignored. I wish we should have stronger reason for system global > > behavior change than just feeling (no offense!). > > The example of a system which can usefully suspend but doesn't have enough > battery life left to allow it to complete a normal shutdown seems a bit > implausible, but I'll concede that it's theoretically possible. Maybe we > should have an rc.d script which checks an rc.conf setting? Well I think this has shown there are plenty of possible conditions to consider and possible races to avoid, going down that path. Disabling hw.acpi.lid_switch_state would seem to solve your original problem without needing to mess with ACPI, until such scenarios are examined? cheers, Ian From owner-freebsd-acpi@freebsd.org Fri Sep 18 17:51:15 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D06FA9CF1AA for ; Fri, 18 Sep 2015 17:51:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEB591D85; Fri, 18 Sep 2015 17:51:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 68FC14650; Fri, 18 Sep 2015 17:51:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: disabling sleep when shutting down To: Colin Percival , "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> From: Jung-uk Kim Message-ID: <55FC4F13.3090603@FreeBSD.org> Date: Fri, 18 Sep 2015 13:51:15 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FB48E3.20401@freebsd.org> Content-Type: multipart/mixed; boundary="------------080505010706070807030101" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 17:51:16 -0000 This is a multi-part message in MIME format. --------------080505010706070807030101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/17/2015 19:12, Colin Percival wrote: > On 09/17/15 13:31, Jung-uk Kim wrote: >> On 09/16/2015 23:49, Colin Percival wrote: >>> I ran into an interesting glitch recently: I told my laptop to >>> shut down, then closed the lid... and it promptly went into S3. >>> When I opened the lid a couple days later, it resumed... and >>> then finished the shutdown which it had started 2 days >>> earlier. >> >> Please try the attached patch. > > No, this doesn't do what I wanted. It might be a good idea anyway, > but your patch only disables suspend once the kernel is trying to > reboot; what I want is to disable suspend a bit earlier -- once > rc.shutdown is running and the userland is trying to shut down, > because at that point unless something breaks horribly we're *about > to* tell the kernel to shut down even though we haven't gotten > there quite yet. Okay. The attached patch is a quick-and-dirty & untested hack for you. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV/E8NAAoJEHyflib82/FGKB4IAJud2fy+GKB8XLnbKYDv7ftx WGB3RWXLCRkkSC41YtnVUJUeCWUmXdRpy6DWRQtQQIFvAgV1ZjjZiHQRJzRtKhKW spPXCUXU9LL7wnYpBWejH9EuH3+xtLLSPxM32eKVRmSgMGUcIse3Q/b2Ztf5yZC5 K0p60jmLvGaXrKgf99tyyX90UUhoJ1bABCVheNuMbf/UuWOJD0AytGDGrKGZckmS fLm8nPQIYVJIC1Xsu3Av/EfmKgQpNoFGk7pDhQqf5glmC+jgzp4KElo7KA9ekq43 ybBusp8tfjY0LVRCoMB+K35KWku9puYLeBDm/2PygzOXOIzfkBC2F4dpfmDI3vY= =unIE -----END PGP SIGNATURE----- --------------080505010706070807030101 Content-Type: text/x-patch; name="acpi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi.diff" Index: etc/rc.shutdown =================================================================== --- etc/rc.shutdown (revision 287937) +++ etc/rc.shutdown (working copy) @@ -43,6 +43,9 @@ HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin export HOME PATH +# Temporarily block any suspend requests. +acpiconf -b 1 >/dev/null 2>&1 + . /etc/rc.subr load_rc_config 'XXX' @@ -109,5 +112,8 @@ fi # Insert other shutdown procedures here +# Unblock suspend requests. +acpiconf -b 0 >/dev/null 2>&1 + echo '.' exit 0 Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 287937) +++ sys/dev/acpica/acpi.c (working copy) @@ -98,6 +98,9 @@ struct callout acpi_sleep_timer; /* Bitmap of device quirks. */ int acpi_quirks; +/* Block suspend requests. */ +static int acpi_sleep_blocked; + /* Supported sleep states. */ static BOOLEAN acpi_sleep_states[ACPI_S_STATE_COUNT]; @@ -2574,10 +2577,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat if (!acpi_sleep_states[state]) return (EOPNOTSUPP); - /* If a suspend request is already in progress, just return. */ - if (sc->acpi_next_sstate != 0) { + /* + * If a reboot/shutdown/suspend request is already in progress + * or suspend is explicitly disabled, just return. + */ + if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked) return (0); - } /* Wait until sleep is enabled. */ while (sc->acpi_sleep_disabled) { @@ -3568,6 +3573,9 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t ad error = *(int *)addr; error = acpi_AckSleepState(sc->acpi_clone, error); break; + case ACPIIO_BLKSLPSTATE: + acpi_sleep_blocked = *(int *)addr; + break; case ACPIIO_SETSLPSTATE: /* DEPRECATED */ state = *(int *)addr; if (state < ACPI_STATE_S0 || state > ACPI_S_STATES_MAX) Index: sys/dev/acpica/acpiio.h =================================================================== --- sys/dev/acpica/acpiio.h (revision 287937) +++ sys/dev/acpica/acpiio.h (working copy) @@ -41,6 +41,9 @@ /* Allow suspend to continue (0) or abort it (errno). */ #define ACPIIO_ACKSLPSTATE _IOW('P', 5, int) +/* Allow suspend request (0) or block it. */ +#define ACPIIO_BLKSLPSTATE _IOW('P', 6, int) + struct acpi_battinfo { int cap; /* percent */ int min; /* remaining time (in minutes) */ Index: usr.sbin/acpi/acpiconf/acpiconf.8 =================================================================== --- usr.sbin/acpi/acpiconf/acpiconf.8 (revision 287937) +++ usr.sbin/acpi/acpiconf/acpiconf.8 (working copy) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd June 10, 2014 +.Dd September 18, 2015 .Dt ACPICONF 8 .Os .Sh NAME @@ -35,6 +35,7 @@ .Nd control ACPI power management .Sh SYNOPSIS .Nm +.Op Fl b Ar block .Op Fl h .Op Fl i Ar batt .Op Fl k Ar ack @@ -45,7 +46,10 @@ The utility allows the user control of the ACPI power management functions. The following command-line options are recognized: -.Bl -tag -width ".Fl s Ar type" +.Bl -tag -width ".Fl b Ar block" +.It Fl b Ar block +Block or unblock suspend requests using the argument provided. +.Sy Most users should not use this option directly. .It Fl h Displays a summary of available options. .It Fl i Ar batt Index: usr.sbin/acpi/acpiconf/acpiconf.c =================================================================== --- usr.sbin/acpi/acpiconf/acpiconf.c (revision 287937) +++ usr.sbin/acpi/acpiconf/acpiconf.c (working copy) @@ -77,6 +77,17 @@ acpi_sleep_ack(int err_val) err(EX_IOERR, "ack sleep type failed"); } +/* Block or unblock suspend requests. */ +static void +acpi_sleep_block(int block) +{ + int ret; + + ret = ioctl(acpifd, ACPIIO_BLKSLPSTATE, &block); + if (ret != 0) + err(EX_IOERR, "%sblock sleep failed", block ? "" : "un"); +} + /* should be a acpi define, but doesn't appear to be */ #define UNKNOWN_CAP 0xffffffff #define UNKNOWN_VOLTAGE 0xffffffff @@ -213,8 +224,11 @@ main(int argc, char *argv[]) sleep_type = -1; acpi_init(); - while ((c = getopt(argc, argv, "hi:k:s:")) != -1) { + while ((c = getopt(argc, argv, "b:hi:k:s:")) != -1) { switch (c) { + case 'b': + acpi_sleep_block(atoi(optarg)); + break; case 'i': acpi_battinfo(atoi(optarg)); break; --------------080505010706070807030101-- From owner-freebsd-acpi@freebsd.org Fri Sep 18 18:29:16 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC5B19CF5CD for ; Fri, 18 Sep 2015 18:29:16 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E1D11E3D for ; Fri, 18 Sep 2015 18:29:16 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1442600954; bh=7cBrkXdSqHHCnsr46RqDMyXSrX65sYwiGOjcrTp5DBs=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=i6xP/Ivo9Glp4Gs3u9yoUJ9Vw8+5hBP62crSHt2/myxGfZu9f1xh6BZig/ltcXkx5FviB6ATigyKJKeDCOHEH4jzVxhshqgLl4gzpa3+56xKGpmzgkWWri7PXMXO3KD+V9Mv/SwiSGZkeSWGHofdT05oTGQNIC+JlLPzc73QiXGADK3x2vY1NLGffMsemSWT/+J49CXcKlb5UPIF1uLR62cuMAqgOFUAwkIcYesdoeD6OFt7nTgH3YhRb24h9jjYqqPIfkPboxBk7qTk2gnLLfJNexwCIJhr2F2OLOo2oYur+LVrGotVL/SVN7vMZCkK0XAHp0Nh1QNCVJrKLT5kgw== Received: from [98.139.215.140] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2015 18:29:14 -0000 Received: from [68.142.230.72] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2015 18:29:14 -0000 Received: from [127.0.0.1] by smtp229.mail.bf1.yahoo.com with NNFMP; 18 Sep 2015 18:29:14 -0000 X-Yahoo-Newman-Id: 738282.84567.bm@smtp229.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BlrhLiMVM1lXX6zya5C7tozB_jf9nMo0qThVxfGuPTi6HJK mFMGa5qgDOKB559N.5ju61IEl.iATIFB5rhHGDybYDL8jILwHVPuoGS4f8jy KiNxLO5IVFpooG1jx5yQ6TZEZDJqwRjhTjcA.npImF4jmEILXniKmxWa1FIQ al_0GnMIlQGNu1MpRKhcHmLdjgnXZ.0y__XigCtp5.bkk7Q5s7dtxmp0N8Oz 3xhi88kp8Edskqaqzerhd1sDVfFOGU2jo4G.9g8Sa2G8LWQ4dGL9M6IgTxeq W5DUfL7_cY84sSx44HU7ncbx1l2HL.cIxKyljSmYIlsdAWTjbZ4YeNcKB412 35tNK7j8b5bcL4QwRXYFyTSs7WucelL2.ZV35KlxVYjsR6OOoPiU7wJiNIfK LKU3NHrH6vWR.rN4S50aOip8YqkQklAd0DPpLYZU1bEuzQ4Z1XNjpivp6Ke3 XiSp89yya8O82cysEOMQBxekt.epjG7c7XcShtY3cB1V3iVMtXFp1Xaa_bYV pxwYfdR0l80liAJcLliCtsTyuh5_9TevX X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- Subject: Re: disabling sleep when shutting down To: Jung-uk Kim , Colin Percival , "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> From: Anthony Jenkins Message-ID: <55FC57F9.3050702@yahoo.com> Date: Fri, 18 Sep 2015 14:29:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FC4F13.3090603@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 18:29:17 -0000 On 09/18/2015 01:51 PM, Jung-uk Kim wrote: > On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31, Jung-uk Kim wrote: > >> On 09/16/2015 23:49, Colin Percival wrote: > >>> I ran into an interesting glitch recently: I told my laptop to > >>> shut down, then closed the lid... and it promptly went into S3. > >>> When I opened the lid a couple days later, it resumed... and > >>> then finished the shutdown which it had started 2 days > >>> earlier. > >> > >> Please try the attached patch. > > > No, this doesn't do what I wanted. It might be a good idea anyway, > > but your patch only disables suspend once the kernel is trying to > > reboot; what I want is to disable suspend a bit earlier -- once > > rc.shutdown is running and the userland is trying to shut down, > > because at that point unless something breaks horribly we're *about > > to* tell the kernel to shut down even though we haven't gotten > > there quite yet. > > Okay. The attached patch is a quick-and-dirty & untested hack for you. > > Jung-uk Kim Is it possible for /etc/rc.shutdown to complete, but shutdown not occur? If so, there should be a mechanism to restore the ability to suspend. Other than that, I like it. -- Anthony Jenkins From owner-freebsd-acpi@freebsd.org Fri Sep 18 19:12:07 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B48D09D09B5 for ; Fri, 18 Sep 2015 19:12:07 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A48281488; Fri, 18 Sep 2015 19:12:07 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 3B8D84085; Fri, 18 Sep 2015 19:12:07 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: disabling sleep when shutting down To: Anthony Jenkins , Colin Percival , "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> From: Jung-uk Kim Message-ID: <55FC6206.8080303@FreeBSD.org> Date: Fri, 18 Sep 2015 15:12:06 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FC57F9.3050702@yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 19:12:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/18/2015 14:29, Anthony Jenkins wrote: > On 09/18/2015 01:51 PM, Jung-uk Kim wrote: >> On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31, >> Jung-uk Kim wrote: > >> On 09/16/2015 23:49, > Colin Percival wrote: > >>> I ran into an interesting glitch > recently: I told my laptop to > >>> shut down, then closed the > lid... and it promptly went into S3. > >>> When I opened the lid a > couple days later, it resumed... and > >>> then finished the > shutdown which it had started 2 days > >>> earlier. > >> > >> > Please try the attached patch. > > > No, this doesn't do what I > wanted. It might be a good idea anyway, > > but your patch only > disables suspend once the kernel is trying to > > reboot; what I > want is to disable suspend a bit earlier -- once > > rc.shutdown is > running and the userland is trying to shut down, > > because at > that point unless something breaks horribly we're *about > > to* > tell the kernel to shut down even though we haven't gotten > > > there quite yet. > > Okay. The attached patch is a quick-and-dirty > & untested hack for you. > > Jung-uk Kim > > Is it possible for /etc/rc.shutdown to complete, but shutdown not > occur? If so, there should be a mechanism to restore the ability > to suspend. Other than that, I like it. If something goes wrong, you can manually do "acpiconf -b 0". Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV/GIBAAoJEHyflib82/FGL9EH/jLI2o2LX+8TrHY+RzwkWvq7 SEXue/Fh0wkZvwUDerqgguWDB83X3xGkP2huWkcZEQ605br9FgFBnjVu2A1sPSw+ KBh20jiggv3pEd+3uJJGp6v8Mz33HRW7Se1xCajtZhadFgbqXMT5pxXkLjELheZb H2S2b7oStkZoSw89RLGzzX0DsakvbbXUPA4RUV7niCKPR2kSKpDqER/iY1+PGzYN 6M3EnwBNGWCxWYu+j+bMR/YqoK69DdY4RlHSRd08xleLif6LaDjOQpg/Gd22HMMR 6eEPIv96KAZbN25ZV7vmw4x8a1CrU1Glp6Lg0/Kuv0usCPfmeng1gtZZqirEr5c= =jWfB -----END PGP SIGNATURE----- From owner-freebsd-acpi@freebsd.org Fri Sep 18 20:32:23 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6AA69CF066 for ; Fri, 18 Sep 2015 20:32:23 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C71EB1D8F; Fri, 18 Sep 2015 20:32:22 +0000 (UTC) (envelope-from dan@obluda.cz) X-SubmittedBy: id 100000045929 subject /C=CZ/O=Univerzita+20Karlova+20v+20Praze/CN=Dan+20Lukes/unstructuredName=100000045929 issued by /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA+20Personal+20CA+202 auth type TLS.MFF Received: from [100.87.2.102] (ip-37-188-133-11.eurotel.cz [37.188.133.11]) (authenticated) by smtp1.ms.mff.cuni.cz (8.14.9/8.14.9) with ESMTP id t8IKVuid025684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Fri, 18 Sep 2015 22:32:16 +0200 (CEST) (envelope-from dan@obluda.cz) From: Dan Lukes Subject: Re: disabling sleep when shutting down To: Colin Percival , Ian Smith Cc: "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> <55FB331A.4010908@obluda.cz> <55FB4B4F.2080700@freebsd.org> Message-ID: <55FC74B6.4050601@obluda.cz> Date: Fri, 18 Sep 2015 22:31:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <55FB4B4F.2080700@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 20:32:23 -0000 Colin Percival wrote: > The example of a system which can usefully suspend but doesn't have enough > battery life left to allow tit to complete a normal shutdown seems a bit > implausible It's valid for in-kernel portion of shutdown only. But you wish to disable suspend even during userland part of shutdown. Such part is generic shell script and even worse, it include third party scripts. We can tell nothing generic about it. Of course, same apply to suspend as well. Thus is plausible that suspend may take just few seconds, but shutdown take substantially longer. But it's another day now, few hours of sleeping and your idea no longer sound as unacceptable to me as yesterday. As long as default system behavior will remain the same, I have nothing against a tool/method/way that will allow user to block S3 state anytime, including the userland portion of shutdown. It's up to system administrator to turn on such feature whenever he feel it helpful. Suspend triggered by LID I recognize special case - it's easy to evaluate consequences in full, thus I consider acceptable modification of the default system behavior. Just personal opinion ... Dan From owner-freebsd-acpi@freebsd.org Sat Sep 19 15:16:54 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AB84A051EB for ; Sat, 19 Sep 2015 15:16:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD86118E; Sat, 19 Sep 2015 15:16:52 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8JFGhjp041078; Sun, 20 Sep 2015 01:16:43 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 20 Sep 2015 01:16:43 +1000 (EST) From: Ian Smith To: Jung-uk Kim cc: Colin Percival , "freebsd-acpi@freebsd.org" Subject: Re: disabling sleep when shutting down In-Reply-To: <55FC4F13.3090603@FreeBSD.org> Message-ID: <20150920004041.J29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=------------080505010706070807030101 Content-ID: <20150920004041.U29510@sola.nimnet.asn.au> X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 15:16:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --------------080505010706070807030101 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20150920004041.B29510@sola.nimnet.asn.au> On Fri, 18 Sep 2015 13:51:15 -0400, Jung-uk Kim wrote: > On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31, Jung-uk Kim wrote: > >> On 09/16/2015 23:49, Colin Percival wrote: > >>> I ran into an interesting glitch recently: I told my laptop to > >>> shut down, then closed the lid... and it promptly went into S3. > >>> When I opened the lid a couple days later, it resumed... and > >>> then finished the shutdown which it had started 2 days > >>> earlier. > >> > >> Please try the attached patch. > > > > No, this doesn't do what I wanted. It might be a good idea anyway, > > but your patch only disables suspend once the kernel is trying to > > reboot; what I want is to disable suspend a bit earlier -- once > > rc.shutdown is running and the userland is trying to shut down, > > because at that point unless something breaks horribly we're *about > > to* tell the kernel to shut down even though we haven't gotten > > there quite yet. > > Okay. The attached patch is a quick-and-dirty & untested hack for you. That looks .. comprehensive, given that it's run when rc.shutdown is called by init(8), if I'm correctly following the train of events from shutdown through init (unless -o) and then halt(8) or reboot(8). Am I right assuming that if one ran say 'shutdown -p +2 [message]' then suspending would only be blocked after that interval has elapsed? And with 'shutdown [-p|-h|-r] now' is there any appreciable delay (like waiting on anything) before launching rc.shutdown? i.e. anything that aforesaid fast lid-slammer might beat? "Five minutes before shutdown, or immediately if shutdown is in less than 5 minutes, logins are disabled by creating /var/run/nologin and copying the warning message there." Guess I'm still wondering if blocking suspend from shutdown, perhaps in a similar timeframe, might better prevent suspend-during-shutdown? Aside perhaps, a point about acpiconf(8) I discovered tonight: every version of the man page since at least 5.5 states that S5 (soft off) is an option for -s. That was true at 5.5, however acpiconf.c at least from 8.2 through 9.3 to HEAD (checked just now) allows only S1 to S4. Noticed that because I was trying to find what else apart from shutdown, halt -p and the power button could initiate a poweroff halt. Are there other ways, apart from doing it like acpiconf does? cheers, Ian --------------080505010706070807030101 Content-Type: TEXT/X-PATCH; NAME=acpi.diff Content-ID: <20150920004041.P29510@sola.nimnet.asn.au> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=acpi.diff Index: etc/rc.shutdown =================================================================== --- etc/rc.shutdown (revision 287937) +++ etc/rc.shutdown (working copy) @@ -43,6 +43,9 @@ HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin export HOME PATH +# Temporarily block any suspend requests. +acpiconf -b 1 >/dev/null 2>&1 + . /etc/rc.subr load_rc_config 'XXX' @@ -109,5 +112,8 @@ fi # Insert other shutdown procedures here +# Unblock suspend requests. +acpiconf -b 0 >/dev/null 2>&1 + echo '.' exit 0 Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 287937) +++ sys/dev/acpica/acpi.c (working copy) @@ -98,6 +98,9 @@ struct callout acpi_sleep_timer; /* Bitmap of device quirks. */ int acpi_quirks; +/* Block suspend requests. */ +static int acpi_sleep_blocked; + /* Supported sleep states. */ static BOOLEAN acpi_sleep_states[ACPI_S_STATE_COUNT]; @@ -2574,10 +2577,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat if (!acpi_sleep_states[state]) return (EOPNOTSUPP); - /* If a suspend request is already in progress, just return. */ - if (sc->acpi_next_sstate != 0) { + /* + * If a reboot/shutdown/suspend request is already in progress + * or suspend is explicitly disabled, just return. + */ + if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked) return (0); - } /* Wait until sleep is enabled. */ while (sc->acpi_sleep_disabled) { @@ -3568,6 +3573,9 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t ad error = *(int *)addr; error = acpi_AckSleepState(sc->acpi_clone, error); break; + case ACPIIO_BLKSLPSTATE: + acpi_sleep_blocked = *(int *)addr; + break; case ACPIIO_SETSLPSTATE: /* DEPRECATED */ state = *(int *)addr; if (state < ACPI_STATE_S0 || state > ACPI_S_STATES_MAX) Index: sys/dev/acpica/acpiio.h =================================================================== --- sys/dev/acpica/acpiio.h (revision 287937) +++ sys/dev/acpica/acpiio.h (working copy) @@ -41,6 +41,9 @@ /* Allow suspend to continue (0) or abort it (errno). */ #define ACPIIO_ACKSLPSTATE _IOW('P', 5, int) +/* Allow suspend request (0) or block it. */ +#define ACPIIO_BLKSLPSTATE _IOW('P', 6, int) + struct acpi_battinfo { int cap; /* percent */ int min; /* remaining time (in minutes) */ Index: usr.sbin/acpi/acpiconf/acpiconf.8 =================================================================== --- usr.sbin/acpi/acpiconf/acpiconf.8 (revision 287937) +++ usr.sbin/acpi/acpiconf/acpiconf.8 (working copy) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd June 10, 2014 +.Dd September 18, 2015 .Dt ACPICONF 8 .Os .Sh NAME @@ -35,6 +35,7 @@ .Nd control ACPI power management .Sh SYNOPSIS .Nm +.Op Fl b Ar block .Op Fl h .Op Fl i Ar batt .Op Fl k Ar ack @@ -45,7 +46,10 @@ The utility allows the user control of the ACPI power management functions. The following command-line options are recognized: -.Bl -tag -width ".Fl s Ar type" +.Bl -tag -width ".Fl b Ar block" +.It Fl b Ar block +Block or unblock suspend requests using the argument provided. +.Sy Most users should not use this option directly. .It Fl h Displays a summary of available options. .It Fl i Ar batt Index: usr.sbin/acpi/acpiconf/acpiconf.c =================================================================== --- usr.sbin/acpi/acpiconf/acpiconf.c (revision 287937) +++ usr.sbin/acpi/acpiconf/acpiconf.c (working copy) @@ -77,6 +77,17 @@ acpi_sleep_ack(int err_val) err(EX_IOERR, "ack sleep type failed"); } +/* Block or unblock suspend requests. */ +static void +acpi_sleep_block(int block) +{ + int ret; + + ret = ioctl(acpifd, ACPIIO_BLKSLPSTATE, &block); + if (ret != 0) + err(EX_IOERR, "%sblock sleep failed", block ? "" : "un"); +} + /* should be a acpi define, but doesn't appear to be */ #define UNKNOWN_CAP 0xffffffff #define UNKNOWN_VOLTAGE 0xffffffff @@ -213,8 +224,11 @@ main(int argc, char *argv[]) sleep_type = -1; acpi_init(); - while ((c = getopt(argc, argv, "hi:k:s:")) != -1) { + while ((c = getopt(argc, argv, "b:hi:k:s:")) != -1) { switch (c) { + case 'b': + acpi_sleep_block(atoi(optarg)); + break; case 'i': acpi_battinfo(atoi(optarg)); break; --------------080505010706070807030101 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: <20150920004041.U29510@sola.nimnet.asn.au> Content-Description: Content-Disposition: INLINE _______________________________________________ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --------------080505010706070807030101--