Re: disabling sleep when shutting down
On Sat, 26 Sep 2015 11:56:10 -0700, Colin Percival wrote: > 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. Sounds good. As all this shows, we can't assume what anyone might do :) > > > * 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")? Sure, if you're satisfied that 'shutdown [..] now' - or hitting the power button as Dan mentioned - then quickly closing the lid will lose that race. As you say, with this mechanism in place, accessing it from shutdown(8) would be straightforward if deemed necessary. So, yes. > Should be trivial to MFC. Cool. Thanks, Ian ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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
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, , 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", , ,
+ , 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,
+ , 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,
_busybufs, 0, "");
+int suspend_blocked = 0;
+SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW,
+ _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 */
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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, ,
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, IanIndex: 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, , 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", , ,
+ , 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,
+ , 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,
_busybufs, 0, "");
+int suspend_blocked = 0;
+SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW,
+ _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.
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-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", , , +
>> , 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, +
>> , 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-
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-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-
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", , ,
+ , 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,
+ , 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,
_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,
+_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) {
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-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-
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, );
+ 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
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
On Thu, 17 Sep 2015 16:22:55 -0700, Colin Percival wrote:
> On 09/17/15 14:39, Dan Lukes wrote:
> > Colin Percival wrote:
> >> I considered that option but thought that disabling suspend completely
> >> would be better in case it was triggered by something else
> >
> > You has been affected by LID issue - and here I'm with you.
>
> Ok. But adjusting the sysctl might not be enough; KDE has a "suspend
> when lid closed" setting which seems to be broken right now, but if it
> worked we would need to figure out how to disable that as well.
If our KDE isn't using FreeBSD methods to manage suspend and/or shutdown
(given it's generally pretty linux-centric), presumably acpiconf -S{3,5}
or in the case of shutdown, perhaps invoking 'shutdown -p now [message]'
then that's a separate issue that needs fixing in KDE. I wouldn't even
consider trawling through KDE power management code, if I could find it.
I think Dan's right, deal with the LID issue by disabling suspend-on-lid
in shutdown.c, which needs adding a sysctl handler for it, and just set
it to 'NONE' after validating options etc. This won't need to consider
any of the other possible circumstances, just disabling a convenience.
And then there's what type of shutdown has been issued? -p powerdown?
-r reboot? -h halt? No switches to drop to single user? With any
delay, or 'now'?
And there's the chance that someone has set hw.acpi.disable_on_reboot ..
things could get messy, but early disabling of hw.acpi.lid_switch_state
sounds pretty safe to me, and you can see by LEDs if the system hasn't
suspended after closing the lid, or whether it's shut down, or rebooted.
> > Suspend triggered by exhausted battery case needs to be evaluated
> > carefully. Battery may be so exhausted so shutdown will not be
> > completed. Note that some system (hardware) require no power to maintain
> > suspend context, thus suspend may save system.
My X200 runs for something like a week suspended from full charge, but I
do miss the control APM offered, running scripts at every 10% graduation
and on critical low power, charging or discharging. I've managed to get
devd to run a script on CMBAT events that logs (among other things) the
battery state via acpiconf -i0. The X200 does so on power loss/returned
and at 80% and 20%, charging or discharging, but I've yet to add code to
parse those looking for capacity less than say 10% to invoke suspend, or
critical low power to invoke shutdown, but it's functionality I'd like.
> > And what about other reasons for suspends ? I can tell nothing about all
> > those cases. Suspend may be triggered for any reason, thus so many
> > possible causes. I can't claim all of them are illegitimate and can be
> > safely ignored. I wish we should have stronger reason for system global
> > behavior change than just feeling (no offense!).
>
> The example of a system which can usefully suspend but doesn't have enough
> battery life left to allow it to complete a normal shutdown seems a bit
> implausible, but I'll concede that it's theoretically possible. Maybe we
> should have an rc.d script which checks an rc.conf setting?
Well I think this has shown there are plenty of possible conditions to
consider and possible races to avoid, going down that path. Disabling
hw.acpi.lid_switch_state would seem to solve your original problem
without needing to mess with ACPI, until such scenarios are examined?
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
Colin Percival wrote: > The example of a system which can usefully suspend but doesn't have enough > battery life left to allow tit to complete a normal shutdown seems a bit > implausible It's valid for in-kernel portion of shutdown only. But you wish to disable suspend even during userland part of shutdown. Such part is generic shell script and even worse, it include third party scripts. We can tell nothing generic about it. Of course, same apply to suspend as well. Thus is plausible that suspend may take just few seconds, but shutdown take substantially longer. But it's another day now, few hours of sleeping and your idea no longer sound as unacceptable to me as yesterday. As long as default system behavior will remain the same, I have nothing against a tool/method/way that will allow user to block S3 state anytime, including the userland portion of shutdown. It's up to system administrator to turn on such feature whenever he feel it helpful. Suspend triggered by LID I recognize special case - it's easy to evaluate consequences in full, thus I consider acceptable modification of the default system behavior. Just personal opinion ... Dan ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/17/2015 19:12, Colin Percival wrote:
> On 09/17/15 13:31, Jung-uk Kim wrote:
>> On 09/16/2015 23:49, Colin Percival wrote:
>>> I ran into an interesting glitch recently: I told my laptop to
>>> shut down, then closed the lid... and it promptly went into S3.
>>> When I opened the lid a couple days later, it resumed... and
>>> then finished the shutdown which it had started 2 days
>>> earlier.
>>
>> Please try the attached patch.
>
> No, this doesn't do what I wanted. It might be a good idea anyway,
> but your patch only disables suspend once the kernel is trying to
> reboot; what I want is to disable suspend a bit earlier -- once
> rc.shutdown is running and the userland is trying to shut down,
> because at that point unless something breaks horribly we're *about
> to* tell the kernel to shut down even though we haven't gotten
> there quite yet.
Okay. The attached patch is a quick-and-dirty & untested hack for you.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJV/E8NAAoJEHyflib82/FGKB4IAJud2fy+GKB8XLnbKYDv7ftx
WGB3RWXLCRkkSC41YtnVUJUeCWUmXdRpy6DWRQtQQIFvAgV1ZjjZiHQRJzRtKhKW
spPXCUXU9LL7wnYpBWejH9EuH3+xtLLSPxM32eKVRmSgMGUcIse3Q/b2Ztf5yZC5
K0p60jmLvGaXrKgf99tyyX90UUhoJ1bABCVheNuMbf/UuWOJD0AytGDGrKGZckmS
fLm8nPQIYVJIC1Xsu3Av/EfmKgQpNoFGk7pDhQqf5glmC+jgzp4KElo7KA9ekq43
ybBusp8tfjY0LVRCoMB+K35KWku9puYLeBDm/2PygzOXOIzfkBC2F4dpfmDI3vY=
=unIE
-END PGP SIGNATURE-
Index: etc/rc.shutdown
===
--- etc/rc.shutdown (revision 287937)
+++ etc/rc.shutdown (working copy)
@@ -43,6 +43,9 @@ HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
export HOME PATH
+# Temporarily block any suspend requests.
+acpiconf -b 1 >/dev/null 2>&1
+
. /etc/rc.subr
load_rc_config 'XXX'
@@ -109,5 +112,8 @@ fi
# Insert other shutdown procedures here
+# Unblock suspend requests.
+acpiconf -b 0 >/dev/null 2>&1
+
echo '.'
exit 0
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 287937)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -98,6 +98,9 @@ struct callout acpi_sleep_timer;
/* Bitmap of device quirks. */
int acpi_quirks;
+/* Block suspend requests. */
+static int acpi_sleep_blocked;
+
/* Supported sleep states. */
static BOOLEAN acpi_sleep_states[ACPI_S_STATE_COUNT];
@@ -2574,10 +2577,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
if (!acpi_sleep_states[state])
return (EOPNOTSUPP);
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/*
+ * If a reboot/shutdown/suspend request is already in progress
+ * or suspend is explicitly disabled, just return.
+ */
+if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked)
return (0);
-}
/* Wait until sleep is enabled. */
while (sc->acpi_sleep_disabled) {
@@ -3568,6 +3573,9 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t ad
error = *(int *)addr;
error = acpi_AckSleepState(sc->acpi_clone, error);
break;
+case ACPIIO_BLKSLPSTATE:
+ acpi_sleep_blocked = *(int *)addr;
+ break;
case ACPIIO_SETSLPSTATE: /* DEPRECATED */
state = *(int *)addr;
if (state < ACPI_STATE_S0 || state > ACPI_S_STATES_MAX)
Index: sys/dev/acpica/acpiio.h
===
--- sys/dev/acpica/acpiio.h (revision 287937)
+++ sys/dev/acpica/acpiio.h (working copy)
@@ -41,6 +41,9 @@
/* Allow suspend to continue (0) or abort it (errno). */
#define ACPIIO_ACKSLPSTATE _IOW('P', 5, int)
+/* Allow suspend request (0) or block it. */
+#define ACPIIO_BLKSLPSTATE _IOW('P', 6, int)
+
struct acpi_battinfo {
int cap;/* percent */
int min;/* remaining time (in minutes) */
Index: usr.sbin/acpi/acpiconf/acpiconf.8
===
--- usr.sbin/acpi/acpiconf/acpiconf.8 (revision 287937)
+++ usr.sbin/acpi/acpiconf/acpiconf.8 (working copy)
@@ -27,7 +27,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd June 10, 2014
+.Dd September 18, 2015
.Dt ACPICONF 8
.Os
.Sh NAME
@@ -35,6 +35,7 @@
.Nd control ACPI power management
.Sh SYNOPSIS
.Nm
+.Op Fl b Ar block
.Op Fl h
.Op Fl i Ar batt
.Op Fl k Ar ack
@@ -45,7 +46,10 @@ The
utility allows the user control of the ACPI power management
functions.
The following command-line options are recognized:
-.Bl -tag -width ".Fl s Ar type"
+.Bl -tag -width ".Fl b Ar block"
+.It Fl b Ar block
+Block or unblock suspend requests using the argument provided.
+.Sy Most users should not use this option directly.
.It Fl h
Displays a summary of available options.
.It Fl i Ar batt
Index: usr.sbin/acpi/acpiconf/acpiconf.c
===
--- usr.sbin/acpi/acpiconf/acpiconf.c (revision 287937)
+++ usr.sbin/acpi/acpiconf/acpiconf.c (working copy)
@@ -77,6
Re: disabling sleep when shutting down
On 09/18/2015 01:51 PM, Jung-uk Kim wrote: > On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31, Jung-uk Kim > wrote: > >> On 09/16/2015 23:49, Colin Percival wrote: > >>> I ran into an interesting glitch recently: I told my laptop to > >>> shut down, then closed the lid... and it promptly went into S3. > >>> When I opened the lid a couple days later, it resumed... and > >>> then finished the shutdown which it had started 2 days > >>> earlier. > >> > >> Please try the attached patch. > > > No, this doesn't do what I wanted. It might be a good idea anyway, > > but your patch only disables suspend once the kernel is trying to > > reboot; what I want is to disable suspend a bit earlier -- once > > rc.shutdown is running and the userland is trying to shut down, > > because at that point unless something breaks horribly we're *about > > to* tell the kernel to shut down even though we haven't gotten > > there quite yet. > > Okay. The attached patch is a quick-and-dirty & untested hack for you. > > Jung-uk Kim Is it possible for /etc/rc.shutdown to complete, but shutdown not occur? If so, there should be a mechanism to restore the ability to suspend. Other than that, I like it. -- Anthony Jenkins ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/16/2015 23:49, Colin Percival wrote:
> Hi ACPI people,
>
> I ran into an interesting glitch recently: I told my laptop to shut
> down, then closed the lid... and it promptly went into S3. When I
> opened the lid a couple days later, it resumed... and then finished
> the shutdown which it had started 2 days earlier. Meanwhile with
> two days of sitting in S3 instead of S5, the battery had almost
> completely drained.
>
> The obvious answer here is to disable Suspend if we're in the
> shutdown path. My first thought was to make rc.suspend slightly
> smarter, but that isn't good enough since there's a 10 second
> timeout after which the suspend will happen even if rc.suspend
> doesn't send the expected acknowledgment. So I think we need to
> get the kernel ACPI bits to disable Suspend.
>
> It looks to me like adding a sysctl to dev/acpica/acpi.c and
> checking it in acpi_ReqSleepState would work; then we just need a
> line in /etc/rc.shutdown to set the sysctl. But ACPI code scares
> me, so I figured I should check with you guys first... am I missing
> anything?
Please try the attached patch.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJV+yM4AAoJEHyflib82/FGxSUH/3Aw2bk+fDxyLIZHxidyxDRo
jbNwkm8CIPGOOshQy8R/nMULPnCoVkLAuXA9O7rNK4G+PB96FoHHUEp/UoDnZfDF
exINmGs6DM0scx2ioVtXM50+lC1SzMfFtb5VaS5t7lAyLwYFtE2bQaUWINethUW7
WpsJ5eyyyoMwTTnRxIQcaYC9I+8oqjC4W6KOO1VeTxaj8kvnacYtCxoXbEU7NHHX
9IprjpopHz9tNlTWuh+gX2SsgaRD7PhWSAekNcN1okYa6Jj1QGAiBIsNvc0GLmUZ
hYv4GIPjxG1ZwYfu9HDCXp8Yiz3i44GIpC6EKuO2y0WO36DTM4vUYKK0OFjNdbw=
=PVmk
-END PGP SIGNATURE-
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 287922)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -2574,10 +2574,9 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
if (!acpi_sleep_states[state])
return (EOPNOTSUPP);
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/* If a reboot or suspend request is already in progress, just return. */
+if (rebooting || sc->acpi_next_sstate != 0)
return (0);
-}
/* Wait until sleep is enabled. */
while (sc->acpi_sleep_disabled) {
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
Colin Percival wrote: > I considered that option but thought that disabling suspend completely > would be better in case it was triggered by something else You has been affected by LID issue - and here I'm with you. Suspend triggered by exhausted battery case needs to be evaluated carefully. Battery may be so exhausted so shutdown will not be completed. Note that some system (hardware) require no power to maintain suspend context, thus suspend may save system. And what about other reasons for suspends ? I can tell nothing about all those cases. Suspend may be triggered for any reason, thus so many possible causes. I can't claim all of them are illegitimate and can be safely ignored. I wish we should have stronger reason for system global behavior change than just feeling (no offense!). Just my $0.02. If system behavior will be changed, I will take it :-) Dan ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
On 09/17/15 13:31, Jung-uk Kim wrote: > On 09/16/2015 23:49, Colin Percival wrote: >> I ran into an interesting glitch recently: I told my laptop to shut >> down, then closed the lid... and it promptly went into S3. When I >> opened the lid a couple days later, it resumed... and then finished >> the shutdown which it had started 2 days earlier. > > Please try the attached patch. No, this doesn't do what I wanted. It might be a good idea anyway, but your patch only disables suspend once the kernel is trying to reboot; what I want is to disable suspend a bit earlier -- once rc.shutdown is running and the userland is trying to shut down, because at that point unless something breaks horribly we're *about to* tell the kernel to shut down even though we haven't gotten there quite yet. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
