Librem 14 - resume from hibernate, wifi does not come online (Solved)

Hardware
1

Hello everyone,

When resuming my Librem 14 from hibernate, WiFi never comes back online.
The driver seems somewhat to be stuck, using the HKS works around the issue.

I am running Debain Bullseye on this system.
Coreboot release is 4.14-Purism-1, Librem-EC is the stock version.

Some logs that seems to be relevant:

kernel: ath: phy3: Failed to wakeup in 500us
kernel: ath: phy3: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
kernel: ath: phy3: Chip reset failed
systemd[1]: Starting Load/Save RF Kill Switch Status...
systemd[1]: Started Load/Save RF Kill Switch Status.
kernel: ath: phy3: RX failed to go idle in 10 ms RXSM=0xffffffff
kernel: ath: phy3: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff

But also this log:

NetworkManager[752]: <warn>  [1629732367.4522] sup-iface[ac3ae7c7bfaf2d4d,4,wls6]: call-p2p-cancel: failed with P2P cancel failed
kernel: pcieport 0000:00:1c.0: pciehp: Slot(6): Link Down
kernel: pcieport 0000:00:1c.0: pciehp: Slot(6): Card not present
kernel: usb 1-3: USB disconnect, device number 3
kernel: ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
kernel: ath: phy1: Chip reset failed
kernel: ath: phy1: Unable to reset channel, reset status -22
kernel: ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
kernel: ath: phy1: Chip reset failed
NetworkManager[752]: <info>  [1629732368.4527] device (wls6): state change: disconnected -> unmanaged (reason 'removed', sys-iface-state: 'removed')

Would anyone know a cleaner fix than just using the HKS to force a reset of the wifi chip?

2

there’s a handful of power-related fixes in the latest version, so please update to that and LMK if the issue persists

3

That was fast - thanks for the advice, will do and report back here :slight_smile:

4

Reporting back on this issue: upgrading the Librem EC to version 2021-08-03, following https://puri.sm/projects/librem-ec/ fixed the issue I described.

For the reference, I was running an EC version from April prior to flashing.

Many thanks for the support/advises @MrChromebox but also for the continuous improvements on the devices firmwares: that is one of the aspect I enjoy with Librem devices, bugs exists (as with any product) but it is continuously improving :slight_smile:

1 Like
5

OMG how will I ever understand this machine, lol

6

Well, an average user would mostly just follow-up with the updates and such issues would go by themselves.

Beside OS updates, you would be looking into PureBoot or Coreboot updates from Purism (for a Librem 14, depending on what you bought), and Librem EC. Detailed instructions to be found on Purism website (they are easy to follow):

7

Aren’t core boot updates/automatic on the L14 software app just like OS updates?

8

AFAICT, they are not.
This is user initiated using instructions provided by Purism.
An evolution that would help make those updates automatic would be to leverage fwupd infrastructre / LVFS, see this thread: Submit firmware to "Linux Vendor Firmware Service" (LVFS) for easy updating

9

As far as I know, they have never been automatic. This is for the same reasons that your Windows PC doesn’t just automatically update its bios (excluding Microsoft products, which do).

In general, the rule of thumb is to not update your bios firmware unless there is a problem you are trying to correct. Hence making it something that auto updates is not advisable.

10

Gotcha, thanks, then I won’t worry about it currently.

11

From a functionnality perspective, this is correct - if you’r happy with it why change it?
From a security perspective, you will be missing CPU microcode updates that help address CPU vulnerabilities like the speculative ones (spectre, meltdown etc…), so from that perspective, applying the updates would be recomended.

I must say, wrt. my coreboot/pureboot update experience: I own several Purism devices, from several generations (server, mini, L13 and L14), using PureBoot (on the server) and coreboot everywhere else: all the updates always happened flawlessly, and I track almost every new releases.

12

I’m not sure but I think that may be “Windows only”. With Linux the CPU microcode updates are applied during the boot. Technically that means that your CPU is vulnerable for a period of time in the early boot but if a hacker can run code before that point in time then you may have bigger problems. :wink:

13

I had a look further and the intel-microcode package is released under the non-free section in Debian.
I would expect PureOS does not ship it at all, therefore having some up to dates microcode shipped with coreboot is better than nothing imho.

15

That “rule” is perfect security antipattern, and is being used by companies to reduce support load.
Problem with this approach is:

BIOS is no longer simple program. In UEFI context it’s standalone small quite capable (can even TCP/IP) OS that runs parallel to your operating system. google CVE UEFI to see how many critical bugs were found in software of many Vendors …

and this is only BIOS , there other firmware, that also can be vunreable in the system.
So NO! Not updating firmware is not a good idea, even “if you don’t have issues”…

@henry-nicolas
microcode is being part of bios package, and purism actually updates it every bios release.
see https://source.puri.sm/firmware/purism-blobs/-/blob/master/mainboard/purism/librem_cnl/cpu_microcode_blob.bin
for l14
however adding debian nonfree repo and set intel-microcode service is a good idea.

16

How ironic, EUFI was meant for security and now it turns out to be a vulnerability.

17

technically every single piece of software at some point will be marked asvulnerable.
it’s only code, written by human.
what is worse even hardware can be vulnerable too Spectre / Meltdown etc.

When vendors says something like: Do not upgrade BIOS/Furmware unless you are trying to fix Issue you are facing…
My answer is always: You will say same thing to Windows XP users? Some of them also not facing any issues… :wink:

No matter what type of initialisation Firmware you have, is it a BIOS , UEFI , EFI . that piece of software can be bugy, some of those bugs can be exploited some not. You will probably never know…

18

@MrChromebox is there an ETA for automation that is mentioned on the update page for the maual installation of EC firmware updates?

19

not at this time

20

Sometimes they are saying that because the update has only had very limited testing to fix one specific problem and may not work in all situations and may not work in all configurations and environments and with all hardware.

So what they are saying is that the risk v. reward trade-off is not good. If you aren’t experiencing that one specific problem (e.g. you don’t even use the functionality that is misbehaving) then the reward is zero, but, with the very limited testing, the risk is greater than zero.

I would be very hesitant to accept that line of thinking for a security problem however.

21

Hi. It looks like I’ve run into the original WiFi problem described in this thread. My Librem 14 freezes after ~5 min of work with the said messages in the dmesg, regardless of wether I boot from the Hard drive or from my bootable USB.
So, I’m thinking about how to upgrade the firmware in a hope that it will fix the issue. But how could I do that with such a short stable working time?

Update

I’ve upgraded the Librem EC and the Coreboot bootloader from the PureOS LiveUSB. Unfortunately, the problem seems to be NOT FIXED for me. To say more, after WiFi card starts to issue error messages (in my case I see these messages not after the system resume, but at random moments of time), EXT4 driver crashes and the system effectively freezes. I suspect that WiFi affects PCI bus somehow.