[SOLVED] Broadcom wl driver not available upon resume on Linux 6.6.26

litelinux · 04-13-2024, 02:44 AM

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

jloco · 04-13-2024, 03:16 AM

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.

H1p8r10n · 04-13-2024, 04:47 AM

Bug confirmed

From Zenwalk tweaks , this hook fixes the problem :

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

Code:

case $1/$2 in
	pre/*)
		for i in $( bluetoothctl devices | cut -f2 -d " " ); do 
			bluetoothctl info "$i" | grep -q "Connected: yes" && bluetoothctl disconnect "$i" && echo "$i" > /tmp/.last-bt-device	
		done
		;;
	post/*)
		if [ -e /tmp/.last-bt-device ]; then
			bluetoothctl connect "$(cat /tmp/.last-bt-device)"
			rm -f /tmp/.last-bt-device
		fi
		/etc/rc.d/rc.networkmanager restart
		;;
esac

All the best

kgha · 04-13-2024, 05:55 AM

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...)

H1p8r10n · 04-13-2024, 07:04 AM

Quote:

Originally Posted by kgha

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

kgha · 04-13-2024, 07:52 AM

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.

z80 · 04-13-2024, 08:11 AM

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

kgha · 04-13-2024, 08:32 AM

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.

z80 · 04-13-2024, 08:58 AM

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

kgha · 04-13-2024, 09:34 AM

Quote:

Originally Posted by z80

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...

kgha · 04-13-2024, 12:14 PM

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.

kgha · 04-13-2024, 12:58 PM

OK, tried rebuilding NetworkManager with a change in the buildscript, line 136, from

Code:

  --with-suspend-resume=elogind \

to

Code:

  --with-suspend-resume=upower \

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.

litelinux · 04-13-2024, 06:40 PM

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

-- ltlnx

af7567 · 04-14-2024, 10:52 AM

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:

Code:

NetworkManager[1217]: <info>  [1713109578.3148] device (eth0): carrier: link connected

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

H1p8r10n · 04-14-2024, 11:34 AM

Quote:

Originally Posted by af7567

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