Librem 11 won't wake up after (unexpected) suspend/hibernate unless turned off and on again

(I will email the support if the community does not know the answer)

With power cable attached, and the following power settings:

  • Power Mode: Balanced
  • Automatic Suspend: Off
  • Power Button Behavior: Nothing

— when the power button is pressed shortly, Librem 11 locks the screen and turns display off. If we press the power button again shortly afterwards, the display turns back on. Though this does not quite match the “Nothing” setting for “Power Button Behavior”, this is how I want it.

However, if the device is left alone after locking/turning the screen off for long enough, it will not wake up on pressing the power button.

The only way to wake it up is to press the power button for long (10+ seconds) after which the blue LED turns off (the device turns off), and turn it on/boot again.

What happens after leaving the device with locked screen long enough with power cable attached? Suspend? Hibernate? Why? Why doesn’t it just stay locked and ready to wake up?

3 Likes

@Greendrake I’ve seen this occasionally. I fixed an issue in PureBoot 29 that was causing failures to resume from suspend, but I omitted it from the PureBoot 29 changelog since I still saw a failure once in testing. (I think it’s improved, and it does sound like this is a second issue unrelated to suspend causing a similar problem, but I don’t list things in the changelog that aren’t totally fixed.)

Could you update your Librem 11 to PureBoot 29, if you haven’t already?

The fact that “Power Button Behavior: Nothing” doesn’t work is a known issue in Phosh. Although GNOME Settings displays the setting, Phosh doesn’t implement this one. Currently, Phosh always blanks the screen when the power button is pressed. (If automatic suspend is enabled, it’ll suspend when the idle time elapses.)

Disabling automatic suspend does work though, so this seems unrelated to suspend.

I don’t have an explanation yet of what’s happening exactly - in my tests it took >24 hours for this issue to appear, so progress has been slow. But I had suspend on, maybe disabling it will trigger the issue sooner or more reliably :crossed_fingers:

5 Likes

Thanks @jonathon.hall , good to know the issue is being addressed!

I just started flashing with battery fully charged but power cable disconnected, and decided it would perhaps be a good idea to connect it just in case. Now the flashing progress is stuck at 0%, although the line inside the square brackets is spinning fast:

Did connecting the power cable during the process crash it? What now, a brick? (15 minutes and still 0%, spinning) :face_with_open_eyes_and_hand_over_mouth:

1 Like

Your device is fine, unfortunately there is a long-standing bug in the progress bar implementation that occasionally causes it to get stuck. I’ve mitigated it a few times, but it needs a significant rework, probably including work on flashrom to have a better way to get the progress information.

The bug is just in the progress bar itself, flashing continues behind the scenes. You’ve already waited longer than 2 minutes, so you can shut the device off, boot again, and confirm that it’s on the new firmware in the system info.

4 Likes

Phew!
Installed v29 fine. Will now press the power button to turn the display off and see what happens tomorrow when I press it again. Cheers.

3 Likes

Nope, it’s the same. About 9 hours lasted since I pressed the power button. The device probably goes to sleep much earlier, I just haven’t tried to find the exact timeout.

By the way, the volume up/down buttons give sound feedback when pressed. This is something you would expect only from an awake device.

2 Likes

That’s a very interesting detail @Greendrake ! It’s possible that we’re just not turning the display back on. There is an interaction between the BIOS and EC to turn the display off/on, and it’s possible that’s not working correctly here.

I was just running some tests with suspend disabled, I kept the display on, and it was fine. I have the display shutting off again (and the sound turned up :wink: ) and hopefully I can confirm the same behavior to get it fixed.

Thank you for the testing and detailed feedback!

1 Like

I have now updated firmware to release 30, and the issue is still there.

Have you had any progress resolving it?

It is quite frustrating because I am not using L11 just because of this problem. After a whole day having the display turned on I want to just turn it off, and quickly turn it back on again the next morning. And the latter does not work — I have to press the power button for very long to restart the device.

