FS#59167 - [linux] Thinkpad T430s. Suspend works only ONCE after a reboot.
Attached to Project:
Arch Linux
Opened by Marek Kozlowski (guayaseal) - Thursday, 28 June 2018, 06:19 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 05 October 2018, 16:36 GMT
Opened by Marek Kozlowski (guayaseal) - Thursday, 28 June 2018, 06:19 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 05 October 2018, 16:36 GMT
|
Details
Description:
Thinkpad T430s. After reboot suspending (with a lid, a key or just `echo -n "mem" > /sys/power/state' works correctly once. Subsequent attempts result in suspending... and waking up immediately. After reboot again - it works once. Additional info: up-to-date system, kernel 4.17.2-1, systemd 238.133-4, xfce as a desktop environment (honestly, I think it doesn't matter), no systemd config customizations, any changes to `/proc/acpi/wakeup' don't help, log containing entries for the first and the second attempts after a reboot attached system hardware configuration attached Steps to reproduce: Suspend with an XFCE button, with closing a lid or just `echo -n "mem" > /sys/power/state' |
This task depends upon
4.14-LTS works fine with no problem,
4.17.4-1 is still affected.
4.17.5-1 is still affected
https://bbs.archlinux.org/viewtopic.php?pid=1797473
4.17.2-1-ARCH
Kernel: 4.17.5-1-ARCH
Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
First suspend after a reboot works, after that, any type of suspend, reboot or shutdown triggers a kernel panic. It happens so late in the process that I can't find any logs, I think the journal has already been shut down before the panic happens.
I tried to turn off (instead of suspend this time) and in fact there is a kernel panic.
I took two photos of the screen.
P_20180721_025445__.jpg (96 KiB)
Dell Latitude E7440, some old BIOS. No Nvidia hardware.
Not reproducible on LTS 4.14 kernel.
I also feel the severity is too low: This bug makes my laptop unusable for its intended use case.
Having proper suspend should not be considered an "optional-feature".
It is not a packaging or integration issue so you are expected to work with upstream to resolve it.
Once you have a patch from upstream the kernel package maintainers could apply it.
However, due to path changes in the 4.17 kernels I tried, I started up without bbswitch running and it worked fine.
So I investigated and apparently, when I enable my discrete GPU first with bbswitch, the suspend is working.
Also it seems to be safe to turn it off again until the next suspend.
This still appears to be the only place where this is mentioned, couldn't find anything upstream.
Could someone else affected try suspending with enabled discrete GPU and report?
Edit: Appears to be a litte more specific. I tried to automate that workaround, but enabling the GPU via systemd-unit right before sleep.target does not prevent the system from hanging on the second suspend!
Will investigate further, trying delays between enabling and suspending. Also I have to finally figure out the last working kernel.
Anything anywhere upstream yet?
Edit#2:
Okay, now, for me at least, that the discrete graphics can be turned on exactly once. Maybe I broke my notebook, looping through ON/OFF in bbswitch worked yesterday.
The card is turned on by bbswitch on suspend, as apparently, there are devices that don't like being suspended/powered off with the card disabled or can't use them after such an event.
Anyway, without bbswitch module loaded on suspend, it works. I don't know if the discrete card is usable though and this isn't a solution.
It's also clearly not a direct bbswitch fault: When I suspended first and removed bbswitch module after resuming, I "used up" my one enabling. When shutting down after that, the kernel also tries to enable the card very late in the halt routine, but it still fails. Luckily, kernel doesn't care for suspend here.
The consistend log line is:
> pci 0000:01:00.0: Refused to change power state, currently in D3
Possibly related: https://bbs.archlinux.org/viewtopic.php?id=238389
We'll need to work with upstream on getting this resolved, I'm sure, but if the problem goes away for some of us, that would be important to know.
Edit: kernel 4, not 14
Edit2: damnit, Thinkpad, not Dell.
I'm updating to linux-4.18.4.arch1-1 now (latest at time of writing), but I don't expect any changes.
Asus Rog G750JH with Nvidia 780M
I'm on "Linux x230 4.18.5-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018 x86_64 GNU/Linux" now.
The *problem persists*: First suspend after boot works fine. Suspending again will cause immediate wakeup.
The regression appears to be fixed.
Suspend seems to work fine again.
I believe I still had a couple of hangs when returning from suspend a couple of days ago, but that would probably be another issue.
I'm not sure which update fixed it for me, but it must have been 4.18.6 or 4.18.7.