Created attachment 868648 [details] Output of dmesg Description of problem: A recent change in the "rawhide" tree causes a ThinkPad T400 which is attached to a docking station (plus external monitor) with its lid closed to suspend after booting up. Upon pressing the power button in order to resume it suspends again within a few seconds. Version-Release number of selected component (if applicable): kernel-3.14.0-0.rc4.git0.2.fc21.x86_64 How reproducible: Always. Steps to Reproduce: 1. Boot system. Actual results: Instead of displaying the login manager, the system suspends. Expected results: The login manager is displayed and it is possible to log in. Additional info: The system is usable only after opening the lid, either using the internal display or after redirecting the monitor output to the external monitor.
Created attachment 868649 [details] Xorg log file Xorg.0.log
logind from systemd 210 is much more aggressive with suspending based on lid events. I would imagine it is that change that is causing the results you are seeing instead of the kernel. Can you attach the journal output for this boot/suspend cycle? Can you install the 3.13.5 F20 kernel on your system using "rpm -ivh --oldpackage <kernel rpm>" and make sure you still see the same thing? It's important to freshly install it so that the initramfs picks up systemd 210 from your system when it's created.
Created attachment 869268 [details] System journal file /var/log/*/system.journal kernel-3.13.5-200.fc20.x86_64 behaves exactly like the ``rawhide'' development kernel.
A downgrade to systemd-208-14.fc21.x86_64 cures the suspend issue with kernel-3.14.0-0.rc4.git0.2.fc21.x86_64 but then the system hangs at start-up and when shutting it down (rescue mode works though). Only the additional downgrade to kernel-3.13.5-200.fc20.x86_64 restores the ability to boot and shut down the system as expected.
OK. The lid suspend issue seems to be related to the logind change I mentioned.
``logind is now a lot more aggressive when suspending the machine due to a closed laptop lid. Instead of acting only on the lid close action it will continuously watch the lid status and act on it.'' This recent change forces a docked notebook attached to an external monitor into suspend whenever systemd finds out that the lid *is* closed instead of watching lid *events* which is unacceptable. Is there a workaround or an updated package to settle this issue which prevents my system from staying in sync withe the ``rawhide'' tree? Many recent packages require systemd-210. Thanks!
Fixed in git.
The option ``HandleLidSwitch=ignore'' in logind.conf restores proper suspend behaviour but the true solution is of course to check whether an external monitor is both attached and active (video output is redirected to the latter). Only then are setups like that of a docked notebook without an external monitor etc. treated correctly.
Iuuc, we now check if a monitor is *connected*. Checking if it is actually active is not something that can be done easily. You could always turn the monitor *off*, and I don't think it's possible to detect that.
Issue is back in Fedora 21 and the current development tree when adding "nomodeset" to the kernel options. The system behaves correctly though when kernel modesetting is enabled.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
I have just upgraded my Dell Latitude E6530 (with a NVS 5200M GPU) from Fedora 23 to Fedora 24. This issue arose after the upgrade. It worked fine using F23. A regression? The nvidia blob is used, version 367.27, with nomodeset (as modeset is not working). The nouveau driver fails completely, so can't test if that makes a difference.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I can reproduce this bug on Fedora 24 as stated. So in my opinion this bug should not be closed. How can i reopen this bug?
Issue was reported for a system using kernel modesetting and is definitely resolved for current Fedora 23. The issue related to booting in basic graphics mode w/o kernel modesetting referred to in comment 12 is a different issue and has been reported in the separate bug 1358306.