2 Likes

Sorry for the delay @Greendrake, been rotating some other tasks and did not realize how much time had gone by on this issue.

I haven’t been able to reproduce this on my devices so far. It might be related to timing of the EC or something else that can vary a bit from device to device. We’ll need to run some diagnostic tests on your device, my thoughts are:

  • I can give you a build that doesn’t power off the display in suspend to confirm that it’s related to this (it’ll increase suspend power consumption but we’ll know we are looking at the right problem)
  • At one point I had a way to force the display back on with ectool, if you’re able to SSH into the device we can try that to see if the display comes back on, let me go back to find that in my notes and confirm it still works on current firmware

I’ll get back to you with that info for the next steps when I have it ready, thanks for helping us solve this.

1 Like

@Greendrake I have a couple of things for you to try.

  1. This ROM might fix the issue (this is a guess, worth trying but don’t get expectations too high): https://source.puri.sm/firmware/releases/-/blob/PureBoot-Release-30-librem_11_display_poweron_1/librem_11/pureboot-librem_11-Release-30-librem_11_display_poweron_1.zip?ref_type=heads
  2. If that doesn’t fix it, try this ROM to at least confirm it’s related to powering off the display: librem_11/pureboot-librem_11-Release-30-librem_11_display_nopoweroff_1.zip · PureBoot-Release-30-librem_11_display_nopoweroff_1 · firmware / releases · GitLab
    • This ROM will have higher power consumption in suspend, but if the issue goes away we will be sure that it has to do with powering off the display.

In both cases, just flash the ROM with PureBoot (retain settings).

I tested manually powering off/on the display with ectool today. Long story short, if the display comes on too late, the system won’t display anything until the display is blanked and unblanked again. I moved the display power on around a little in the first ROM as a bit of a guess.

It is possible to manually power on/off the display with ectool, but that basically tells us the same thing as never powering off the display, so let’s test that first.

Let me know what you find out!

1 Like

Thanks for the suggested options. I will try the ROMs in the next few days, but in the meantime can you please let me know how to use ectool to turn display on/off? My L11 is in the subject state right now but I can ssh to it, so would like to see what can be done there first.

1 Like

Yes here’s how to do it:

Build ectool:

  1. Install deps: sudo apt install build-essential git
  2. Clone coreboot: git clone https://source.puri.sm/firmware/coreboot.git -b 24.02.01-Purism-1
  3. cd coreboot/util/ectool
  4. make

Then to power on the display: sudo ./ectool -w 0xa3 -z 0. Then you’ll probably need to press the power button to blank the display, wait a few seconds, then press it again to try to unblank again.

Hope that helps, let me know if it works!

1 Like

I am trying the 2nd ROM now (display_nopoweroff), will report in 24 hours.

Didn’t notice any changes with the 1st one (display_poweron).

By the way, when flashing, do I retain or overwrite settings? Or does it not matter?

The ectool said Writing ec a3 = 00 but otherwise didn’t do anything, nor pressing the power button afterwards did anything. Same when running it just shortly after turning the display off i.e. when I still can turn it back on.

By the way, you say you can’t reproduce the issue, but how long do you leave the device undisturbed after turning the display off? Every time you press the power button before the issue kicks in, you will be resetting the time counter to wait for it to occur. I don’t know how soon it kicks in, but leaving the device undisturbed for 12 hours consistently reproduces the issue for me.

1 Like

Nah, the 2nd ROM makes no discernible difference. All the same: the power button doesn’t do anything, volume buttons audibly react, ectool says “Writing…” but nothing happens.

I’ve commanded sudo poweroff until I hear new ideas :neutral_face:.

2 Likes

not a new idea, but for me the problem went away switching from PUREOS/Phosh to Debian/Gnome

3 Likes

That is a new idea! So far it seemed the problem is below the OS level. Will try!

1 Like