From owner-freebsd-acpi@freebsd.org Thu Sep 17 21:39:55 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 395F79CEBAD for ; Thu, 17 Sep 2015 21:39:55 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C45F13C3; Thu, 17 Sep 2015 21:39:53 +0000 (UTC) (envelope-from dan@obluda.cz) X-SubmittedBy: id 100000045929 subject /C=CZ/O=Univerzita+20Karlova+20v+20Praze/CN=Dan+20Lukes/unstructuredName=100000045929 issued by /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA+20Personal+20CA+202 auth type TLS.MFF Received: from [172.20.1.29] (fw.ax.cz [77.240.102.126]) (authenticated) by smtp1.ms.mff.cuni.cz (8.14.9/8.14.9) with ESMTP id t8HLdckw079313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 17 Sep 2015 23:39:46 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: disabling sleep when shutting down To: Colin Percival , Ian Smith Cc: "freebsd-acpi@freebsd.org" References: <55FA3848.7090802@freebsd.org> <55FA7F47.6050508@obluda.cz> <20150917211219.M29510@sola.nimnet.asn.au> <55FB187F.2090000@freebsd.org> From: Dan Lukes Message-ID: <55FB331A.4010908@obluda.cz> Date: Thu, 17 Sep 2015 23:39:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <55FB187F.2090000@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 21:39:55 -0000 Colin Percival wrote: > I considered that option but thought that disabling suspend completely > would be better in case it was triggered by something else You has been affected by LID issue - and here I'm with you. Suspend triggered by exhausted battery case needs to be evaluated carefully. Battery may be so exhausted so shutdown will not be completed. Note that some system (hardware) require no power to maintain suspend context, thus suspend may save system. And what about other reasons for suspends ? I can tell nothing about all those cases. Suspend may be triggered for any reason, thus so many possible causes. I can't claim all of them are illegitimate and can be safely ignored. I wish we should have stronger reason for system global behavior change than just feeling (no offense!). Just my $0.02. If system behavior will be changed, I will take it :-) Dan