[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Laptop fails to suspend



On 4/27/19 5:25 PM, Sam Smith wrote:
On 3/30/19 2:07 AM, Andrea Borgia wrote:
Il 30/03/19 00:56, Sam Smith ha scritto:


I have an older Lenovo T520 laptop that I've ran Debian on for years and I have never had any issues with putting it to "sleep" or suspending when closing the lid. However after upgrading from stretch to Buster, suspend fails to work.

While researching a similar bug [1] on my EEEpc (similar in the sense that it affected suspend and manifested itself after upgrade), I recall seeing a few bugs that specifically mentioned Lenovo:
https://bugzilla.kernel.org/

So, first thing, have a look if the issue is already known and perhaps fixed upstream.

Next, try these guides:
https://wiki.ubuntu.com/DebuggingKernelSuspend
https://wiki.archlinux.org/index.php/Power_management/Suspend%20and%20hibernate

If you want to bisect kernel changes to find out exactly when it broke, just use the archives.[2]

Good luck :)


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919227
[2] https://snapshot.debian.org/



I've spent another several hours messing with this. Most trouble shooting involves the computer entering suspend but not being able to wake from it. I've tried every possible combination of commands with pm-suspend, s2ram, and systemctl suspend. I've booted into single user mode and unloaded every possible module and that did not help (going into suspend just leaves the screen black and the power led flashing). This page: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt listed some extra trouble shooting steps. I can do any one of:
echo [devices,freezer,platform] > /sys/power/pm_test

followed by a 'echo mem > /sys/power/state'. Those work, but it fails when using 'processors' or 'core' for the pm_test. The debugging webpage states that failing the 'processors' test means: "If the "processors" test fails, the disabling/enabling of nonboot CPUs does not work" and you can further diagnose by playing with /sys/devices/system/cpu/cpu*/online. But setting any cpu's 'online' attr to 0 results in the system still running, but the keyboard not responding and having stuff like this going to console:

INFO: task kworker/7:1:73 blocked for more than 120 seconds.
INFO: task bash:9164 blocked for more than 120 seconds.

So does this mean I have an issue with cpu hotplugging or is that normal?

Regards,



I managed to find the problem. First I booted the Buster live cd and tested suspending from there and it worked fine. I saved the output from 'lsmod' and compared it with the normal system. Not much of a difference other than some kernel timer modules where loaded on the live cd system. About a year ago I had disabled all watchdog timers in the kernel as I was having some random reboot issues. So with that in mind...

In /etc/sysctl.d/local.conf I had:
	kernel.nmi_watchdog=0
	kernel.watchdog=0


And in /etc/modprobe.d/local.conf:
	blacklist iTCO_wdt
	blacklist iTCO_vendor_support


I commented all that out and all is well now.


Reply to: