Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration

Zygo Blaxell zblaxell at quark.hungrycats.org
Wed Mar 20 17:03:59 GMT 2019


On Wed, Mar 20, 2019 at 01:37:50PM +0000, Mark Hindley wrote:
> Tags: moreinfo
> 
> On Sat, Jan 19, 2019 at 10:34:02AM +0000, Mark Hindley wrote:
> > One issue I will pass upstream is why the Docked status is taking so long to
> > update. Once docked elogind should be ignoring lid events by default. (I know
> > this doesn't address the underlying issue in this case, but it would no longer
> > be problematic.)
> 
> Zygo,
> 
> We have not yet found why the Docked status is slow to update and we don't have
> access to any hardware to reproduce.
> 
> Are you able to build a debugging version  of elogind and post the log?

The hardware has been returned to the end user (with no elogind package).

About 1 in 4 laptops that I see needs to have ACPI suspend disabled
or limited, either because of broken switch sensors, or because the
ACPI firmware or Linux kernel crashes before completing resume.
On desktops...I've never personally seen a desktop running Linux
successfully suspend and resume afterwards, but I'm told they exist.

We don't have time to debug ACPI firmware--the defect rate is just
too high.  We just disable suspend by default, and re-enable it only on
hardware where it is known to work.

Earlier:
> Users should be warned of potential interactions among the two
> packages, but not deprived of the freedom to handle and resolve those
> interactions if they like to, IMHO.

Maybe it should be in the package's news or debconf, so the admin is
notified when the package is installed for the first time on an existing
system (as opposed to a fresh install).  A statement something like:

	"Installing this package may change the way ACPI events such as
	lid-close are handled.	If you know that's going to be a problem
	on your hardware, you should do something about this now."

That would give a chance to defer or abort the installation while
workarounds get lined up.  If it was debconf, you could even ask whether
suspend should be enabled and put the installer's answer in the config
file.

Bonus points for something like "I'm going to try 10 suspend/resume cycles
now, if the system crashes, reboot it, and when the installer runs again,
I'll disable suspend for you."  };->


> Thanks
> 
> Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20190320/e409a76d/attachment.sig>


More information about the Debian-init-diversity mailing list