Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #206790 > unrolled thread

Laptop fails to suspend

Back to article view | Back to linux.debian.user

Contents

  Laptop fails to suspend Sam Smith <debian@net153.net> - 2019-03-30 01:00 +0100
    Re: Laptop fails to suspend Esteban L <esteban@little-beak.com> - 2019-03-30 04:40 +0100
    Re: Laptop fails to suspend Andrea Borgia <andrea@borgia.bo.it> - 2019-03-30 08:10 +0100
      Re: Laptop fails to suspend Sam Smith <debian@net153.net> - 2019-04-28 00:30 +0200
        Re: Laptop fails to suspend Andrea Borgia <andrea@borgia.bo.it> - 2019-04-28 20:10 +0200
        Re: Laptop fails to suspend Sam Smith <debian@net153.net> - 2019-05-08 17:50 +0200

#206790 — Laptop fails to suspend

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.

I run KDE and I've tried to suspend from the desktop using the built in 
"suspend" button (right next to "shutdown" or "reboot" buttons), as well 
as using systemd or pm-suspend from the command line but they all result 
in the same issue. The issue is that once the machine starts to go into 
suspend mode, the power led flashes and the screen then goes blank. 
Normally at this point the power led would stop flashing and would stay 
off, however it keeps flashing. I've left it for a couple of minutes but 
it never stops. Keyboard is unresponsive and I have to force it to power 
off (hold down power button). How might I go about trouble shooting this?

Thanks,
Sam

[toc] | [next] | [standalone]

#206800

[Multipart message — attachments visible in raw view] — view raw

Hello,

Unless I am mistaken, Buster is still in development/testing?

If thats the case, I would expect behavior exactly like that.

As to troubleshooting it? My guess is you would have to be a talented program, to debug, and code your own modules.

On March 30, 2019 12:56:12 AM GMT+01:00, Sam Smith <debian@net153.net> wrote:
>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.
>
>I run KDE and I've tried to suspend from the desktop using the built in
>
>"suspend" button (right next to "shutdown" or "reboot" buttons), as
>well 
>as using systemd or pm-suspend from the command line but they all
>result 
>in the same issue. The issue is that once the machine starts to go into
>
>suspend mode, the power led flashes and the screen then goes blank. 
>Normally at this point the power led would stop flashing and would stay
>
>off, however it keeps flashing. I've left it for a couple of minutes
>but 
>it never stops. Keyboard is unresponsive and I have to force it to
>power 
>off (hold down power button). How might I go about trouble shooting
>this?
>
>Thanks,
>Sam

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#206802

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/

[toc] | [prev] | [next] | [standalone]

#207917

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,

[toc] | [prev] | [next] | [standalone]

#207933

Il 28/04/19 00:25, Sam Smith ha scritto:

> 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?

AFAIK it isn't normal but I wouldn't know how serious it is or whether 
it is related to hotplugging, sorry.

Andrea.

[toc] | [prev] | [next] | [standalone]

#208404

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web