Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: When starting laptop it enters deep sleep after login. 2. What is the Version-Release number of the kernel: 5.6.14 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Not sure, but seems to be present in latest 5.6.x kernels 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Reboot 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: No idea. 6. Are you running any modules that not shipped with directly Fedora's kernel?: VBox 7. ``` [ 43.879652] wlp0s20f3: associated [ 43.944018] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s20f3: link becomes ready [ 44.196610] tun: Universal TUN/TAP device driver, 1.6 [ 44.197511] virbr0: port 1(virbr0-nic) entered blocking state [ 44.197512] virbr0: port 1(virbr0-nic) entered disabled state [ 44.197587] device virbr0-nic entered promiscuous mode [ 44.463329] virbr0: port 1(virbr0-nic) entered blocking state [ 44.463330] virbr0: port 1(virbr0-nic) entered listening state [ 44.487298] virbr0: port 1(virbr0-nic) entered disabled state [ 44.755363] process 'docker/tmp/qemu-check585923527/check' started with executable stack [ 46.072544] rfkill: input handler disabled [ 46.446903] usb 1-9: reset full-speed USB device number 6 using xhci_hcd [ 46.699560] usb 1-5.2.1: reset high-speed USB device number 11 using xhci_hcd [ 55.015405] rfkill: input handler enabled [ 55.950978] drm: not enough stolen space for compressed buffer (need 25804800 more bytes), disabling. Hint: you may be able to increase stolen memory size in the BIOS to avoid this. [ 58.155531] rfkill: input handler disabled [ 63.033165] usb 4-1.2: Disable of device-initiated U1 failed. [ 63.050286] usb 4-1.2: Disable of device-initiated U2 failed. [ 63.357671] usb 4-1.2: reset SuperSpeedPlus Gen 2 USB device number 3 using xhci_hcd [ 63.877263] PM: suspend entry (deep) [ 63.892125] Filesystems sync: 0.014 seconds [ 63.893651] Freezing user space processes ... (elapsed 0.023 seconds) done. [ 63.917418] OOM killer disabled. [ 63.917418] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 63.918464] printk: Suspending console(s) (use no_console_suspend to debug) [ 63.919448] wlp0s20f3: deauthenticating from 4c:5e:0c:39:de:cd by local choice (Reason: 3=DEAUTH_LEAVING) [ 64.027347] e1000e: EEE TX LPI TIMER: 00000011 [ 64.381852] PM: suspend devices took 0.463 seconds [ 64.401737] ACPI: EC: interrupt blocked [ 64.587461] ACPI: Preparing to enter system sleep state S3 [ 64.592824] ACPI: EC: event blocked [ 64.592825] ACPI: EC: EC stopped [ 64.592825] PM: Saving platform NVS memory [ 64.592842] Disabling non-boot CPUs ... [ 64.593261] IRQ 146: no longer affine to CPU1 [ 64.594280] smpboot: CPU 1 is now offline [ 64.596770] IRQ 147: no longer affine to CPU2 [ 64.597788] smpboot: CPU 2 is now offline [ 64.600569] IRQ 148: no longer affine to CPU3 [ 64.601589] smpboot: CPU 3 is now offline [ 64.604184] IRQ 149: no longer affine to CPU4 [ 64.605538] smpboot: CPU 4 is now offline [ 64.608219] IRQ 150: no longer affine to CPU5 [ 64.609237] smpboot: CPU 5 is now offline [ 64.612237] IRQ 151: no longer affine to CPU6 [ 64.613260] smpboot: CPU 6 is now offline [ 64.616526] IRQ 152: no longer affine to CPU7 [ 64.617551] smpboot: CPU 7 is now offline [ 64.623513] ACPI: Low-level resume complete [ 64.623615] ACPI: EC: EC started [ 64.623615] PM: Restoring platform NVS memory [ 64.624742] Enabling non-boot CPUs ... [ 64.624791] x86: Booting SMP configuration: [ 64.624792] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 64.626333] CPU1 is up [ 64.626352] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 64.626958] CPU2 is up [ 64.626975] smpboot: Booting Node 0 Processor 3 APIC 0x6 [ 64.627594] CPU3 is up [ 64.627610] smpboot: Booting Node 0 Processor 4 APIC 0x1 [ 64.628336] CPU4 is up [ 64.628357] smpboot: Booting Node 0 Processor 5 APIC 0x3 [ 64.628982] CPU5 is up [ 64.628999] smpboot: Booting Node 0 Processor 6 APIC 0x5 [ 64.629654] CPU6 is up [ 64.629672] smpboot: Booting Node 0 Processor 7 APIC 0x7 [ 64.630343] CPU7 is up [ 64.632743] ACPI: Waking up from system sleep state S3 [ 64.715139] ACPI: EC: interrupt unblocked [ 65.974566] ACPI: EC: event unblocked ```
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.