Date: Fri, 18 Sep 2015 17:51:16 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Colin Percival <cperciva@freebsd.org> Cc: Dan Lukes <dan@obluda.cz>, jkim@freebsd.org, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: disabling sleep when shutting down Message-ID: <20150918161310.U29510@sola.nimnet.asn.au> In-Reply-To: <55FB4B4F.2080700@freebsd.org> References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> <55FB331A.4010908@obluda.cz> <55FB4B4F.2080700@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150918161310.U29510>