Bug 1840021

Hmm. The most likely cause of this is that the kernel things the lid of the laptop is closed, which causes userspace to suspend the laptop as soon as userspace registers the close state of the lid.

Can you try adding "button.lid_init_state=ignore" to the kernel commandline and see if that helps ?

Please do: "cat /proc/cmdline" to verify that you have correctly added this to the commandline.

Oh, lid is actually closed and on docking. Good call, will going to give it a try.

Is this how it should be configured in this scenario?

Thanks!

(In reply to Marko Bevc from comment #2)
> Oh, lid is actually closed and on docking. Good call, will going to give it
> a try.
> 
> Is this how it should be configured in this scenario?

Hmm, if the laptop is docked it is a bit of a different story. AFAIK systemd ignores the initial LID state, only reacting to status changes. So that leaves your desktop-environment as the culprit. At least with GNOME it should not suspend the machine based on lid status if external monitors are present. Does your external display light up before the suspend happens? Sometimes probing thunderbolt connected displays can be slow, if it is too slow it might not see the external monitor when gdm starts and gdm sees the lid is closed + no external monitor and responds to that ...

Doing the kernel cmdline option is probably still going to help with the symptoms but it will only point us in the wrong direction for the solution.

Quick hack idea, can you try creating a:

/etc/rc.d/rc.local

With the following in there:

#!/bin/sh
sleep 10

That should delay gdm starting and prove or disprove my external monitor not being probed yet theory. Do not forget to "chmod +x" the file.

Oh, exact process is:
1. it boots
2. get to the login screen (GNOME)
3. login (screen goes dark, probably due switching to Xorg-reasons)
4. hibernate

I think you're right here, perhaps that switch is too slow as docking for T490s is via TB3 now and might be to slow...hm

I'll give it a go with sleep, but are there any other options here?

After some testing posting my discoveries here:
- 1st suggestion didn't helped as it affect only boot process and I've ended up screen not moved to external screen
- 2nd suggestion unfortunately also didn't do anything

I've also confirmed it's only an issue when logging in using GNOME Xorg, but works fine with Wayland on GNOME. Not sure if it's just too long to detect an active monitor or something else here when using Xorg window manager...

Any new suggestions welcome :)

Thanks!

Ok, so here is how this all works.

systemd-logind will automatically suspend the machine when the lid is closed unless the machine is considered docked or has external displays, also see:

https://github.com/systemd/systemd/issues/5451

AFAIK a thunderbolt dock does not report a "docked" status to userspace in anyway, so we are solely reliant on the external-displays detection here.

I guess what is happening is that Xorg re-probes the external monitors when it starts and that causes them to temporarily disappear from whatever interface systemd-logind is using to check for external monitors and then systemd-logind suspends the system because:

a) The lid is closed; and
b) It is not docked (to a traditional dock which reports SW_DOCKED to userspace); and
c) There are no external monitors (visible to systemd-logind at the time when it makes the decision)

I'm not 100% sure this is what is happening but it seems the most likely cause.

As a workaround try editing /etc/systemd/logind.conf, uncomment:

#HandleLidSwitchExternalPower=suspend

And change to:

HandleLidSwitchExternalPower=ignore

Since when docked you do have external power that should fix it, with the caveat that the laptop will now no longer suspend when charging with a "normal" charger and the lid is closed.

If this helps perhaps you can file a new issue with systemd upstream for this, with a pointer to this bug and the other systemd issue. Just copy and paste my theory there. A possible fix would be for systemd to wait a bit and re-check when external monitors go away. In my experience with TB3 docks when the DisplayPort MST display stuff the use gets re-enumerated for some reason the displays can easily go away for 10 seconds.

And/or maybe we need to find a way to report SW_DOCKED to userspace when connected to a TB3 dock. 

And/or we need to figure out why the re-enumeration is being triggered with the newer kernels, do you know if this also happens with a 5.5 or 5.4 kernel?

I'll try that as well, thanks!

Double checked docking and it's USB-C connection and not Thunderbolt3, but assuming it's same thing not reporting SW_DOCKED...

Found this upstream: https://github.com/systemd/systemd/issues/5451

And running: `busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager Docked`

is detecting my USB-C docking as docked, so probably there is really issue with just monitor detection being slow?

(In reply to Marko Bevc from comment #8)
> Found this upstream: https://github.com/systemd/systemd/issues/5451
> 
> And running: `busctl get-property org.freedesktop.login1
> /org/freedesktop/login1 org.freedesktop.login1.Manager Docked`
> 
> is detecting my USB-C docking as docked, so probably there is really issue
> with just monitor detection being slow?

Yes, slow on the kernel side / too fast on the systemd-logind side. As said I think that logind needs to wait a bit before suspending the machine when the (last) external monitor goes away, as it might only be temporarily going away because the DP MST stuff is being re-enumerated.

Can you please file a systemd issue for this?

also opened issue on their GH: https://github.com/systemd/systemd/issues/16045

Hm, this is gotten worse on latest 5.8.x kernel build: https://bugzilla.redhat.com/show_bug.cgi?id=1874782

Using suggested workaround does wake it up eventually (takes really long for monitor to get detected and getting input), but dmesg also produces:
```
[  387.747807] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 0000000062584252 port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  388.320018] i915 0000:00:02.0: [drm] *ERROR* failed to allocate vcpi
[  391.320907] [drm:drm_dp_check_act_status [drm_kms_helper]] *ERROR* Failed to get ACT after 3000ms, last status: 00
[  391.679251] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000b3d8c323 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  395.113002] [drm:drm_dp_check_act_status [drm_kms_helper]] *ERROR* Failed to get ACT after 3000ms, last status: 00
[  396.150476] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 0000000062584252 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  396.348115] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 0000000062584252 port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  396.929159] i915 0000:00:02.0: [drm] *ERROR* failed to allocate vcpi
[  399.930097] [drm:drm_dp_check_act_status [drm_kms_helper]] *ERROR* Failed to get ACT after 3000ms, last status: 00
[  400.280769] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  400.479025] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.389379] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.446100] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.532722] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.560854] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.648229] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.676011] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.704252] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.791898] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.820663] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.849035] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.936254] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.964002] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  406.991702] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  407.077868] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  407.106096] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  407.193253] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  413.386076] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[  413.442356] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a11bbb4e port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
```

Seems it's gotten worse in 5.8.10 as doesn't wake up monitor at at when docked and lid is closed.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

The workaround is simple: /etc/systemd/logind.conf HandleLidSwitchExternalPower=ignore
But they WONTFIXed it upstream: https://github.com/systemd/systemd/pull/19490

Besides that I have found this my workaround got lost from my /etc/systemd/logind.conf but curiously I no longer get the suspends during boot. Maybe it better detects I am on a docking station (which is now my display, a change compared to when I was dealing with this Bug).

This message is a reminder that Fedora Linux 40 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '40'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 40 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.