From owner-freebsd-acpi@freebsd.org Fri Sep 18 07:51:29 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 608889CF9D6 for ; Fri, 18 Sep 2015 07:51:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B95F11CF9; Fri, 18 Sep 2015 07:51:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8I7pGKt076251; Fri, 18 Sep 2015 17:51:17 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 18 Sep 2015 17:51:16 +1000 (EST) From: Ian Smith To: Colin Percival cc: Dan Lukes , jkim@freebsd.org, "freebsd-acpi@freebsd.org" Subject: Re: disabling sleep when shutting down In-Reply-To: <55FB4B4F.2080700@freebsd.org> Message-ID: <20150918161310.U29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> <55FB331A.4010908@obluda.cz> <55FB4B4F.2080700@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 07:51:29 -0000 On Thu, 17 Sep 2015 16:22:55 -0700, Colin Percival wrote: > On 09/17/15 14:39, Dan Lukes wrote: > > Colin Percival wrote: > >> I considered that option but thought that disabling suspend completely > >> would be better in case it was triggered by something else > > > > You has been affected by LID issue - and here I'm with you. > > Ok. But adjusting the sysctl might not be enough; KDE has a "suspend > when lid closed" setting which seems to be broken right now, but if it > worked we would need to figure out how to disable that as well. If our KDE isn't using FreeBSD methods to manage suspend and/or shutdown (given it's generally pretty linux-centric), presumably acpiconf -S{3,5} or in the case of shutdown, perhaps invoking 'shutdown -p now [message]' then that's a separate issue that needs fixing in KDE. I wouldn't even consider trawling through KDE power management code, if I could find it. I think Dan's right, deal with the LID issue by disabling suspend-on-lid in shutdown.c, which needs adding a sysctl handler for it, and just set it to 'NONE' after validating options etc. This won't need to consider any of the other possible circumstances, just disabling a convenience. And then there's what type of shutdown has been issued? -p powerdown? -r reboot? -h halt? No switches to drop to single user? With any delay, or 'now'? And there's the chance that someone has set hw.acpi.disable_on_reboot .. things could get messy, but early disabling of hw.acpi.lid_switch_state sounds pretty safe to me, and you can see by LEDs if the system hasn't suspended after closing the lid, or whether it's shut down, or rebooted. > > Suspend triggered by exhausted battery case needs to be evaluated > > carefully. Battery may be so exhausted so shutdown will not be > > completed. Note that some system (hardware) require no power to maintain > > suspend context, thus suspend may save system. My X200 runs for something like a week suspended from full charge, but I do miss the control APM offered, running scripts at every 10% graduation and on critical low power, charging or discharging. I've managed to get devd to run a script on CMBAT events that logs (among other things) the battery state via acpiconf -i0. The X200 does so on power loss/returned and at 80% and 20%, charging or discharging, but I've yet to add code to parse those looking for capacity less than say 10% to invoke suspend, or critical low power to invoke shutdown, but it's functionality I'd like. > > And what about other reasons for suspends ? I can tell nothing about all > > those cases. Suspend may be triggered for any reason, thus so many > > possible causes. I can't claim all of them are illegitimate and can be > > safely ignored. I wish we should have stronger reason for system global > > behavior change than just feeling (no offense!). > > The example of a system which can usefully suspend but doesn't have enough > battery life left to allow it to complete a normal shutdown seems a bit > implausible, but I'll concede that it's theoretically possible. Maybe we > should have an rc.d script which checks an rc.conf setting? Well I think this has shown there are plenty of possible conditions to consider and possible races to avoid, going down that path. Disabling hw.acpi.lid_switch_state would seem to solve your original problem without needing to mess with ACPI, until such scenarios are examined? cheers, Ian