FS#40140 - [systemd] logind refuses t suspend on lid close w/ NVidia binary blob, upstream patch in description

Attached to Project: Arch Linux
Opened by Benjamin Podszun (darklajid) - Tuesday, 29 April 2014, 13:54 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Thursday, 01 May 2014, 19:37 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Thinkpad T520. I set the severity to medium (actually I was tempted to choose 'high'), because hardware damage is entirely possible and likely.

For quite a while/since a recent update to either systemd or the proprietary nvidia driver (sorry!), this Thinkpad doesn't suspend anymore when the lid is closed. That event is ignored, laptop stays on, gets hot and probably dies if this happens a couple more times.

The problem is logind, which looks at the number of the connected displays(!) before it considers to suspend the machine. Worse, it checks for $numberOfDisplays != 1. For binary blob users like me logind comes up empty and actually thinks that my laptop has no connected display, so there's no point suspending, right?

Additional info:
* core/systemd 212-3

Steps to reproduce:

Enable logind debugging messages:
systemctl set-environment SYSTEMD_LOG_LEVEL=debug && systemctl restart systemd-logind && systemctl unset-environment SYSTEMD_LOG_LEVEL

Apr 29 15:43:53 TIS-Ben-T520 systemd-logind[22264]: Lid closed.
Apr 29 15:43:53 TIS-Ben-T520 systemd-logind[22264]: Ignoring lid switch request, 0 displays connected.
Apr 29 15:43:53 TIS-Ben-T520 systemd-logind[22264]: Ignoring lid switch request, 0 displays connected.
Apr 29 15:43:53 TIS-Ben-T520 logger[22270]: LID closed
Apr 29 15:43:58 TIS-Ben-T520 systemd-logind[22264]: Lid opened.
Apr 29 15:43:58 TIS-Ben-T520 logger[22273]: LID opened

If you don't know the magic incantation to enable debugging messages you get absolutely nothing of value in the logs:

Apr 29 15:44:49 TIS-Ben-T520 systemd-logind[22288]: Lid closed.
Apr 29 15:44:49 TIS-Ben-T520 logger[22291]: LID closed
Apr 29 15:44:54 TIS-Ben-T520 systemd-logind[22288]: Lid opened.
Apr 29 15:44:54 TIS-Ben-T520 logger[22293]: LID opened

The check for connected devices seems to be linked to DRM support. A patch that would solve this issue for machines like mine is at [1].
Although upstream knows about this problem and has multiple reports about it, I'm escalating it here and hope for patch in Arch for the time being - especially since upstream seems to think that 'NVidia should fix their driver' is the better choice for this issue [2].

I know the general rule is to work with upstream and avoid modifications where possible, but this seems a high risk issue. Admittedly I don't know how large a percentage of the Arch user base is affected (i.e. using latest systemd/nvidia on a laptop - maybe it happens with other proprietary drivers as well though?), but this is a bug that (repeating myself, I know) might destroy hardware and it has _no_ workaround as far as I'm aware (other than always remembering to power down your machine..).

1: http://article.gmane.org/gmane.comp.sysutils.systemd.devel/18764
2: http://article.gmane.org/gmane.comp.sysutils.systemd.devel/18787
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Thursday, 01 May 2014, 19:37 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#39530 
Comment by Dave Reisner (falconindy) - Tuesday, 29 April 2014, 14:17 GMT
As a suggestion, write your own hook for acpid which calls 'systemctl suspend'. I'm extremely uninterested in carrying patches against systemd in Arch.
Comment by Benjamin Podszun (darklajid) - Tuesday, 29 April 2014, 14:46 GMT
I certainly understand the sentiment.

By default, acpid won't handle lid switches (logind grabs those, logind.conf needs to be changed at least - I'll give that a try now).
The biggest concern is discoverability (is that a word?) though, I think. As I stated above: Suspend silently fails and you have no place to start, ignoring the fact that this is rather dangerous and .. annoying in the first place.

Different idea: What about a warning in the Arch Linux news [1]? I expect users to check that page if they run into trouble after some upgrades (better: before upgrading) and if 'PS/2 might stop working for you' is worth a warning, maybe 'Your laptop might die in your backpack unless you're careful and follow some manual steps' might be worth an entry as well? The bug (is that even arguable?) was introduced in [2], on the third of March (i.e. 'recently'). Upstream has a bug at [3], but no result after quite some time (and the ml link from my original report gives the impression that it is of no concern for them).

The Arch BBS contains a good number of threads of people with the same problem [4].
You closed related bugs as 'upstream' with a reference to [3] already ([5]).

Bottom line: From a security (as in, "please don't destroy my hardware, will you") and awareness standpoint I think this deserves more than random BBS posts about laptops growing hot. Bad idea?

1: https://www.archlinux.org/
2: http://cgit.freedesktop.org/systemd/systemd/commit/src/login/logind-action.c?id=6a79c58603ea816a1b4fa1520397b4e138bc1ca0
3: https://bugs.freedesktop.org/show_bug.cgi?id=76267
4:
https://bbs.archlinux.org/viewtopic.php?id=179732
https://bbs.archlinux.org/viewtopic.php?id=179382
https://bbs.archlinux.org/viewtopic.php?pid=1393954#p1393954
5: https://bugs.archlinux.org/task/39530
Comment by Mantas Mikulėnas (grawity) - Tuesday, 29 April 2014, 14:50 GMT
> By default, acpid won't handle lid switches (logind grabs those, logind.conf needs to be changed at least - I'll give that a try now).

Neither logind nor acpid "grab" the input devices; there can be multiple readers. In fact, you already have acpid running and its handler.sh is printing the "logger: LID closed" messages in your syslog.
Comment by Benjamin Podszun (darklajid) - Tuesday, 29 April 2014, 14:54 GMT
Thanks a lot. My bad, I should've tested that first. I got confused by this part of the man page of acpid:

When troubleshooting acpid, it is important to be aware that other parts of a system might be handling ACPI events. systemd(1) is capable of handling the power switch and various other events that are commonly handled by acpid. See the description of HandlePowerKey in logind.conf(5) for more. Some window managers also take over acpid's normal handling of the power button and other events.

By now I understand that I misread that. Sorry for the noise.

Loading...