Does suspend work for you?

Hardware Librem 5
21

The above is dmesg output and looks suspicious. Why the CPU freeze does not work?
Moreover

Why this failure? Could it be this? The kernel is 6.6.0-1-librem5
(uname -r)

1 Like
22

As suspend works here I was looking at any diff reported in dmesg.
Kernel is also (uname -r) 6.6.0-1-librem5
dmesg give the same from
[ 123.845270] PM: suspend entry (deep)
to
[ 123.892602] printk: Suspending console(s) (use no_console_suspend to debug)
then I have this line
[ 124.967094] brcmfmac_cyw: brcmf_cyw_detach: executing
and then

[  125.022982] Disabling non-boot CPUs ...
[  125.024847] psci: CPU1 killed (polled 0 ms)
[  125.027441] psci: CPU2 killed (polled 0 ms)
[  125.029958] psci: CPU3 killed (polled 0 ms)

brcmfmac is the Broadcom brcmfmac driver

Hope it could help…

1 Like
23

I found also this line in dmesg but suspend works here.

2 Likes
24

Thanks for checking your dmessages. Does anyone know what this, about brcmfmac, could mean ?

1 Like
25

It’s the WiFi card driver for the new SparkLAN WiFi card, as distinct from the old Redpine Systems card.

So which do you have?

If you have the Redpine Systems card then you won’t have messages from or about “brcmfmac”.

2 Likes
26

I have the sparklan card which I installed removing the Redpine which came as default. Could this be the issue?

But it was working a month ago.

1 Like
27

I also have SparkLAN card, which I swapped in instead of Redpine, and suspend is working for me.

2 Likes
28

I have two L5 devices, one with SparkLAN and the other with Redpine. In both suspend is working fine. With one observation and one exception.

Observation: When I wakeup the L5 from suspend with the power button, I can see if the L5 was really in suspend (and not only display off): For a second or so in the upper status bar there is an icon with the two arrows showing that no network is available. This goes away when WLAN or WWAN comes up. The icon looks like this: ⇆

Exception: When I do the wake up not with the power button, but plug-in the USB-C for power or for tethering with my laptops, the L5 sometimes, not always, freezes.

3 Likes
29

It was working for me too for a long period of time. I do not know what happened recently and does not work anymore.

1 Like
30

So currently we’re suspicious that brcmfmac module is the problem.

Try to turn off SparkLAN card with killswitch, and then execute this:

sudo rmmod brcmfmac_cyw
sudo rmmod brcmfmac

These commands will unload the module from kernel.
Try to suspend then, and see if it works.

1 Like
31

Both commands produce error as these modules are not loaded. And these modules do not exist in the phone as insmod also fails with “no such file or directory”.

1 Like
32

Could it be that some service blocks suspend? What is jitterentropy-rngd.service?

Also apt says that linux-image-6.2.0-1-librem5 and similarly 6.3.0 and 6.4.0 are no longer needed and must be removed with apt autoremove.

Is there anyway to boot with 6.4.0 instead of the current 6.6.0? If I do
sudo apt-get purge linux-image-6.6.0-1-librem5
will it get back to 6.4.0 or I will brick the phone?

1 Like
33

I tried :
lsmod | grep brcmfmac
brcmfmac_cyw 12288 0 brcmfmac 348160 1 brcmfmac_cyw cfg80211 1024000 1 brcmfmac brcmutil 28672 1 brcmfmac
then as you suggest:

sudo rmmod brcmfmac_cyw
sudo rmmod brcmfmac

and suspend is still working. So it seems brcmfmac modules loaded or not don’t inhibit suspend.

1 Like
34

Yeah, it was just a shot in the dark, as I can’t figure out from @antonis logs what’s wrong.

I’ve searched today for people having similar issues on different platforms, hoping to find something, but I found nothing useful. Either the problem went away with kernel upgrade, or they reinstalled the system.

1 Like
35

Since logs do not help, I would like to downgrade the kernel as it was working in the past. How do I do that?

If this does not solve the issue then I will try to ask at purism support. There must be an answer when and why the kernel can not kill the non bootable cpus. Maybe it is time to bug @guido.gunther if he knows something about this.

1 Like
36

Yes. You use the flash-kernel command. You can search the forum for various examples - although I don’t know that it’s exactly routine and recommended procedure.

As always when messing around with this stuff, you should have a working uuu setup on a host computer and know how to use it because you should either

  • use Jumpdrive to image the entire disk of the phone before starting to mess around, or
  • be prepared to reflash the phone if the result is bad

or both.

At this stage don’t use apt autoremove - I mean it’s good to use that command from time to time e.g. in order to avoid the /boot partition filling up but in this case, it would be a good idea to keep old kernels. Do however just take a peek at how full /boot is.

(This is probably more than you wanted to know but …)

I don’t actually know but I can take a guess. An *rngd service generally is a source of entropy for strong random number generation.

For example, on some of my computers I have external entropy hardware and the appropriate *rngd service periodically grabs entropy from the device and loads it into the kernel’s entropy pool.

On most (even vaguely recent) computers (definitely Intel, I think ARM too) the CPU can provide entropy. So there is a daemon for grabbing entropy from there instead. I think many experts believe that this may not be ideal because the source of entropy is opaque. You have no way of knowing how the entropy is being generated within the CPU and whether it is in fact backdoored and only looks random.

So if both of those options are ruled out (don’t have external hardware, don’t trust Intel), computers will use “jitter” to produce entropy. “jitter” means measuring “something” periodically and using the low order bits as a best effort at being “unpredictable”. In the good old days, the computer might have used magnetic disk access times. Nowadays, it might be other kinds of response times.

Because it is very hard to get entropy during the early boot, most computers will save the entropy pool at shutdown and restore it on boot. So it is only the first boot that might be troublesome.

Bottom line though … this service seems unlikely to block suspend.

1 Like
37

Since this may happen to everyone when swapping batteries, it turned out that something went wrong with the swap and suspend stopped working.

I removed the battery and held the power button for more than 18 sec pressed with no power connected (or battery). Release the power button, re-installed the battery, and suspend works as before.

Wrong alarm but I think it can happen to anyone. What could have gone wrong? I wonder…

5 Likes