Broadcom wl driver not available upon resume on Linux 6.6.26
 

Hi,

A few days ago I upgraded from kernel 6.6.25 to 6.6.26, recompiled the broadcom-sta SlackBuild and installed it as usual, but unlike the previous build, Wi-Fi won't work after resuming from hibernation. modprobe -r wl then modprobe wl doesn't help.

Has anyone on -current also faced this issue? I've checked the Arch and Gentoo repos, and it seems like no patch is available yet.

-- ltlnx

I don’t generally hibernate my machine so I haven’t noticed anything nor have I seen any new patches. I’m away from my machine right now but I’ll do some tests when I’m around it to see how it behaves for me and report back.

Bug confirmed :)

From Zenwalk tweaks , this hook fixes the problem :

/lib64/elogind/system-sleep/hook.sh

All the best

I never hibernate but often suspend by simply closing the laptop lid. Noticed today that suspend/resume actions change - system no longer resumes after opening the lid, I have to hit the on/off button to resume. After resuming, no wifi connection and NetworkManager applet unresponsible.

Tried the suggested hook.sh file - put it in /lib64/elogind/system-sleep/ and made it executable. No change after rebooting.

Reverted to elogind-252.23-x86_64-2.txz and all is well (although now I get an issue with mate-power-manager, but not sure if that's really connected...)

No need to reboot : just go to sleep and at resume : networkmanager will be restarted by the hook.sh. It can't "not" work :)

It actually can "not" work, at least here...

Maybe this has something to do with the confusing terms sleep/standby/suspend? Or have I missed something or made some mistake?

I'm on a fully upgraded -current (multilib) and the mate desktop, but behaviour is the same in a xfce session.

After suspending (by closing the laptop lid or choosing "suspend" from the shutdown menu) and resuming, the network connection is broken and the networkmanager applet is unresponsive/greyed out. The hook.sh script, placed in /lib64/elogind/system-sleep/ and made executable (-rwxr-xr-x) makes no difference at all. If I run the script in a terminal after having resumed, nothing happens.

Reverting to previous elogind version gets me the expected behaviour but affects some functions in the mate desktop (e.g disappearance of the shutdown menu).

I can choose "blank screen" instead of "suspend" as desired action when closing the lid. Then the network connection is still active and everything works when I open the lid (no need for the hook.sh script). I'll choose this as a workaround for now and hope for some kind of fix in a future elogind upgrade.

Same issue here with Intel WiFi and KDE and I can confirm that the hook script does NOT work.


Edited to add: reverting to an older version of elogind solves the problem with the mentioned drawbacks

Just read this which seems to be relevant... https://github.com/elogind/elogind/r.../tag/v255.4-r1
Right now rebuilding elogind from this latest source file, will see what happens...

UPDATE: no difference, sadly.

If you revert polkit to polkit-123 shutdown / reboot / display brightness works as it should.

Yes, downgrading both polkit and elogind solves both the suspend/resume issue and the problems with shutdown, brightness, power manager.

Tried rebuilding polkit-124 after upgrading to latest elogind, but that didn't change anything. So there must be some other interference somewhere...

Could the upower upgrade be involved somehow? Found this mentioning:

"-Dsuspend_resume=upower: Use this switch if you have UPower-1.90.4 installed and want to use it (instead of elogind-252.23 ) for suspend and resume support."

at https://www.linuxfromscratch.org/blf...rkmanager.html

Haven't tried rebuilding NM with that switch, though.

OK, tried rebuilding NetworkManager with a change in the buildscript, line 136, from
to
Now network connection (and the NM applet) is active after suspend/resume. However, it seems as if connection stays on during suspend. Previously, connection has been down during suspend, reconnecting after a few seconds. So upower doesn't seem to do anything.

Thanks for all the replies/testing! Can confirm downgrading both elogind and polkit works.

-- ltlnx

Recompiling with --with-suspend-resume=upower fixes it for me. Like kgha says, it seems to do "nothing" as in NM doesn't know the system is going to sleep so it doesn't bring down the network first. But it does still notice when the ethernet link comes back up and networking continues to work normally. This is the only message I get from NM when sleeping using the upower method:
This is better for me than restarting networkmanager, because that breaks Firefox and thunderbird. If I restart NM then I also need to restart firefox and thunderbird otherwise they can't find the internet. So that kind of defeats the purpose of going to sleep in the first place a bit :)

Indeed :)

I'm experiencing this as well.

Rollback to elogind-252.23 and polkit-123 fixes most problems as far as I tested.

I spoke too soon. By using the upower workaround the internet still works fine, and firefox and thunderbird work initially after a resume. But after a few minutes they do go wrong and need restarting anyway. So it looks like NM aware apps are just going to go wrong whichever workaround is used, so downgrade is the only reliable fix at the moment.

I've raised the issue at github.com/elogind. Hopefully some explanation/help/solution will come out of it.

However, it seems as if Pat considers reverting to version 252.23, or maybe come down with an aternative solution: https://www.linuxquestions.org/quest...ml#post6495928

logind.conf is ignored by 255.4 at the moment (at least on Slackware), I opened an issue on github about that yesterday. So anything you tested changing in the logind.conf files won't have done anything.

edit: Oh sorry, I just saw you referenced my issue there so do know about the logind.conf thing :)

Yup. And as I wrote over there,I've tried recompiling elogind using the latest 255.4-r1 and your patch, but no difference.

LuckyCyborg has posted something regarding the elogind upgrade here: https://www.linuxquestions.org/quest...ml#post6496029
but I can't see how this relates to the network issue.

On my system resuming from s2idle results in my mouse not working for some reason, so it seems to break more devices than real sleep does. I have always had SuspendMode set to deep because of that, and s2idle also keeps the PC running so not really sleeping at all.

I have just seen that the elogind developer also mentions s2idle.
You can check what sleep method your system is using in /var/log/messages, and see if it is different when using 252 instead of 255
s2idle would explain why the LEDs stay on, but the network staying down problem happens whatever sleep mode is used.

Right now I'm provisionally running elogind-255.4 and polkit-124 with the following /etc/elogind/sleep.conf.d/10-elogind.conf:
(The last line is the important one, changed from default).

I also have the rebuilt NetworkManager, built with --with-suspend-resume=upower \ as mentioned in post #12 above.

Suspend/resume behaviour appears "normal" - the wifi LED goes off during suspend, wifi and bluetooth immediately active after resume. And suspend/resume by closing/opening laptop lid works. I have not encountered any problems with my browser (vivaldi) or mail client (thunderbird) that af7567 mentions in post #18

EDIT: Have to revoke the last lines - I do get issues with Thunderbird. So this is not a viable option. Sorry.

Just to know if is related: after rollbacking polkit and elogind, I'm experiencing the notify service of KDE failing and falling back to xfce4 one. Anyone else experience the same?

EDIT: tried upgrading to the current version of elogind and polkit with no result. I guess is not related. Rollbacked again and i'll open another thread about it

On a tangent kioslave5 is also crashing for me too, not sure if it's related (but it also started happening only after a recent upgrade)

-- ltlnx

Edit: on both fully upgraded and upgraded-then-downgraded -current

I just had a reboot after a couple of days and had the same thing happening.
I guess this is related, i'm investigating the changes:

yes is it. I solved it at https://www.linuxquestions.org/quest...le-4175736075/

The revert to elogind-252 did the trick. Marking this as solved. Thanks Pat and everyone involved!

-- ltlnx