Bug 1490516 - Unintended suspend
Summary: Unintended suspend
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-11 20:37 UTC by jeremy9856
Modified: 2017-09-25 17:11 UTC (History)
33 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-13 08:21:27 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github MattDevo firmware issues 73 0 None None None 2017-09-13 08:22:41 UTC

Description jeremy9856 2017-09-11 20:37:58 UTC
Hello,

My laptop (HP Chromebook 14 w/ MattDeVo custom firmware) sometime go to sleep without any reason on F26. I ran F25 for month without any problem.

By the way I briefly tried F26 KDE and often the laptop couldn't be suspended (hang on a black screen).

What can produce that ?

Thanks !

Comment 1 jeremy9856 2017-09-12 19:03:44 UTC
It seem the there is fake "Lid closed" event...

sept. 12 19:59:30 hp systemd-logind[759]: Lid opened.
sept. 12 19:59:30 hp systemd-logind[759]: Suspending...
sept. 12 19:59:30 hp systemd-logind[759]: Lid closed.

Comment 2 Michal Schmidt 2017-09-13 08:21:27 UTC
systemd-logind reacts to events from the lid switch input device.
The custom firmware is likely to blame.

You can observe the input events with the libinput tool:
  libinput list-devices
In the output find which /dev/input/... device is identified as a "Lid Switch".
Then:
  libinput debug-events --device /dev/input/...
And you should see the same lid switch events that systemd-logind sees.

As a workaround you can disable lid switch handling in /etc/systemd/logind.conf, by setting HandleLidSwitch=ignore.

It does not look like a bug in systemd. It's just showing the GIGO principle (nonsense inputs lead to nonsense outputs).

Comment 3 jeremy9856 2017-09-13 11:23:44 UTC
Ok thanks, I will check with them. What's surprise me is that I didn't had any problem with Fedora 25 with the same firmware that I run since July.

About the KDE spin suspend problem, I'm looking to see if it's possible to install Fedora twice (Gnome + KDE) with UEFI. The Last time I tried Grub found only one Fedora. If you know how to do it let me know :)

Comment 4 Michal Schmidt 2017-09-15 07:43:19 UTC
You could just add KDE to your Fedora Workstation installation:
dnf group install kde-desktop-environment

Then you can choose "Plasma" as the session type on the gdm login screen.
You can also replace gdm with KDE's preferred display manager, sddm:
systemctl enable --force sddm

Comment 5 jeremy9856 2017-09-15 10:50:08 UTC
Well unfortunately that load gnome services on kde and vice versa and that make things behave strangely.

Comment 6 jeremy9856 2017-09-21 06:15:17 UTC
Well I had an unintended suspend with John Lewis firmware. Either it's a Fedora 26 problem or my lid switch is broken.

Comment 7 Michal Schmidt 2017-09-25 13:22:21 UTC
You could try running a kernel built with CONFIG_ACPI_DEBUG enabled (in Fedora it is enabled in 'kernel-debug' builds). Then in /sys/modules/acpi/parameters you'll find 'debug_layer' and 'debug_level' parameters that you can configure (see https://www.kernel.org/doc/Documentation/acpi/debug.txt) in order to get verbose messages in dmesg when the kernel processes events from the lid switch.

Comment 8 jeremy9856 2017-09-25 17:11:34 UTC
Thank you Michal.


Note You need to log in before you can comment on or make changes to this bug.