I've been hacking on an ancient r50e. Despite best efforts, I can't get the thing to wake up properly from suspend or hibernate.

Goes to bed as expected, and won't wake up.

Would love some help if you have any ideas.

Debian minimal install with i3wm. Acpi appears functional, acpi-support configured correctly by every guide I could find.

I'm stumped at this point, and not closing the lid without a plan. :)

@RussSharek

According to linuxcompatible.org/compatdb/d it used to work.

1. Make sure the BIOS/CMOS settings aren't bad. Since it used to work for people without effort, it points to the default settings being safe. Sometimes "better" settings are buggy, so use defaults. (*)

2. Possible issues due to changes in kernel configuration settings. You should be able to easily try changing the prebuilt kernel you're using. You might need to build your own, though.

(*) HDD settings should be preserved.

@RussSharek

And when I say, "HDD settings should be preserved" there are BIOS/CMOS settings that change how the OS sees your hard disk and if things are misaligned the system won't boot. This isn't an issue if you're going to reinstall the system, but should not be considered if you want to preserve things.

@RussSharek

Have you checked the logs after the suspend? Are you sure it is successfully suspending? It would be interesting if it never _quite_ completed the suspend operation, and then couldn't resume.

According to askubuntu.com/questions/279584 sometimes WiFi or graphics cards can mess with suspend/resume. Since it is a laptop, I don't expect a graphics issue, but you might try shutting down the WiFi before you try suspending.

@yam655
It appears it is suspending but the screen isn't turning back on during resume.

@RussSharek

Oh? That's something that should be fixable. Let me see if I can find that...

@RussSharek

So, there's thinkwiki.org/wiki/Category:R5 which pointed me to a dead link, I found a cached copy at archive.li/q6XNW and it mentions:

Suspend-to-Ram (S3)

There are a few things to do just before suspending and right after it, [...] It does the following:
* It switches to console one (prevents problems with after resume).
[...]

That sounds like your issue might be long-standing. Does it go away if you do Control-Alt-F1 before you close the lid?

Follow

@yam655

Sounds like it was never fixed on this older model. It's mostly a learning toy, so if I can neuter the lid switch I may just try that

@RussSharek

If neutering the lid switch is acceptable, screw looking for a software solution and check the CMOS/BIOS. You may be able to neuter it there.

@yam655

I'll have a look at next opportunity. Thanks for the help!

@RussSharek

You're welcome. The references to "Suspend2" in the old docs are for software that became TuxOnIce. There's a "hibernate" script, and it looks like the configuration is /etc/hibernate/hibernate.conf

Hopefully you can disable it in the BIOS, but if you can't, maybe tweaking that configuration will help?

I can't find the docs for TuxOnIce online. I've seen references for two different defunct websites.

@yam655

I tried installing that. It hibernated, tried to recover from it and died on the way back up.

@RussSharek

thinkwiki.org/wiki/How_to_make has all sorts of tidbits.

And by "tidbits" I mean "OMFG I hope you can just disable it."

@yam655

I found that last night and thought the same thing. Fortunately more recent vintage thinkpads behave better.

@RussSharek

There's pieces which could include the solution to your problem there.

It mentions "xset dpms force off", but this means "xset dpms force on" on resume may bring the display to life. ...

The issue with the TuxOnIce/hibernate script and resuming might be the "ACPI S4 hardware signature mismatch" issue ...

The fact that there's all these references to 10+ year old versions of Linux doesn't exactly help, either. 2.4 was 2001. 2.6 was 2003.

@yam655

A little additional poking has revealed two things:

1. There is no way to disable the lid switch in bios.

2. Thusfar, all attempts to make resume of any kind work leave me with a system that appears up and the backlight is on, but the screen won't give me back the console.

I'm appreciating how far things have come since the 'good old days'

@RussSharek

You might need to hunt for the solution for your particular Debian apps, but askubuntu.com/questions/15520/ lists a number of potential starting points.

If you're using SystemD or a component thereof, you need to edit /etc/systemd/logind.conf

If you're using gnome-power-manager, you need to tweak that's settings.

If you're using UPower, you need to tweak /etc/UPower/UPower.conf

@yam655

I saw that mismatch error when hibernate froze the system. Seems to be smart enough to simply recreate the file it needs

@RussSharek

Did you see wiki.debian.org/Suspend ?

Included are how to "Disable suspend and hibernation".

@RussSharek

I also wonder if the "Fixing corrupted video on resume" section might include pieces you need. But the fact that it confirms /etc/systemd/logind.conf as being how to disable the lid switch should be good enough.

@yam655

Ooooh. Disabling kms got the laptop to suspend to ram correctly from the command line, but the lid switch is clearly calling the wrong script. I think you've almost helped me crack it!

@RussSharek

What about /etc/systemd/logind.conf as the way to disable the switch? Does that work?

A full fix would be best, but this will answer the question: Is the systemd logind configuration bypassed right now?

Right now we don't really know what's listening to the lid switch.

@yam655

Okay, progress!

HandleLidSwitch in /etc/systems/logind.conf set to ignore disables suspend as intended. So question of the moment is how do I get the suspend directive it calls to call whichever mojo acpi -s calls which seems to be working, as opposed to whatever default which doesn't seem to want to wake up correctly.

@yam655

Incidentally: Setting it to hibernate has laptop hibernating, but not succeeding in waking up correctly

@RussSharek

Is that the mismatch error? Or is it something else?

@yam655

Unsure. Disabling kms, which was mentioned there, got suspend working from the CLI but not via lid switch. Calling different commands I suspect, though not sure which one systemd uses.

@RussSharek

If wiki.debian.org/SystemdSuspend is any indication, it looks like "systemctl" may be responsible for suspend normally.

@yam655

That's promoting.

Currently running acpitool -s as root suspends correctly, and wakes up with function key press as expected. Lid switch goes to sleep... Forever.

I suppose I'll dig into the manpage you sent later tonight. Damn I appreciate your help on this.

@RussSharek

So, the acpi command is skipping all the logic described in the man page.

@RussSharek

The man page lists a couple script locations that get processed. There are two possibilities:
1. One of the scripts fail on suspend
2. One of the scripts fail on resume

But the whole, "WTF is being run that is killing it" may be solved. (At least in a general sense, at least.)

@yam655

Clearly failing on resume, both in hibernate and suspend.

@RussSharek

Now, if the resume process expects a state that isn't being set -- due to acpitool instead of the expected systemd scripts -- we may be able to fix resume by fixing suspend.

@yam655

Running systemd-sleep as root definitely replicates the broken behavior.

Part of me wonders if I could just replace it with a script that runs acpitool...

@RussSharek

There's a good chance one of the scripts has a comment in it, "this breaks under <some condition>". And that's a condition true for your laptop.

@yam655

My plan is to dig at this later tonight. I did notice that systemd-sleep appears to be a binary.

@RussSharek

You really want to solve it with a configuration fix if possible. The Debian folks tend to be pretty good about making the stuff that can break things tweakable in scripts. Configuration changes will persist through OS upgrades.

It's nice to have the capacity to make patches to fix things, but nobody wants to do that if they don't have to.

Show more
Sign in to participate in the conversation
Mastodon.ART

Mastodon.ART — Your friendly creative home on the Fediverse! Interact with friends and discover new ones, all on a platform that is community-owned and ad-free. Admin: @Curator. Moderators: @EmergencyBattle, @ScribbleAddict, @Adamk678, @Otherbuttons, @katwylder