From owner-freebsd-acpi@freebsd.org Sun Sep 20 07:18:04 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 9636BA05561 for ; Sun, 20 Sep 2015 07:18:04 +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 50C3F11C4 for ; Sun, 20 Sep 2015 07:18:03 +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=chFeEcboLQ0Gw9o3gMiw2j8v+xI=; b=qiBxqTNNjZvaIBGX3e 12asklk/Ex1P9k2TYSCviWiipTQ8OH9C49gJTO6yJVAfPyNypf7LBB/zVSa2ZyIx b0X4w/AdCMKG2YRqF8R6UrS+Br9YVFYoupXMSZYCkb0aLMf0iqCXFfMy8me41Xn4 LfhOOQ8HYjS2utaKHHsBwNdQg= Received: by filter0831p1mdw1.sendgrid.net with SMTP id filter0831p1mdw1.3147.55FE5DA41E 2015-09-20 07:17:56.776665799 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id zOvCbJIgRGi0mD_G8l8Mfw for ; Sun, 20 Sep 2015 07:17:56.918 +0000 (UTC) Received: (qmail 75025 invoked from network); 20 Sep 2015 07:17:51 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 20 Sep 2015 07:17:51 -0000 Received: (qmail 3942 invoked from network); 20 Sep 2015 07:16:36 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 20 Sep 2015 07:16:36 -0000 Subject: Re: disabling sleep when shutting down To: Anthony Jenkins , Jung-uk Kim , "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: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <55FE5D54.1030806@freebsd.org> Date: Sun, 20 Sep 2015 00:16:36 -0700 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-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCu1z2+lZELrw0J+Mht2L0+6OEDPLkCEslzGuc /N9aL+C9jIzPBUs9bROdkicJg0PtiDBT2x6dX/ss1ehRBpDelTYNE3lKnFF2QIBmk9wMFEh3A8eXNA QgjzFcufnftDGSk7Ra9d8IO0K/11PWTBYRck 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: Sun, 20 Sep 2015 07:18:04 -0000 On 09/18/15 11:29, Anthony Jenkins wrote: > 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. Hmm... well, rc.shutdown runs before the system drops into single-user mode. Which makes me think that maybe we should be making the kernel call from inside init instead of from rc.shutdown. -- 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 Sun Sep 20 10:04: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 618F5A05F50 for ; Sun, 20 Sep 2015 10:04: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 C9D15110B; Sun, 20 Sep 2015 10:04: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 t8KA4juh078785; Sun, 20 Sep 2015 20:04:46 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 20 Sep 2015 20:04:45 +1000 (EST) From: Ian Smith To: Colin Percival cc: Anthony Jenkins , Jung-uk Kim , "freebsd-acpi@freebsd.org" Subject: Re: disabling sleep when shutting down In-Reply-To: <55FE5D54.1030806@freebsd.org> Message-ID: <20150920194946.U29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@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: Sun, 20 Sep 2015 10:04:54 -0000 On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote: > On 09/18/15 11:29, Anthony Jenkins wrote: > > 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. > > Hmm... well, rc.shutdown runs before the system drops into single-user > mode. Which makes me think that maybe we should be making the kernel > call from inside init instead of from rc.shutdown. I still think disabling suspend from shutdown.c, at the same time as creating /var/run/nologin might be the best way to go, to avoid any possibility of untimely suspending once committed to shutting down. For one thing, shutdown's -o flag bypasses using init and calls halt or reboot directly, though I don't know if anyone uses that. For another, if shutdown fails for any reason, or is cancelled by signal by the user .. or in any case, I gather .. finish() removes /var/run/nologin, and could also there reenable suspend, covering Anthony's point. cheers, Ian From owner-freebsd-acpi@freebsd.org Tue Sep 22 08:26:38 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 4E8EDA037F7 for ; Tue, 22 Sep 2015 08:26:38 +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 A2B85113F for ; Tue, 22 Sep 2015 08:26:37 +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=IrDGZ6NmP8smITU/eS+PTBRrtRI=; b=bFggMClbH3NDEzM9nh i4fBt/hoDESz8cVomRw4AazsAE0EgiuZumB9ld0O4Pp/Fa3IVGt/UhXt01NnZ9IO Gmnzt/u2haQxdabffOjb58BhG2IU92W+RfoOlpoC2L0R3uqUBR2uHNrUZTvGZewK Y0Q4ayPwYoCORj3p6N3EgyZ0M= Received: by filter0423p1mdw1.sendgrid.net with SMTP id filter0423p1mdw1.24274.560110B528 2015-09-22 08:26:29.502083787 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id FPYAbwvTRMGfQVIBAP98Jw for ; Tue, 22 Sep 2015 08:26:29.337 +0000 (UTC) Received: (qmail 81452 invoked from network); 22 Sep 2015 08:26:21 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 22 Sep 2015 08:26:21 -0000 Received: (qmail 5792 invoked from network); 22 Sep 2015 08:26:27 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 22 Sep 2015 08:26:27 -0000 Subject: Re: disabling sleep when shutting down To: Ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <20150920194946.U29510@sola.nimnet.asn.au> Cc: Anthony Jenkins , Jung-uk Kim , "freebsd-acpi@freebsd.org" From: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <560110B3.6050401@freebsd.org> Date: Tue, 22 Sep 2015 01:26:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150920194946.U29510@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCvdSZrvh00wPTOBy8w92olYQHZKw4H458c7fK 8yTLbZhYuBUUk3cDI7Fvf2ryKqWA552xxkwogQvyMqVKpm8DMtCIASCIkgGcYtTcfFBIdq/XWyK3Ef jcRt/GC5Opo6913ZW2Uo4Afpd+AsdVSTiCRK 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: Tue, 22 Sep 2015 08:26:38 -0000 On 09/20/15 03:04, Ian Smith wrote: > On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote: > > On 09/18/15 11:29, Anthony Jenkins wrote: > > > 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. > > > > Hmm... well, rc.shutdown runs before the system drops into single-user > > mode. Which makes me think that maybe we should be making the kernel > > call from inside init instead of from rc.shutdown. > > I still think disabling suspend from shutdown.c, at the same time as > creating /var/run/nologin might be the best way to go, to avoid any > possibility of untimely suspending once committed to shutting down. So you think we should disable suspend for the last 5 minutes before a scheduled shutdown? This seems a bit strange to me... and I honestly can't imagine a situation where you'd need to announce an imminent shutdown of your laptop to logged-in users. > For one thing, shutdown's -o flag bypasses using init and calls halt or > reboot directly, though I don't know if anyone uses that. Right, I figured it wasn't worth worrying about that case since anyone who uses that hopefully knows what they're doing; also since that skips running rc.shutdown there's a much smaller race window. On the other hand, "send a signal to init" and the sysv compatible approach of running `init [runlevel]` are likely to be used by other tools (e.g., desktop environments), so I don't think we should assume that reboot/poweroff requests always go through shutdown(8). > For another, > if shutdown fails for any reason, or is cancelled by signal by the user > .. or in any case, I gather .. finish() removes /var/run/nologin, and > could also there reenable suspend, covering Anthony's point. This would also be accomplished by having the suspend-disabling done by init; if you tell shutdown(8) to not shut the system down, then it never sends the relevant signal to init. The shutdown(8) utility doesn't do any shutting down itself; it's just a front-end which makes an announcement, sets a timer, and disables logins, and then ultimately asks init(8) to do the real work (including spawning rc.shutdown). -- 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 Tue Sep 22 17:35:02 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 F15AAA069E4 for ; Tue, 22 Sep 2015 17:35:01 +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 DE3A11A27; Tue, 22 Sep 2015 17:35:01 +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 7586E69AC7; Tue, 22 Sep 2015 17:35:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: disabling sleep when shutting down To: Colin Percival , Anthony Jenkins , "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> <55FE5D54.1030806@freebsd.org> From: Jung-uk Kim Message-ID: <56019145.2070903@FreeBSD.org> Date: Tue, 22 Sep 2015 13:35:01 -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: <55FE5D54.1030806@freebsd.org> Content-Type: multipart/mixed; boundary="------------070003050204040408020807" 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: Tue, 22 Sep 2015 17:35:02 -0000 This is a multi-part message in MIME format. --------------070003050204040408020807 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/20/2015 03:16, Colin Percival wrote: > On 09/18/15 11:29, Anthony Jenkins wrote: >> 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. > > Hmm... well, rc.shutdown runs before the system drops into > single-user mode. Which makes me think that maybe we should be > making the kernel call from inside init instead of from > rc.shutdown. I didn't want to pollute init with arch-dependent hacks. Anyway, the attached patch should do what you want (not tested). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWAZFAAAoJEHyflib82/FGtJEIAIEd52nb4OaB51G4A/ygOvnR 71wooCMDS/6MJBGGptdOl3YEjVpN5rfuTTr+kxZrrvONjyTdxm15/Qp3usvuNpQQ 7dMYckAc8ZjT9tXGfHQIyG8gwhRgaE/jpPY25xKrExG8NfyEXvMzSjIlJprHZgtX JcqBLXjGKPhrbJbIBYs+7CeFKhKpPKBeiT2hAPtvHh1OfNi/J/3u5sDeEBeHkx05 dFNZ+sjGIAi/2GeEwrT0IFAfkE6+ecvVZUvYcTreYcMjsLAqwGHOG5GCX/RW50xn yU9Cu2EWM4Rj3Zet9rXsRajnco0s/tX5wc4oMuWVRakjDupkG17oih+PkpIAIKs= =q9E6 -----END PGP SIGNATURE----- --------------070003050204040408020807 Content-Type: text/x-patch; name="acpi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi.diff" Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 288120) +++ sbin/init/init.c (working copy) @@ -52,6 +52,10 @@ static const char rcsid[] = #include #include +#if defined(__amd64__) || defined(__i386__) +#include +#endif + #include #include #include @@ -1480,6 +1484,20 @@ alrm_handler(int sig) clang = 1; } +static void +block_sleep(int block) +{ +#if defined(__amd64__) || defined(__i386__) + int fd; + + fd = open("/dev/acpi", O_RDWR); + if (fd != -1) { + ioctl(fd, ACPIIO_BLKSLPSTATE, &block); + close(fd); + } +#endif +} + /* * Bring the system down to single user. */ @@ -1488,6 +1506,9 @@ death(void) { session_t *sp; + /* Temporarily block any suspend requests. */ + block_sleep(1); + /* * Also revoke the TTY here. Because runshutdown() may reopen * the TTY whose getty we're killing here, there is no guarantee @@ -1503,6 +1524,9 @@ death(void) /* Try to run the rc.shutdown script within a period of time */ runshutdown(); + /* Unblock suspend requests. */ + block_sleep(0); + return (state_func_t) death_single; } Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 288120) +++ 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 288120) +++ 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 288120) +++ usr.sbin/acpi/acpiconf/acpiconf.8 (working copy) @@ -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 288120) +++ 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; --------------070003050204040408020807-- From owner-freebsd-acpi@freebsd.org Tue Sep 22 19:13:40 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 526BCA07696 for ; Tue, 22 Sep 2015 19:13:40 +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 3E7651230; Tue, 22 Sep 2015 19:13:40 +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 CA782693F1; Tue, 22 Sep 2015 19:13:39 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim Subject: Re: disabling sleep when shutting down To: Colin Percival , Anthony Jenkins , "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> <55FE5D54.1030806@freebsd.org> Message-ID: <5601A863.5070406@FreeBSD.org> Date: Tue, 22 Sep 2015 15:13:39 -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: <55FE5D54.1030806@freebsd.org> Content-Type: multipart/mixed; boundary="------------000903080601040909000901" 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: Tue, 22 Sep 2015 19:13:40 -0000 This is a multi-part message in MIME format. --------------000903080601040909000901 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > On 09/20/2015 03:16, Colin Percival wrote: >> On 09/18/15 11:29, Anthony Jenkins wrote: >>> 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. >> >> Hmm... well, rc.shutdown runs before the system drops into >> single-user mode. Which makes me think that maybe we should be >> making the kernel call from inside init instead of from >> rc.shutdown. > > I didn't want to pollute init with arch-dependent hacks. Anyway, > the attached patch should do what you want (not tested). Or a simpler hack with sysctl(3) instead of ioctl(2). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWAag9AAoJEHyflib82/FGkmQH/2LM7+pCPkvCq4ljV3UMlLbc YhvVZYr2k/j6CwjknMC0e4trF9Owgwxstnt+T8HDiGuIO553zUFPDTfgKTredv2x UHn48KgyBupnmanT1rBmQs9zg1+yVsmUGl4YgNHTaSjDz6qEB9+Jc+OTMssqBYcP 3DujmU2HWD3XDm9M5hCxyAuzh6anolb/Ev2FePezz81D7atJJoc+yF34tm3Y/Fjh KSybphHzib78qzLsXhz3Tf1LKbdZVBHFobkCTOUovB9bM5YPCT7/8HXSa/TBbvEV 1HLnj9GJX1x5WZIu4ACcsUkmJ2YT/JIwTUcZemw0BvG0usSkZL/G1fdybfgctxk= =qmkC -----END PGP SIGNATURE----- --------------000903080601040909000901 Content-Type: text/x-patch; name="init.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="init.diff" Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 288123) +++ sbin/init/init.c (working copy) @@ -1487,7 +1487,18 @@ static state_func_t death(void) { session_t *sp; +#if defined(__amd64__) || defined(__i386__) + size_t len; + int block, blocked; + /* Temporarily block any suspend requests. */ + len = sizeof(blocked); + block = 1; + if (sysctlbyname("debug.acpi.sleep_blocked", &blocked, &len, + &block, sizeof(block)) == -1) + blocked = 0; +#endif + /* * Also revoke the TTY here. Because runshutdown() may reopen * the TTY whose getty we're killing here, there is no guarantee @@ -1503,6 +1514,13 @@ death(void) /* Try to run the rc.shutdown script within a period of time */ runshutdown(); +#if defined(__amd64__) || defined(__i386__) + /* Unblock suspend requests. */ + if (!blocked) + sysctlbyname("debug.acpi.sleep_blocked", NULL, NULL, + &blocked, sizeof(blocked)); +#endif + return (state_func_t) death_single; } Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 288123) +++ sys/dev/acpica/acpi.c (working copy) @@ -292,6 +292,11 @@ static int acpi_susp_bounce; SYSCTL_INT(_debug_acpi, OID_AUTO, suspend_bounce, CTLFLAG_RW, &acpi_susp_bounce, 0, "Don't actually suspend, just test devices."); +/* Block suspend requests. */ +static int acpi_sleep_blocked; +SYSCTL_INT(_debug_acpi, OID_AUTO, sleep_blocked, CTLFLAG_RW, + &acpi_sleep_blocked, 0, "Ignore any sleep requests."); + /* * ACPI can only be loaded as a module by the loader; activating it after * system bootstrap time is not useful, and can be fatal to the system. @@ -2574,10 +2579,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) { --------------000903080601040909000901-- From owner-freebsd-acpi@freebsd.org Wed Sep 23 00:23:27 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 A7FB7A07C56 for ; Wed, 23 Sep 2015 00:23:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 858061470; Wed, 23 Sep 2015 00:23:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB1B4B97B; Tue, 22 Sep 2015 20:23:25 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Cc: Jung-uk Kim , Colin Percival , Anthony Jenkins Subject: Re: disabling sleep when shutting down Date: Tue, 22 Sep 2015 15:38:39 -0700 Message-ID: <1905488.VHUbJhcB3l@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <5601A863.5070406@FreeBSD.org> References: <55FA3848.7090802@freebsd.org> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Sep 2015 20:23:25 -0400 (EDT) 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: Wed, 23 Sep 2015 00:23:27 -0000 On Tuesday, September 22, 2015 03:13:39 PM Jung-uk Kim wrote: > > On 09/20/2015 03:16, Colin Percival wrote: > >> On 09/18/15 11:29, Anthony Jenkins wrote: > >>> 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. > >> > >> Hmm... well, rc.shutdown runs before the system drops into > >> single-user mode. Which makes me think that maybe we should be > >> making the kernel call from inside init instead of from > >> rc.shutdown. > > > > I didn't want to pollute init with arch-dependent hacks. Anyway, > > the attached patch should do what you want (not tested). > > Or a simpler hack with sysctl(3) instead of ioctl(2). I kind of think just setting the LID switch sysctl during shutdown is probably fine. That said, if you want to do this in the kernel, there's no reason to make this x86-specific. powerpc laptops can suspend but don't use ACPI to do so. Can you just have an MI sysctl that init frobs? It doesn't hurt to do so on platforms that don't support suspending (the knob would just be a no-op). -- John Baldwin From owner-freebsd-acpi@freebsd.org Wed Sep 23 08:29:02 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 74C06A07216 for ; Wed, 23 Sep 2015 08:29:02 +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 20D7C186C for ; Wed, 23 Sep 2015 08:29:02 +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=TqRynhMcPQC7WVUgH8sE2u+OYuc=; b=HRE6NOQBwZ8BBhexGA C7K4LVUSA02SgI9lB2M9sumtAV7JG5/qGqfWBgjhFoxlvVWJsl7HuKG0LjUqjBbY lt7ixftPSwydYM988x4lSLUFnzBBlXw2FHzWTabde04pvR/PImFIp1n0qmSA90NH ouFe3b2OmCzIi9gIWUYa9Ry8g= Received: by filter0486p1mdw1.sendgrid.net with SMTP id filter0486p1mdw1.14244.560262C527 2015-09-23 08:28:53.484684148 +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 0jRm_jaUSuqg0C40o9A1vQ for ; Wed, 23 Sep 2015 08:28:53.196 +0000 (UTC) Received: (qmail 33283 invoked from network); 23 Sep 2015 08:28:43 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 23 Sep 2015 08:28:43 -0000 Received: (qmail 16937 invoked from network); 23 Sep 2015 08:28:47 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 23 Sep 2015 08:28:47 -0000 Subject: Re: disabling sleep when shutting down To: Jung-uk Kim , Anthony Jenkins , "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> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> From: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <560262BF.7090107@freebsd.org> Date: Wed, 23 Sep 2015 01:28:47 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5601A863.5070406@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCvnRov9I10XDijiiApebiJd0xfF7n3XN2rkES IHk2K9M/lSojCYkZuIn97/YFeTfhGCPckzIdmlTSaD+MQ9UpySi+0S8+P+oY8qnTFrbUJe2siDoqxG C7Bjyk89YablD3rvKGZDLYo7H/2f8TraMbCx 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: Wed, 23 Sep 2015 08:29:02 -0000 On 09/22/15 12:13, Jung-uk Kim wrote: >> I didn't want to pollute init with arch-dependent hacks. Anyway, >> the attached patch should do what you want (not tested). > > Or a simpler hack with sysctl(3) instead of ioctl(2). Right, this is more like what I was thinking. (I can write patches myself btw -- I was asking for help with figuring out the right solution, not with the coding itself!) A couple things I'm not sure about though: > + /* Temporarily block any suspend requests. */ > + len = sizeof(blocked); > + block = 1; > + if (sysctlbyname("debug.acpi.sleep_blocked", &blocked, &len, > + &block, sizeof(block)) == -1) > + blocked = 0; Wouldn't it make sense to wrap this in "if (Reboot)"? That way it would block suspend for poweroff / halt / reboot, but not for dropping to single-user mode. > +#if defined(__amd64__) || defined(__i386__) > + /* Unblock suspend requests. */ > + if (!blocked) > + sysctlbyname("debug.acpi.sleep_blocked", NULL, NULL, > + &blocked, sizeof(blocked)); > +#endif > + And if we restrict the blocking to only happen if (Reboot), is there any point unblocking suspend when we're about to call reboot(2)? -- 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 Wed Sep 23 08:38:10 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 9CD28A0771E for ; Wed, 23 Sep 2015 08:38:10 +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 2F5B41D43 for ; Wed, 23 Sep 2015 08:38:10 +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=CsXfJpWRZCBvCi2A6v82AW+WGPI=; b=iKN5Sr0QwwGcxP0BhV lXDYZvl/oUJYaUYceIKBaOJkz0dhAB5hP3uoIjnE8w/H9lDEKG9lVQsJJ3n4WUrk WEb3AKFXFEpbFNNflocbG7VDSvl9i7exQ4THVBwf3OYK/xzznwGR1YH6Ld0qZgzm gYfQMZJ0Den37CLj3xqrKfus0= Received: by filter0808p1mdw1.sendgrid.net with SMTP id filter0808p1mdw1.17274.560264EE42 2015-09-23 08:38:06.709469049 +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 BUbMUapLQ7-8kFRa3xX04Q for ; Wed, 23 Sep 2015 08:38:06.707 +0000 (UTC) Received: (qmail 33722 invoked from network); 23 Sep 2015 08:37:57 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 23 Sep 2015 08:37:57 -0000 Received: (qmail 16967 invoked from network); 23 Sep 2015 08:38:00 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 23 Sep 2015 08:38:00 -0000 Subject: Re: disabling sleep when shutting down To: John Baldwin , freebsd-acpi@freebsd.org References: <55FA3848.7090802@freebsd.org> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <1905488.VHUbJhcB3l@ralph.baldwin.cx> From: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <560264E8.4060407@freebsd.org> Date: Wed, 23 Sep 2015 01:38:00 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1905488.VHUbJhcB3l@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCsKtqDhYxmSeGsi0qy355wxzdIeOZgnK6XcCq Tp4WD2HcqB9e40iE42nu4tX27ZJT43YLeWQEk1q3iN7JstJ4fflmkZMBB9MO4+XtyVqNVkPsCVryf5 QCR8fXvC7v2ocMry8438S6RnESinL0pn4jYB 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: Wed, 23 Sep 2015 08:38:10 -0000 On 09/22/15 15:38, John Baldwin wrote: > I kind of think just setting the LID switch sysctl during shutdown > is probably fine. It's all a matter of how general a solution we want, I guess. My immediate issue was the lid switch, but I never like solving a small problem if I can address a more general issue instead. ;-) > That said, if you want to do this in the kernel, there's no reason to > make this x86-specific. powerpc laptops can suspend but don't use > ACPI to do so. Can you just have an MI sysctl that init frobs? It > doesn't hurt to do so on platforms that don't support suspending (the > knob would just be a no-op). This makes sense to me. kern.shutdownpending meaning "userspace has informed the kernel that the system will be shutting down soon"? This could conceivably be used by other systems where it doesn't make sense to do something just before shutting down. Or should we stick to a more restricted kern.insomniac meaning "the kernel should not suspend"? (Or, less poetically, kern.suspend_blocked?) Any preferences? -- 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 Wed Sep 23 13:01:14 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 95D72A036E3 for ; Wed, 23 Sep 2015 13:01:14 +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 ED49B12BE; Wed, 23 Sep 2015 13:01:12 +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 t8ND13cN032070; Wed, 23 Sep 2015 23:01:03 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 23 Sep 2015 23:01:03 +1000 (EST) From: Ian Smith To: Colin Percival cc: Anthony Jenkins , Jung-uk Kim , "freebsd-acpi@freebsd.org" Subject: Re: disabling sleep when shutting down In-Reply-To: <560110B3.6050401@freebsd.org> Message-ID: <20150923221134.C29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <20150920194946.U29510@sola.nimnet.asn.au> <560110B3.6050401@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: Wed, 23 Sep 2015 13:01:14 -0000 On Tue, 22 Sep 2015 01:28:27 -0100, Colin Percival wrote: > On 09/20/15 03:04, Ian Smith wrote: > > On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote: > > > On 09/18/15 11:29, Anthony Jenkins wrote: > > > > 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. > > > > > > Hmm... well, rc.shutdown runs before the system drops into single-user > > > mode. Which makes me think that maybe we should be making the kernel > > > call from inside init instead of from rc.shutdown. > > > > I still think disabling suspend from shutdown.c, at the same time as > > creating /var/run/nologin might be the best way to go, to avoid any > > possibility of untimely suspending once committed to shutting down. > > So you think we should disable suspend for the last 5 minutes before a > scheduled shutdown? This seems a bit strange to me... and I honestly can't > imagine a situation where you'd need to announce an imminent shutdown of > your laptop to logged-in users. Not necessarily 5 minutes, but maybe some time. I've long used several laptops as servers, one with websites, DNS, mail, etc, and with login users .. but I've not considered suspending on such (rare) shutdowns, nor there used scheduled shutdowns. It's hard sometimes imagining other peoples' experiences if they're very different from your own :) > > For one thing, shutdown's -o flag bypasses using init and calls halt or > > reboot directly, though I don't know if anyone uses that. > > Right, I figured it wasn't worth worrying about that case since anyone who > uses that hopefully knows what they're doing; also since that skips running > rc.shutdown there's a much smaller race window. Fair enough. > On the other hand, "send a signal to init" and the sysv compatible approach > of running `init [runlevel]` are likely to be used by other tools (e.g., > desktop environments), so I don't think we should assume that reboot/poweroff > requests always go through shutdown(8). That's a good point, and I do think the approach you're developing is looking pretty good overall .. except for one point, below. And I agree with your latest point, that shutdown to SU shouldn't disable suspend. > > For another, > > if shutdown fails for any reason, or is cancelled by signal by the user > > .. or in any case, I gather .. finish() removes /var/run/nologin, and > > could also there reenable suspend, covering Anthony's point. I's almost suggested /var/run/nosuspend, possibly holding the previous value of hw.acpi.lid_switch_state, when considering just the LID issue, but that would require removing on startup. > This would also be accomplished by having the suspend-disabling done by init; > if you tell shutdown(8) to not shut the system down, then it never sends the > relevant signal to init. The shutdown(8) utility doesn't do any shutting > down itself; it's just a front-end which makes an announcement, sets a timer, > and disables logins, and then ultimately asks init(8) to do the real work > (including spawning rc.shutdown). Indeed, not to mention the handy logging. However to come back to your initial issue: if you initiate a shutdown - I'd assumed you meant using 'shutdown -p now' ono? - hit return and snap the lid shut - let's say with practice and some bruised fingers in 0.3s - then are we sure that shutdown will progress to init, or from init to rc.shutdown in the other scenario jkim offered, within say 0.3s? IOW, are we sure a fix in init, or ever so shightly later in rc.shutdown, will always win that race, on a system that might be in a high load state? If not, the lid switch race becomes almost a separate issue, which the bother of adding setting hw.acpi.lid_switch_state would deal with, while needing storage to restore it on a cancelled or failed shutdown. Don't mind me, I've only used slower low-end gear for years now, and my concepts of how long things might take is conditioned on that. On one laptop I can't trust shutdown to wind down KDE including a browser with maybe 15 tabs inside two minutes, so always shut KDE down first .. this sort of stuff most people nowadays don't need to even consider. cheers, Ian From owner-freebsd-acpi@freebsd.org Wed Sep 23 14:54:00 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 DA677A070F8 for ; Wed, 23 Sep 2015 14:54:00 +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 37DA11D80; Wed, 23 Sep 2015 14:54:00 +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 t8NErpEN011557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 23 Sep 2015 16:53:55 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: disabling sleep when shutting down To: Ian Smith , Colin Percival Cc: "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> <55FE5D54.1030806@freebsd.org> <20150920194946.U29510@sola.nimnet.asn.au> <560110B3.6050401@freebsd.org> <20150923221134.C29510@sola.nimnet.asn.au> From: Dan Lukes Message-ID: <5602BCFE.9000800@obluda.cz> Date: Wed, 23 Sep 2015 16:53: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: <20150923221134.C29510@sola.nimnet.asn.au> 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: Wed, 23 Sep 2015 14:54:00 -0000 Ian Smith wrote: > if you initiate a shutdown - I'd assumed you meant using 'shutdown -p now' ono? Unsure what method the Colin is using, but I'm using power-off button to initiate shutdown. Dan From owner-freebsd-acpi@freebsd.org Wed Sep 23 15:09:21 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 1B525A07723 for ; Wed, 23 Sep 2015 15:09:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECFEE1359; Wed, 23 Sep 2015 15:09:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EB738B945; Wed, 23 Sep 2015 11:09:19 -0400 (EDT) From: John Baldwin To: Colin Percival Cc: freebsd-acpi@freebsd.org, Jung-uk Kim , Anthony Jenkins Subject: Re: disabling sleep when shutting down Date: Wed, 23 Sep 2015 08:03:15 -0700 Message-ID: <1560128.HC08lqgeSM@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <560264E8.4060407@freebsd.org> References: <55FA3848.7090802@freebsd.org> <1905488.VHUbJhcB3l@ralph.baldwin.cx> <560264E8.4060407@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 23 Sep 2015 11:09:20 -0400 (EDT) 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: Wed, 23 Sep 2015 15:09:21 -0000 On Wednesday, September 23, 2015 01:38:00 AM Colin Percival wrote: > On 09/22/15 15:38, John Baldwin wrote: > > I kind of think just setting the LID switch sysctl during shutdown > > is probably fine. > > It's all a matter of how general a solution we want, I guess. My immediate > issue was the lid switch, but I never like solving a small problem if I can > address a more general issue instead. ;-) > > > That said, if you want to do this in the kernel, there's no reason to > > make this x86-specific. powerpc laptops can suspend but don't use > > ACPI to do so. Can you just have an MI sysctl that init frobs? It > > doesn't hurt to do so on platforms that don't support suspending (the > > knob would just be a no-op). > > This makes sense to me. kern.shutdownpending meaning "userspace has > informed the kernel that the system will be shutting down soon"? This > could conceivably be used by other systems where it doesn't make sense > to do something just before shutting down. > > Or should we stick to a more restricted kern.insomniac meaning "the > kernel should not suspend"? (Or, less poetically, kern.suspend_blocked?) > > Any preferences? I think suspend_blocked is fine for now. We may find that there are other use cases in the future. -- John Baldwin From owner-freebsd-acpi@freebsd.org Wed Sep 23 17:17:02 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 5FD07A07CCE for ; Wed, 23 Sep 2015 17:17:02 +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 4E9971DB1; Wed, 23 Sep 2015 17:17:02 +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 DB2143AF1; Wed, 23 Sep 2015 17:17:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: disabling sleep when shutting down To: Colin Percival , Anthony Jenkins , "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> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> From: Jung-uk Kim X-Enigmail-Draft-Status: N1110 Message-ID: <5602DE8D.3020102@FreeBSD.org> Date: Wed, 23 Sep 2015 13:17:01 -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: <560262BF.7090107@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Wed, 23 Sep 2015 17:17:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/23/2015 04:28, Colin Percival wrote: > On 09/22/15 12:13, Jung-uk Kim wrote: >>> I didn't want to pollute init with arch-dependent hacks. >>> Anyway, the attached patch should do what you want (not >>> tested). >> >> Or a simpler hack with sysctl(3) instead of ioctl(2). > > Right, this is more like what I was thinking. (I can write patches > myself btw -- I was asking for help with figuring out the right > solution, not with the coding itself!) I don't doubt that. In fact, I wanted to save some electrons because you can read/write patches and "the code speaks for itself". :-) > A couple things I'm not sure about though: >> + /* Temporarily block any suspend requests. */ + len = >> sizeof(blocked); + block = 1; + if >> (sysctlbyname("debug.acpi.sleep_blocked", &blocked, &len, + >> &block, sizeof(block)) == -1) + blocked = 0; > > Wouldn't it make sense to wrap this in "if (Reboot)"? That way it > would block suspend for poweroff / halt / reboot, but not for > dropping to single-user mode. I think dropping to single user should be protected, too. Jung-uk Kim >> +#if defined(__amd64__) || defined(__i386__) + /* Unblock suspend >> requests. */ + if (!blocked) + >> sysctlbyname("debug.acpi.sleep_blocked", NULL, NULL, + >> &blocked, sizeof(blocked)); +#endif + > > And if we restrict the blocking to only happen if (Reboot), is > there any point unblocking suspend when we're about to call > reboot(2)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWAt6IAAoJEHyflib82/FGoT4H/3eoM/O/Zj80VqT1qBmYiSoa VFJM/RQ3c0Nvu+a+D0GHoD4G98QFclmqmeQiaSBl6LchgqTPllN3o5l8WTKVisM7 12iFzx5WrfVpdoB8u6l2wMp9YcIvsqPwEAbz+nvaZOHZWpSgjxcjImCoI1nKhHpz SPF2jkjdTwvPvpDHgfT1GALfDXFPtFGyDZeEin5ntkTm9mJOyxd0v3Jj4iFSRzgc D1KsTRfIjsygiNHnTvTfuKSOspU4yhlWr+NS3b3hnXpPgOmBhdS8UYjOjVCt03eE SRfZ9FPqMI8rX8l8AXchxKHpRSkngqGTpUpMdNooqqyNfqGoHwvqQ2nI4NStHsc= =wzTq -----END PGP SIGNATURE----- From owner-freebsd-acpi@freebsd.org Fri Sep 25 18:39:52 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 B9BB8A0924E for ; Fri, 25 Sep 2015 18:39:52 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A726110D for ; Fri, 25 Sep 2015 18:39:52 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: by wicfx3 with SMTP id fx3so30725486wic.0 for ; Fri, 25 Sep 2015 11:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=XbtrrLuwN10Md9ePtcImeT1bTZONrbYkB1h8sGsYc9E=; b=kXUmu/zRrEM1EjQFa5pSzliKa0tyuuh3JPtDOZ4cgQLvZajr+MYZfcuw/NVJjC3RKj 0PtstehpwLSlWVsaNOAH1Am77rDqO3CHvaCaLgGExfubiEnLPdYmsIT8IuTl5XRGa+kD jyZ7Sn/8wKuxtDCImlZrup8DRLjBh5TZDRxz+mbbB9v3mbr8tDfYrfMaUIffMMwRqqg+ 1ib8smBjaaq0GZ0++d9xFnlQoI6f0PTVTHyrfunjnQgQJCWU4onICc+B1rQsXjuFuUU3 uJ18ziQL29tkV1RD9A8eyuB3enkH3jAV5W6dalEPQyI8S76gesA56PLvVS+bjcmHIb7A +9NQ== X-Received: by 10.180.182.116 with SMTP id ed20mr2137852wic.19.1443206390498; Fri, 25 Sep 2015 11:39:50 -0700 (PDT) Received: from macbookderpeijl.aerrow.local ([62.238.6.31]) by smtp.gmail.com with ESMTPSA id fs9sm4492575wic.24.2015.09.25.11.39.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 11:39:49 -0700 (PDT) From: Arthur van der Peijl Subject: ACPI problems op ASrock Message-Id: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> Date: Fri, 25 Sep 2015 20:39:48 +0200 To: freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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, 25 Sep 2015 18:39:52 -0000 Hello, In May I started with 10.0-Release on an ASrock E3C224D4I-14S. The system had low power consumption and powerd(8) did a good job = lowering the CPU frequency. However starting from 10.1 (and now 10.2-release) I keep getting high = CPU consumption due to a process called {acpi task}. BIOS upgrades or changes didn't help. Disabling ACPI results in system = halt at startup.=20 Does anybody have an idea to solve this? It seems that the ACPI process = in FreeBSD is changed, which my motherboard cannot handle (or the mb has = wrong ACPI tables?).=20 top -SH output: ---- last pid: 41184; load averages: 1.71, 1.75, 1.64 = up 8+14:05:40 10:00:16 691 processes: 7 running, 663 sleeping, 21 waiting CPU: 0.8% user, 0.0% nice, 62.7% system, 0.0% interrupt, 36.5% idle Mem: 90M Active, 4310M Inact, 11G Wired, 18M Cache, 144K Buf, 497M Free ARC: 9991M Total, 1364M MFU, 7997M MRU, 4841K Anon, 36M Header, 588M = Other Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 11 root 155 ki31 0K 32K RUN 1 122.7H 62.99% = idle{idle: cpu1} 0 root 8 0 0K 7088K RUN 1 73.2H 36.87% = kernel{acpi_task_1} 0 root 8 0 0K 7088K RUN 0 73.3H 36.18% = kernel{acpi_task_0} 0 root 8 0 0K 7088K RUN 0 73.2H 35.60% = kernel{acpi_task_2} 11 root 155 ki31 0K 32K RUN 0 67.6H 34.08% = idle{idle: cpu0} 1024 mysql 20 0 266M 69624K RUN 1 0:37 0.10% = mysqld{mysqld} 12 root -60 - 0K 336K WAIT 0 11:18 0.00% = intr{swi4: clock} 1149 root 20 0 500M 90016K sbwait 0 6:15 0.00% = mongod{mongod} 1149 root 20 0 500M 90016K sbwait 1 6:13 0.00% = mongod{mongod} 1149 root 20 0 500M 90016K sbwait 0 6:12 0.00% = mongod{mongod} 687 root 20 0 4560M 363M uwait 1 5:31 0.00% = java{java} ---- Regards, Arthur= From owner-freebsd-acpi@freebsd.org Fri Sep 25 23:09: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 37ECAA081E8 for ; Fri, 25 Sep 2015 23:09:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F134D1E48 for ; Fri, 25 Sep 2015 23:09:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by oibi136 with SMTP id i136so66260790oib.3 for ; Fri, 25 Sep 2015 16:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uxvQ+a5u3nefAh/+APG4pn6Wdj/sb1RHTOwLxmpUAsM=; b=rbM571BvTEb0t7qYN7d1mAFxGcOK+TOuINAA0gzmLmh6U68HkzjafYXwanvnezNIbu 9UhnQuyxtnIjZ1W64P+UbzFDqIYZeXyfXULcl9LPAyFExN9fDy2VdgaKUtnNYBiWdCm7 xsRH+OViv04g7FhCBjAzJMRkwFNsw0etvA09U2SjnaUSzw/h1SFSv11QtPrVWH5JWvPg wmsljHcNugx6yNqlsN3oBBUXxUfzSaKeJ624SPtLP/awD/ikGH/yThjucpDDeC9/APCl YJSONDAk3eTvY8pYW+QrEPOrjlIBcuejh8V01tNG0lc+v791n7E7zSeKnzDDltGTzz8r kgAQ== MIME-Version: 1.0 X-Received: by 10.202.182.87 with SMTP id g84mr4350681oif.59.1443222558268; Fri, 25 Sep 2015 16:09:18 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.202.102.9 with HTTP; Fri, 25 Sep 2015 16:09:18 -0700 (PDT) In-Reply-To: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> Date: Fri, 25 Sep 2015 16:09:18 -0700 X-Google-Sender-Auth: q7hjIJTKGCZVdgNvxN14KnkOLVw Message-ID: Subject: Re: ACPI problems op ASrock From: Kevin Oberman To: Arthur van der Peijl Cc: "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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, 25 Sep 2015 23:09:19 -0000 On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl < aavanderpeijl@gmail.com> wrote: > Hello, > > In May I started with 10.0-Release on an ASrock E3C224D4I-14S. > The system had low power consumption and powerd(8) did a good job lowering > the CPU frequency. > > However starting from 10.1 (and now 10.2-release) I keep getting high CPU > consumption due to a process called {acpi task}. > > BIOS upgrades or changes didn't help. Disabling ACPI results in system > halt at startup. > Does anybody have an idea to solve this? It seems that the ACPI process in > FreeBSD is changed, which my motherboard cannot handle (or the mb has wrong > ACPI tables?). > > top -SH output: > ---- > last pid: 41184; load averages: 1.71, 1.75, 1.64 > up 8+14:05:40 10:00:16 > 691 processes: 7 running, 663 sleeping, 21 waiting > CPU: 0.8% user, 0.0% nice, 62.7% system, 0.0% interrupt, 36.5% idle > Mem: 90M Active, 4310M Inact, 11G Wired, 18M Cache, 144K Buf, 497M Free > ARC: 9991M Total, 1364M MFU, 7997M MRU, 4841K Anon, 36M Header, 588M Other > Swap: 2048M Total, 2048M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 155 ki31 0K 32K RUN 1 122.7H 62.99% > idle{idle: cpu1} > 0 root 8 0 0K 7088K RUN 1 73.2H 36.87% > kernel{acpi_task_1} > 0 root 8 0 0K 7088K RUN 0 73.3H 36.18% > kernel{acpi_task_0} > 0 root 8 0 0K 7088K RUN 0 73.2H 35.60% > kernel{acpi_task_2} > 11 root 155 ki31 0K 32K RUN 0 67.6H 34.08% > idle{idle: cpu0} > 1024 mysql 20 0 266M 69624K RUN 1 0:37 0.10% > mysqld{mysqld} > 12 root -60 - 0K 336K WAIT 0 11:18 0.00% > intr{swi4: clock} > 1149 root 20 0 500M 90016K sbwait 0 6:15 0.00% > mongod{mongod} > 1149 root 20 0 500M 90016K sbwait 1 6:13 0.00% > mongod{mongod} > 1149 root 20 0 500M 90016K sbwait 0 6:12 0.00% > mongod{mongod} > 687 root 20 0 4560M 363M uwait 1 5:31 0.00% > java{java} > ---- > > Regards, > > Arthur > I have not noted this exact behavior, so this MIGHT not work, but the subject of power management seems to keep coming up. For a good discussion of the subject, read mav@'s FreeBSD wiki article on the subject. It's slightly (but only slightly) dated. To fix your immediate issue, try adding the following to /etc/rc.conf: performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" NOTE: In the case of very large multiprocessor systems with 32 or more CPUs, you might get a nasty performance hit and should instead use: performance_cx_lowest="C2" economy_cx_lowest="Cmax" Please DON'T enable TCC and/or throttling and C-states together! On some processors this can cause deadlocks. Intel never expected TCC/throttling to be used the way FreeBSD did. For desktop and laptop use, "Cmax" is always the way to go. It really, really reduces power consumption. Finally, if this fails, you can restore TCC by adding "hint.acpi_p4tcc.0.disabled=0" to /boot/loader.conf, but never combine this with setting either cx_lowest value in rc.conf. This change will require a reboot. You can change this on a running system with "sysctl dev.cpu.0.cx_lowest=C8" to enable C-states or C1 to disable them. No need to re-boot. Read on for more gory details. Note that I am at least partly responsible for the long-term brokenness of FreeBSD power management as I did laboratory testing of it when I was at Lawrence Berkeley Lab, but did not really understand the differences between the test-bed and the real world. Throttling is not and never has been a tool for power management. It was created by Intel as a method of thermal management and the implementation was manual. That is, some external process had to activate it. It was replaced in 2000 by TCC (Thermal Control Circuit) which did the exact same thing, but was entirely internal to the processor and was thus consistent and uniformly implemented. Throttling was still present for compatibility, but is really, really obsolete. Both throttling and TCC so the same thing. They reduce the heat generated by skipping 'N' of every 8 clock cycles. They don't actually change the clock speed. EST, which actually does slow the clock as well as reducing the core voltage should still provide a a few clock speeds. The number is dependent on the particular CPU, but usually between 3 and 8. It does save power, but not very effectively. Unfortunately, many thought that throttling was a way to do power management. In fact, except in a few real-time edge cases, it is totally ineffective for that purpose. The problem you are having is probably that enabling the newer, really effective power management tool was not committed to 10.2 when TCC was disabled. It is now in HEAD and I am hoping to see it in 10.3 as well as 11. (I'm not a committer, so I only can go on what I've been told by the one who committed disabling TCC.) C-states do not change the clock speed. You will only have a small set of frequencies reported as those will be REAL clock speeds from EST, not the synthetic ones shown when using throttling/TCC, so the number of them shown by default on 10.2 will be 1/8th of when was shown by prior versions. I you do need to do this, please let us know. That should not be happening! I am now working (slowly) on a power management section of the handbook which will do a better job of explaining the issues. -- Kevin Oberman, Part time goatherd and retired Network Engineer From owner-freebsd-acpi@freebsd.org Sat Sep 26 07:26:50 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 682909B88B6 for ; Sat, 26 Sep 2015 07:26:50 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o1.l99.sendgrid.net (o1.l99.sendgrid.net [198.37.153.74]) (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 1A225E8A for ; Sat, 26 Sep 2015 07:26:49 +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; s=smtpapi; bh=YNlcK5FYUD9kHBB9jVcOtHDfwDo=; b=kibJDsXPIzJbj1NrSY 85iNNFYqChrFqd+ItBmde8Uc88kfx2kWPqxisWuaBd+Dsj/9e4Q5JnZjdNuy5DNa +lZ7JdvcsW6LdBUhnI5EiydaGj3u2IWGb3C0QWVlIih2jxVcQ7zDVs61fhyimKx2 x9HTmA3BkKGAJBU6CRNCp/89o= Received: by filter0494p1mdw1.sendgrid.net with SMTP id filter0494p1mdw1.4380.560648B718 2015-09-26 07:26:47.274819235 +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 SKGglLT0Tq2SPZdpc1o34A for ; Sat, 26 Sep 2015 07:26:47.458 +0000 (UTC) Received: (qmail 87334 invoked from network); 26 Sep 2015 07:26:34 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Sep 2015 07:26:34 -0000 Received: (qmail 45985 invoked from network); 26 Sep 2015 07:26:31 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Sep 2015 07:26:31 -0000 Subject: Re: disabling sleep when shutting down To: Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , Dan Lukes , ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> From: Colin Percival X-Enigmail-Draft-Status: N1010 Message-ID: <560648A7.4030708@freebsd.org> Date: Sat, 26 Sep 2015 00:26:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5602DE8D.3020102@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------050603020603000908060907" X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCtC+zdQfazmrMuua54LIIP8icfOP7GEZ39bgo nrJiSCw4xhfcBvg/A3T1g8aX6TbAgj8G0vWWi5YMpOGx2QnSO8yI/rKZFzyPbNpSWDrqyszkACmhU3 D1HeJSpWgMpPy3eTDoIJiUVRUiboGIQ9S9Nm 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, 26 Sep 2015 07:26:50 -0000 This is a multi-part message in MIME format. --------------050603020603000908060907 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi all, I think there is consensus for: * Using a sysctl (simpler than a device node), * Setting this sysctl on all architectures, * Calling the sysctl kern.suspend_blocked, * Consulting the sysctl from the ACPI code (for now) and possibly from other platform-specific forms of sleeping (in the indefinite future). Points without consensus: * jkim thinks we should prevent suspend when we're dropping to single-user mode; I'm not sure I see the point, but I don't think there's any harm in doing that too. * Ian Smith would like to have suspend blocked for the last 5 minutes before shutdown(8) signals init to shut the system down. I don't think anyone else has expressed a desire for this, and some people have raised concerns about blocking suspend for too long in case a system is running out of battery; so I'm inclined to leave this out at this point. (It would be easy enough to add the sysctl-frobbing to shutdown(8) if desired later.) With the above in mind, I've written (but not yet actually compiled or tested, so beware of typos) a patch which I think makes sense. If nobody is violently opposed to this I'll make sure I got the details right and then commit this in a few days. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------050603020603000908060907 Content-Type: text/x-patch; name="block_suspend.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="block_suspend.patch" Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 288249) +++ sbin/init/init.c (working copy) @@ -1481,6 +1481,16 @@ } /* + * Block (if block == 1) or unblock (if block == 0) suspend. + */ +static void +block_suspend(int block) +{ + + sysctlbyname("kern.suspend_blocked", NULL, NULL, &block, sizeof(block)); +} + +/* * Bring the system down to single user. */ static state_func_t @@ -1487,7 +1497,16 @@ death(void) { session_t *sp; + int block, blocked; + size_t len; + /* Temporarily block suspend. */ + len = sizeof(blocked); + block = 1; + if (sysctlbyname("kern.suspend_blocked", &blocked, &len, + &block, sizeof(block))) + blocked = 0; + /* * Also revoke the TTY here. Because runshutdown() may reopen * the TTY whose getty we're killing here, there is no guarantee @@ -1503,6 +1522,11 @@ /* Try to run the rc.shutdown script within a period of time */ runshutdown(); + /* Unblock suspend if we blocked it. */ + if (!blocked) + sysctlbyname(kern.suspend_blocked", NULL, NULL, + &blocked, sizeof(blocked)); + return (state_func_t) death_single; } Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 288249) +++ sys/dev/acpica/acpi.c (working copy) @@ -2574,8 +2574,11 @@ 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 blocked due to an upcoming shutdown, just return. + */ + if (rebooting || sc->acpi_next_sstate != 0 || suspend_blocked) { return (0); } Index: sys/kern/kern_shutdown.c =================================================================== --- sys/kern/kern_shutdown.c (revision 288249) +++ sys/kern/kern_shutdown.c (working copy) @@ -137,6 +137,10 @@ SYSCTL_INT(_kern_shutdown, OID_AUTO, show_busybufs, CTLFLAG_RW, &show_busybufs, 0, ""); +int suspend_blocked = 0; +SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW, + &suspend_blocked, 0, "Block suspend due to a pending shutdown"); + /* * Variable panicstr contains argument to first call to panic; used as flag * to indicate that the kernel has already called panic. Index: sys/sys/systm.h =================================================================== --- sys/sys/systm.h (revision 288249) +++ sys/sys/systm.h (working copy) @@ -46,6 +46,7 @@ #include /* for people using printf mainly */ extern int cold; /* nonzero if we are doing a cold boot */ +extern int suspend_blocked; /* block suspend due to pending shutdown */ extern int rebooting; /* kern_reboot() has been called. */ extern const char *panicstr; /* panic message */ extern char version[]; /* system version */ --------------050603020603000908060907-- From owner-freebsd-acpi@freebsd.org Sat Sep 26 07:40:30 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 15FCBA08392 for ; Sat, 26 Sep 2015 07:40:30 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6187FA1C; Sat, 26 Sep 2015 07:40:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 680D71FE023; Sat, 26 Sep 2015 09:40:26 +0200 (CEST) Subject: Re: disabling sleep when shutting down To: Colin Percival , Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , Dan Lukes , ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> From: Hans Petter Selasky Message-ID: <56064C48.8020100@selasky.org> Date: Sat, 26 Sep 2015 09:42:00 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560648A7.4030708@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Sat, 26 Sep 2015 07:40:30 -0000 Hi, On 09/26/15 09:26, Colin Percival wrote: > Hi all, > > I think there is consensus for: > * Using a sysctl (simpler than a device node), Presumably a read/write tunable sysctl, RWTUN? > * Setting this sysctl on all architectures, > * Calling the sysctl kern.suspend_blocked, > * Consulting the sysctl from the ACPI code (for now) and possibly from > other platform-specific forms of sleeping (in the indefinite future). > > Points without consensus: > * jkim thinks we should prevent suspend when we're dropping to single-user > mode; I'm not sure I see the point, but I don't think there's any harm in > doing that too. > * Ian Smith would like to have suspend blocked for the last 5 minutes before > shutdown(8) signals init to shut the system down. I don't think anyone else > has expressed a desire for this, and some people have raised concerns about > blocking suspend for too long in case a system is running out of battery; so > I'm inclined to leave this out at this point. (It would be easy enough to > add the sysctl-frobbing to shutdown(8) if desired later.) > > With the above in mind, I've written (but not yet actually compiled or tested, > so beware of typos) a patch which I think makes sense. If nobody is violently > opposed to this I'll make sure I got the details right and then commit this in > a few days. +1 I think this is a good idea. I've seen this issue myself with non-FreeBSD OS'es. --HPS From owner-freebsd-acpi@freebsd.org Sat Sep 26 07:49:01 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 A00ACA08B95 for ; Sat, 26 Sep 2015 07:49:01 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o1.l99.sendgrid.net (o1.l99.sendgrid.net [198.37.153.74]) (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 2E9ACFD4 for ; Sat, 26 Sep 2015 07:49:00 +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=IYgx3HZOygmd6TaNip9taAnYog4=; b=OrtKglHsMzL8WhvUcJ +uD8PWR0B1E+afeR46szVMAYcNOomaJm/tzC3TqakZV5FXsOF+na6Hvl5Im+k9Jn 4zx7ocXWKFo4JCvbPUzy46nOn/jQz6KblVkw3jbD2Fux5mPZ07LddltcT74JdldM a8Hsnpf0XPmyBJJbye5SyVTKQ= Received: by filter0455p1mdw1.sendgrid.net with SMTP id filter0455p1mdw1.28900.56064DE93A 2015-09-26 07:48:57.765770447 +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 ZuFDrR0sQiy-dBCwqitYLA for ; Sat, 26 Sep 2015 07:48:57.750 +0000 (UTC) Received: (qmail 88021 invoked from network); 26 Sep 2015 07:48:45 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Sep 2015 07:48:45 -0000 Received: (qmail 46331 invoked from network); 26 Sep 2015 07:48:41 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Sep 2015 07:48:41 -0000 Subject: Re: disabling sleep when shutting down To: Hans Petter Selasky , "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> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> <56064C48.8020100@selasky.org> From: Colin Percival Message-ID: <56064DD9.6020503@freebsd.org> Date: Sat, 26 Sep 2015 00:48:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56064C48.8020100@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCtiESGtHN70TomWRk+KwEgW/YDE/y/OL5aO8V zbTHi35/jMVruwB/Ed3Ytsa15srZuSSDp/j6K5fyfy1VGiTJyeeCflJbu+S4fradRDa6q7Jrh9wlds 86kB8X5fCCz/pBwOzuDzp8GgMLhGsvrxBP+e 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, 26 Sep 2015 07:49:01 -0000 On 09/26/15 00:42, Hans Petter Selasky wrote: > On 09/26/15 09:26, Colin Percival wrote: >> I think there is consensus for: >> * Using a sysctl (simpler than a device node), > > Presumably a read/write tunable sysctl, RWTUN? I suppose it could be, but the intention here was to block suspend while we're shutting down, not to have it always blocked. The sysctl isn't a configuration setting, it's a userland-kernel communications channel. -- 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 Sat Sep 26 08:17:25 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 73E8E9B81B4 for ; Sat, 26 Sep 2015 08:17:25 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE6D91C8 for ; Sat, 26 Sep 2015 08:17:24 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: by wicge5 with SMTP id ge5so47023833wic.0 for ; Sat, 26 Sep 2015 01:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3BvReGBL7DGqcOBSatf7Z14S+51Q7RftEOszgo8YP6k=; b=H9aagUfXTQaee0Pf4UUVcIco9lN0dTu6QGRrWrKgzSVDCNW9XHYQEU3CCEBCoU9+8p GuZEr7IsEPnIhpOWjwR3xgJ/H/j8WflZq8eZF2raCAO6htnbjHLF0orpsBmTwsBxJAWl F6mwO6SSR/0//cWT2n1AP6BgdqK16qKXNhO/7MT9uyooqAXTeBYXnGTPgJWDVmsOLbZp 5lk4W0dLo+/jYpPI4kcf9hdZdqOtG5f4GKhb3axAVHnLt4mERwSK1YqIbcOelnf7i81j BTBmKcpmU0lfX3JyPcIz0OEuB4OIcBDN1n9dkyL2C1B/t1CkBmDE37kmEFYOg6u5tUJ2 Q1eA== X-Received: by 10.180.87.102 with SMTP id w6mr8143930wiz.88.1443255443079; Sat, 26 Sep 2015 01:17:23 -0700 (PDT) Received: from macbookderpeijl.aerrow.local ([62.238.6.31]) by smtp.gmail.com with ESMTPSA id ex17sm7127975wid.23.2015.09.26.01.17.21 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Sep 2015 01:17:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: ACPI problems op ASrock From: Arthur van der Peijl In-Reply-To: Date: Sat, 26 Sep 2015 10:17:20 +0200 Cc: "freebsd-acpi@freebsd.org" Message-Id: References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> To: Kevin Oberman X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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, 26 Sep 2015 08:17:25 -0000 Thank you for assistance: powerd must clearly not be my focus: the CPU = stays high and thus cannot go into idle mode. I worked thought the document which uncovers that most settings are = already available in my system: [root@zfsguru /home/ssh]# cat /etc/rc.conf | grep cx_ performance_cx_lowest=3D"Cmax" economy_cx_lowest=3D"Cmax" =20 No need to change performance_cx_lowest as I just have a Pentium G3220 = running. [root@zfsguru /home/ssh]# cat /boot/loader.conf | grep hint. hint.p4tcc.0.disabled=3D"1" hint.acpi_throttle.0.disabled=3D"1" Tried to change lowest level on running system:=20 [root@zfsguru /home/ssh]# sysctl dev.cpu.0.cx_lowest=3DC8 dev.cpu.0.cx_lowest: C8 -> C8 We're already there. The document described some other setting which = could be read: [root@zfsguru /home/ssh]# sysctl dev.cpu | grep cx dev.cpu.1.cx_usage: 100.00% last 5us dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_supported: C1/1/1 dev.cpu.0.cx_usage: 100.00% 0.00% last 4us dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/2/117 I don't inderstand this. 100% CPU is my main issue, created by = {acpi_task} in the kernal. However -> CPU1 supports different states as CPU0? Or is this a summary = of last states? You last remark about frequencies: [root@zfsguru /home/ssh]# sysctl dev.cpu | grep freq dev.cpu.0.freq_levels: 3000/53000 2900/50301 2700/46082 2600/43525 = 2400/39557 2300/37137 2100/33398 2000/31112 1800/27610 1700/25455 = 1500/22171 1400/20144 1200/17084 1100/15181 900/12329 800/10550 dev.cpu.0.freq: 3000 As I understand there could be better effective power management be = available. Should that resolve my high CPU issue? Or is it caused by bad = Asrock BIOS tables?=20 As only my high CPU generating {acpi_task} stops, I'll get a better - = more power effective - system using less Watts. Regards, Arthur Op 26 sep. 2015, om 01:09 heeft Kevin Oberman het = volgende geschreven: > On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl = wrote: > Hello, >=20 > In May I started with 10.0-Release on an ASrock E3C224D4I-14S. > The system had low power consumption and powerd(8) did a good job = lowering the CPU frequency. >=20 > However starting from 10.1 (and now 10.2-release) I keep getting high = CPU consumption due to a process called {acpi task}. >=20 > BIOS upgrades or changes didn't help. Disabling ACPI results in system = halt at startup. > Does anybody have an idea to solve this? It seems that the ACPI = process in FreeBSD is changed, which my motherboard cannot handle (or = the mb has wrong ACPI tables?). >=20 > top -SH output: > ---- > last pid: 41184; load averages: 1.71, 1.75, 1.64 = up 8+14:05:40 10:00:16 > 691 processes: 7 running, 663 sleeping, 21 waiting > CPU: 0.8% user, 0.0% nice, 62.7% system, 0.0% interrupt, 36.5% idle > Mem: 90M Active, 4310M Inact, 11G Wired, 18M Cache, 144K Buf, 497M = Free > ARC: 9991M Total, 1364M MFU, 7997M MRU, 4841K Anon, 36M Header, 588M = Other > Swap: 2048M Total, 2048M Free >=20 > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > 11 root 155 ki31 0K 32K RUN 1 122.7H 62.99% = idle{idle: cpu1} > 0 root 8 0 0K 7088K RUN 1 73.2H 36.87% = kernel{acpi_task_1} > 0 root 8 0 0K 7088K RUN 0 73.3H 36.18% = kernel{acpi_task_0} > 0 root 8 0 0K 7088K RUN 0 73.2H 35.60% = kernel{acpi_task_2} > 11 root 155 ki31 0K 32K RUN 0 67.6H 34.08% = idle{idle: cpu0} > 1024 mysql 20 0 266M 69624K RUN 1 0:37 0.10% = mysqld{mysqld} > 12 root -60 - 0K 336K WAIT 0 11:18 0.00% = intr{swi4: clock} > 1149 root 20 0 500M 90016K sbwait 0 6:15 0.00% = mongod{mongod} > 1149 root 20 0 500M 90016K sbwait 1 6:13 0.00% = mongod{mongod} > 1149 root 20 0 500M 90016K sbwait 0 6:12 0.00% = mongod{mongod} > 687 root 20 0 4560M 363M uwait 1 5:31 0.00% = java{java} > ---- >=20 > Regards, >=20 > Arthur >=20 > I have not noted this exact behavior, so this MIGHT not work, but the = subject of power management seems to keep coming up. For a good = discussion of the subject, read mav@'s FreeBSD wiki article on the = subject. It's slightly (but only slightly) dated. >=20 > To fix your immediate issue, try adding the following to /etc/rc.conf: > performance_cx_lowest=3D"Cmax" > economy_cx_lowest=3D"Cmax" >=20 > NOTE: In the case of very large multiprocessor systems with 32 or more = CPUs, you might get a nasty performance hit and should instead use: > performance_cx_lowest=3D"C2" > economy_cx_lowest=3D"Cmax" >=20 > Please DON'T enable TCC and/or throttling and C-states together! On = some processors this can cause deadlocks. Intel never expected = TCC/throttling to be used the way FreeBSD did. >=20 > For desktop and laptop use, "Cmax" is always the way to go. It really, = really reduces power consumption. >=20 > Finally, if this fails, you can restore TCC by adding = "hint.acpi_p4tcc.0.disabled=3D0" to /boot/loader.conf, but never combine = this with setting either cx_lowest value in rc.conf. This change will = require a reboot. >=20 > You can change this on a running system with "sysctl = dev.cpu.0.cx_lowest=3DC8" to enable C-states or C1 to disable them. No = need to re-boot. >=20 > Read on for more gory details. Note that I am at least partly = responsible for the long-term brokenness of FreeBSD power management as = I did laboratory testing of it when I was at Lawrence Berkeley Lab, but = did not really understand the differences between the test-bed and the = real world.=20 >=20 > Throttling is not and never has been a tool for power management. It = was created by Intel as a method of thermal management and the = implementation was manual. That is, some external process had to = activate it. It was replaced in 2000 by TCC (Thermal Control Circuit) = which did the exact same thing, but was entirely internal to the = processor and was thus consistent and uniformly implemented. Throttling = was still present for compatibility, but is really, really obsolete. >=20 > Both throttling and TCC so the same thing. They reduce the heat = generated by skipping 'N' of every 8 clock cycles. They don't actually = change the clock speed. EST, which actually does slow the clock as well = as reducing the core voltage should still provide a a few clock speeds. = The number is dependent on the particular CPU, but usually between 3 and = 8. It does save power, but not very effectively. >=20 > Unfortunately, many thought that throttling was a way to do power = management. In fact, except in a few real-time edge cases, it is totally = ineffective for that purpose. >=20 > The problem you are having is probably that enabling the newer, really = effective power management tool was not committed to 10.2 when TCC was = disabled. It is now in HEAD and I am hoping to see it in 10.3 as well as = 11. (I'm not a committer, so I only can go on what I've been told by the = one who committed disabling TCC.) >=20 > C-states do not change the clock speed. You will only have a small set = of frequencies reported as those will be REAL clock speeds from EST, not = the synthetic ones shown when using throttling/TCC, so the number of = them shown by default on 10.2 will be 1/8th of when was shown by prior = versions. >=20 > I you do need to do this, please let us know. That should not be = happening! >=20 > I am now working (slowly) on a power management section of the = handbook which will do a better job of explaining the issues. > -- > Kevin Oberman, Part time goatherd and retired Network Engineer >=20 >=20 From owner-freebsd-acpi@freebsd.org Sat Sep 26 08:54:24 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 6CA8CA08EBC for ; Sat, 26 Sep 2015 08:54:24 +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 6A6AA69C; Sat, 26 Sep 2015 08:54:23 +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 t8Q8sBPv046489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sat, 26 Sep 2015 10:54:18 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: disabling sleep when shutting down To: Colin Percival , Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> From: Dan Lukes Reply-To: "freebsd-acpi@freebsd.org" Message-ID: <56065D33.7080109@obluda.cz> Date: Sat, 26 Sep 2015 10:54:11 +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: <560648A7.4030708@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: Sat, 26 Sep 2015 08:54:24 -0000 Colin Percival wrote: > I've written (but not yet actually compiled or tested, so beware of typos) a patch which I think makes sense. It look good. But it seems to me the goal has been lost during discussion. It has been started because of unwilling interaction of LID close and ongoing shutdown, isn't it ? Unless I misunderstood the code, your patch seems to solve it for special case only: hw.acpi.lid_switch_state=S3 But what about Sx states for x -ne 3 ? I don't feel to be expert on ACPI code, thus it's possible those states are handled (=ignored) correctly as well. In such case ignore this message. Dan From owner-freebsd-acpi@freebsd.org Sat Sep 26 09:15: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 7B2CC9B8109 for ; Sat, 26 Sep 2015 09:15:35 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o1.l99.sendgrid.net (o1.l99.sendgrid.net [198.37.153.74]) (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 35F44653 for ; Sat, 26 Sep 2015 09:15:35 +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=QBj5Dy+yg5uq9zFrw+hgfWC/+UI=; b=I8WGsp2gURAOGyBoSS uISvQFnzfModJFjczrzt+hZKJQOhOcBqqFpIe4sbd5qJrK9+fH4wbx1FSlZ9cs6f XOyswftcklNicQx19qTaItg/kpK7BjZLTntKEpJ2ivaMJjiPjCie5oTH8V64O5mQ 4irVUowE7JKF0wpW8s5RTC5t8= Received: by filter0823p1mdw1.sendgrid.net with SMTP id filter0823p1mdw1.7047.560662348 2015-09-26 09:15:32.058209893 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id D5QzgkJ4Re26GclMl8Dn-w for ; Sat, 26 Sep 2015 09:15:32.700 +0000 (UTC) Received: (qmail 90744 invoked from network); 26 Sep 2015 09:15:19 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Sep 2015 09:15:19 -0000 Received: (qmail 47623 invoked from network); 26 Sep 2015 09:15:16 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Sep 2015 09:15:16 -0000 Subject: Re: disabling sleep when shutting down To: "freebsd-acpi@freebsd.org" , Jung-uk Kim , John Baldwin , ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> <56065D33.7080109@obluda.cz> From: Colin Percival Message-ID: <56066224.6020503@freebsd.org> Date: Sat, 26 Sep 2015 02:15:16 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56065D33.7080109@obluda.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCv06w+LEbCMIKBLo64EfUtP13+P0olZBMIJdf czlIiO+J4SUb2pa6G+OKepzW7JR1B9cI5VCBGdWSYeo1Dk/3pA6MulPGwDjuxNS/BDvXYgbtRmHtjy 4vCR5QwPPhsPuns= 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, 26 Sep 2015 09:15:35 -0000 On 09/26/15 01:54, Dan Lukes wrote: > Colin Percival wrote: >> I've written (but not yet actually compiled or tested, so beware of typos) a patch which I think makes sense. > > It look good. > > But it seems to me the goal has been lost during discussion. It has been > started because of unwilling interaction of LID close and ongoing > shutdown, isn't it ? Yes, I tripped over this in the context of "tell FreeBSD to shut down, then close the lid of my laptop". > Unless I misunderstood the code, your patch seems to solve it for > special case only: > hw.acpi.lid_switch_state=S3 > > But what about Sx states for x -ne 3 ? > > I don't feel to be expert on ACPI code, thus it's possible those states > are handled (=ignored) correctly as well. In such case ignore this message. I may be wrong, but I believe all the ACPI Sx states go through the same function which is checking for suspend_blocked in my patch. -- 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 Sat Sep 26 18:00:04 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 8137CA09B51 for ; Sat, 26 Sep 2015 18:00:04 +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 B967AF19; Sat, 26 Sep 2015 18:00:02 +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 t8QHxr3t095641; Sun, 27 Sep 2015 03:59:53 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 27 Sep 2015 03:59:53 +1000 (EST) From: Ian Smith To: Colin Percival cc: Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , Dan Lukes Subject: Re: disabling sleep when shutting down In-Reply-To: <560648A7.4030708@freebsd.org> Message-ID: <20150927024553.L29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------050603020603000908060907 Content-ID: <20150927024553.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, 26 Sep 2015 18:00:04 -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. --------------050603020603000908060907 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20150927024553.P29510@sola.nimnet.asn.au> On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote: > Hi all, > > I think there is consensus for: > * Using a sysctl (simpler than a device node), > * Setting this sysctl on all architectures, > * Calling the sysctl kern.suspend_blocked, > * Consulting the sysctl from the ACPI code (for now) and possibly from > other platform-specific forms of sleeping (in the indefinite future). Sounds all good to me, FWTW. > Points without consensus: > * jkim thinks we should prevent suspend when we're dropping to single-user > mode; I'm not sure I see the point, but I don't think there's any harm in > doing that too. We should prevent suspending _during_ shutdown to SU, of course. Once happily in SU, is there any reason to disallow suspend? I've done it. > * Ian Smith would like to have suspend blocked for the last 5 minutes before > shutdown(8) signals init to shut the system down. I don't think anyone else > has expressed a desire for this, and some people have raised concerns about > blocking suspend for too long in case a system is running out of battery; so > I'm inclined to leave this out at this point. (It would be easy enough to > add the sysctl-frobbing to shutdown(8) if desired later.) Sorry, but that rather misrepresents my position; I was trying to deal specifically with the LID foot-shooting potential, in the case of user- initiated shutdown, so looking at possible mechanisms. Not to worry, I clearly didn't express myself clearly :^\ As jkim pointed out, code speaks for itself, and C is read-only here at best .. though after 30-odd years I can usually follow it around .. > With the above in mind, I've written (but not yet actually compiled or tested, > so beware of typos) a patch which I think makes sense. If nobody is violently > opposed to this I'll make sure I got the details right and then commit this in > a few days. +static void +block_suspend(int block) +{ + + sysctlbyname("kern.suspend_blocked", NULL, NULL, &block, sizeof(block)); +} This doesn't appear to get called? Any idea if any of this may not be straightforward to MFC, to 9 maybe? Thanks for going for the generic solution. Hope it wins that race :) cheers, Ian --------------050603020603000908060907 Content-Type: TEXT/X-PATCH; NAME=block_suspend.patch Content-ID: <20150927024553.X29510@sola.nimnet.asn.au> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=block_suspend.patch Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 288249) +++ sbin/init/init.c (working copy) @@ -1481,6 +1481,16 @@ } /* + * Block (if block == 1) or unblock (if block == 0) suspend. + */ +static void +block_suspend(int block) +{ + + sysctlbyname("kern.suspend_blocked", NULL, NULL, &block, sizeof(block)); +} + +/* * Bring the system down to single user. */ static state_func_t @@ -1487,7 +1497,16 @@ death(void) { session_t *sp; + int block, blocked; + size_t len; + /* Temporarily block suspend. */ + len = sizeof(blocked); + block = 1; + if (sysctlbyname("kern.suspend_blocked", &blocked, &len, + &block, sizeof(block))) + blocked = 0; + /* * Also revoke the TTY here. Because runshutdown() may reopen * the TTY whose getty we're killing here, there is no guarantee @@ -1503,6 +1522,11 @@ /* Try to run the rc.shutdown script within a period of time */ runshutdown(); + /* Unblock suspend if we blocked it. */ + if (!blocked) + sysctlbyname(kern.suspend_blocked", NULL, NULL, + &blocked, sizeof(blocked)); + return (state_func_t) death_single; } Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 288249) +++ sys/dev/acpica/acpi.c (working copy) @@ -2574,8 +2574,11 @@ 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 blocked due to an upcoming shutdown, just return. + */ + if (rebooting || sc->acpi_next_sstate != 0 || suspend_blocked) { return (0); } Index: sys/kern/kern_shutdown.c =================================================================== --- sys/kern/kern_shutdown.c (revision 288249) +++ sys/kern/kern_shutdown.c (working copy) @@ -137,6 +137,10 @@ SYSCTL_INT(_kern_shutdown, OID_AUTO, show_busybufs, CTLFLAG_RW, &show_busybufs, 0, ""); +int suspend_blocked = 0; +SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW, + &suspend_blocked, 0, "Block suspend due to a pending shutdown"); + /* * Variable panicstr contains argument to first call to panic; used as flag * to indicate that the kernel has already called panic. Index: sys/sys/systm.h =================================================================== --- sys/sys/systm.h (revision 288249) +++ sys/sys/systm.h (working copy) @@ -46,6 +46,7 @@ #include /* for people using printf mainly */ extern int cold; /* nonzero if we are doing a cold boot */ +extern int suspend_blocked; /* block suspend due to pending shutdown */ extern int rebooting; /* kern_reboot() has been called. */ extern const char *panicstr; /* panic message */ extern char version[]; /* system version */ --------------050603020603000908060907-- From owner-freebsd-acpi@freebsd.org Sat Sep 26 18:56:34 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 27B48A0A385 for ; Sat, 26 Sep 2015 18:56:34 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o1.l99.sendgrid.net (o1.l99.sendgrid.net [198.37.153.74]) (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 CDA24DDD for ; Sat, 26 Sep 2015 18:56:33 +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=pBAAtdDxX7ygDSkUvFWqC8H99mA=; b=M/NqvSAPftkC3gDXIC S4aTp9WXuZwGsDxlVVs3XRMcjtdLXfNXVgxDSfqoFEOAUftdCwv/HpGjgQf8lxXf /SXJ+ytbiYXKPK4JRnZUFU1SnL5pCFceDLz8TQ7axLUg0fs9tvM/Hd1Gyc9T4p5q J3VrkNzPOheoqz4B/fTz3acj0= Received: by filter0847p1mdw1.sendgrid.net with SMTP id filter0847p1mdw1.4873.5606EA5C38 2015-09-26 18:56:28.848223975 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id OsIq2dW0STOJlwjquVZhEg for ; Sat, 26 Sep 2015 18:56:28.773 +0000 (UTC) Received: (qmail 10359 invoked from network); 26 Sep 2015 18:56:15 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Sep 2015 18:56:15 -0000 Received: (qmail 50354 invoked from network); 26 Sep 2015 18:56:10 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Sep 2015 18:56:10 -0000 Subject: Re: disabling sleep when shutting down To: Ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> <20150927024553.L29510@sola.nimnet.asn.au> Cc: Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , Dan Lukes From: Colin Percival X-Enigmail-Draft-Status: N1110 Message-ID: <5606EA4A.3090705@freebsd.org> Date: Sat, 26 Sep 2015 11:56:10 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150927024553.L29510@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCutq7qM8UfANMMWic7mmEyMrTqkR5CCvNd54E nyaBbnNwSOQEPGPOYumkpAqMZ+xWc8bDJQhQp9xEPwzr0OLF9ejU9rmM7Jm17vgfp4Rk3SBUP1bU7d DhByhyb48Z7HkO5OGd3YYM05SO3Mn60fc1cl 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, 26 Sep 2015 18:56:34 -0000 On 09/26/15 10:59, Ian Smith wrote: > On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote: > > Points without consensus: > > * jkim thinks we should prevent suspend when we're dropping to single-user > > mode; I'm not sure I see the point, but I don't think there's any harm in > > doing that too. > > We should prevent suspending _during_ shutdown to SU, of course. Once > happily in SU, is there any reason to disallow suspend? I've done it. I think the question here was about suspending during the shutdown to single-user mode. This seemed a bit different to me since it's not a "walk away from your laptop" sort of situation. But I've included it (or rather, not *excluded* it) anyway. > > * Ian Smith would like to have suspend blocked for the last 5 minutes before > > shutdown(8) signals init to shut the system down. I don't think anyone else > > has expressed a desire for this, and some people have raised concerns about > > blocking suspend for too long in case a system is running out of battery; so > > I'm inclined to leave this out at this point. (It would be easy enough to > > add the sysctl-frobbing to shutdown(8) if desired later.) > > Sorry, but that rather misrepresents my position; I was trying to deal > specifically with the LID foot-shooting potential, in the case of user- > initiated shutdown, so looking at possible mechanisms. Not to worry, I > clearly didn't express myself clearly :^\ Ok, so you're satisfied with having the suspend-disabling triggered by init (i.e., not happening until shutdown(8) reaches "now")? > +static void > +block_suspend(int block) > +{ > + > + sysctlbyname("kern.suspend_blocked", NULL, NULL, &block, > sizeof(block)); > +} > > This doesn't appear to get called? Err, yes. I wrote a helper function, then decided that since it was just one line I really didn't need to make it a helper function. Pretend it isn't there. ;-) > Any idea if any of this may not be straightforward to MFC, to 9 maybe? Should be trivial to MFC. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid