Created attachment 1409861 [details] dmesg output for working (4.14.18) Description of problem: For the past few weeks, suspend doesn't seem to complete on a ThinkPad p50. Previously, it was working fine. When I initiate the suspend, the laptop + second monitor go blank and it appears that the system has (almost fully suspended), except that the power button light is not flashing, as it should after suspending (instead it is solid on). If I attempt to resume, pressing the power button is ignored. The workaround is to hold the power button down until full power down. Another workaround is to to install older 4.14.18-300.fc27.x86_64 kernel. Version-Release number of selected component (if applicable): Occurs with 4.15.8-300.fc27.x86_64 How reproducible: Recreates every time on ThinkPad p50 Steps to Reproduce: 1. Boot Fedora (currently using GNOME with Wayland disabled). 2. Click on Suspend in menu. 3. wait for power button to flicker but that will not happen, it stays solid on. Actual results: Expected results: Additional info:
Created attachment 1409862 [details] dmesg output from non-working (4.15.10 from updates-testing repository) kernel
You should probably file a bug at bugzilla.kernel.org. The upstream devs are in a better position to narrow down what broke suspend/resume. You could also do a kernel bisect yourself to see which commit broke.
Thanks Laura, I will file a bugzilla.kernel.org bug.
I tried searching on bugzilla.kernel.org first to see if anyone reported the same issue, hard to tell. I suppose that someone can report the issue as a duplicate if it is, so will report it soon.
Created (upstream) issue https://bugzilla.kernel.org/show_bug.cgi?id=199195
I've used "git bisect run" to find the cause of regressions in WildFly but haven't ever tried that with linking the Linux kernel for my primary work machine. I assume that instead of running "git bisect run", we would instead manually step through. Maybe something like: git bisect start git bisect good COMMIT_ID_FROM_4.14.18_KERNEL git bisect bad COMMIT_ID_FROM_4.15.8_KERNEL link kernel, reboot and try linked kernel (e.g. try OS suspend, issue 'git bisect good' if works, else reboot and issue 'git bisect bad'). Are there any shared scripts that guide/drive this process?
Yes, that's pretty much the process. There's a guide on building a vanilla kernel (https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_Vanilla_upstream_kernel) which should get you going.
I've done some testing and I'm not convinced it's the kernel that's the problem. Clean installs on an external drive of F27 and F28 booting the F27 kernel don't show the problem. But more convincing is that if I do "echo mem > /sys/power/state", the laptop suspends and resumes with no problem. There's something else going wrong in the sequence of suspending. It is still strange that when booting with the 4.14.x kernel, suspend works.
As I mentioned in the kernel bug, I have seen this same problem on another laptop which has an AMD chipset. Also, I hit the same hang with the /sys/power/state workaround which I thought was working. So it looks like it is the kernel, but maybe there's a race condition somewhere because often the /sys/power/state option works, but using the suspend key always hangs.
I installed Fedora 28 eight days ago and cannot now recreate the failure. I also installed 4.17.0-0.rc7.git1.1.fc29.x86_64 and restarted. I was able to repeatedly (OS) suspend four times without trouble. uname -a Linux smarlowp50.localdomain 4.17.0-0.rc7.git1.1.fc29.x86_64 #1 SMP Wed May 30 16:05:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux RPMs that I installed: kernel-4.17.0-0.rc7.git1.1.fc29.x86_64 kernel-core-4.17.0-0.rc7.git1.1.fc29.x86_64 kernel-devel-4.17.0-0.rc7.git1.1.fc29.x86_64 kernel-headers-4.17.0-0.rc7.git1.1.fc29.x86_64 kernel-modules-4.17.0-0.rc7.git1.1.fc29.x86_64 kernel-modules-extra-4.17.0-0.rc7.git1.1.fc29.x86_64 The upstream issue https://bugzilla.kernel.org/show_bug.cgi?id=199195 was closed, I think that this one can also be closed.
Thanks for letting us know.
I can also verify that upgrading to F28 solved the problem using the 4.16 kernel.