Getting broadcom wireless to load right consistently

rabarrett · 2021-08-29 17:05:53

For wireless, I use this package:
broadcom-wl-dkms

However, when I boot up, my wireless is working probably only about 25% of the time. The other 75% or so I can't get a ping out of my local network. If I reboot, it eventually boots properly and I have a connection. Instead of rebooting, I can usually solve the problem by reinstalling the broadcom package, which runs the hooks and (if done enough times) eventually establishes a connection. For example, a few minutes ago, I rebooted, pinging didn't work, so I reinstalled broadcom-wl-dkms over and over and on the fourth attempt, I could ping again.

I'm guessing that the modules aren't being loaded in the proper order. Could someone help me understand if that's the problem and how to fix it?

Are there any logs I should provide to help (e.g. journalctl with certain flags)?

Thank you,

Richard

rabarrett · 2021-09-04 16:30:58

No one else has run into this?

seth · 2021-09-04 18:59:50

People won't run into this because they avoid having broadcom chips

You might not be blacklisting brcm80211

Please post the output of "sudo journalctl -b" for a disfunctional boot (... "-b -1" will print the journal for the previous boot and you can increase that number to go back in time.

rabarrett · 2021-09-25 15:48:36

I was starting to think I would never get the info to post a response. Since I posted this near the beginning of Sept, it hadn't happened again until today.

Here's my journalctl -b output from just after the boot that didn't load wireless properly:
https://pastebin.com/XG3RcZvW

When I couldn't access wireless I reinstalled the broadcom-wl-dkms modules and after it ran the hooks, wireless started working again (without the need to reboot).

Thoughts on what to do? (This problem started last spring, probably in March or April, and it was a nearly weekly issue until the beginning of September. Now it seems to happen less frequently. I can't think of any reason that my modules blacklisted or not would have changed last spring.)

seth · 2021-09-25 16:07:55

Sep 25 10:33:53 arch-planet-earth kernel: wl 0000:02:00.0 wlp2s0: renamed from wlan0
Sep 25 10:33:53 arch-planet-earth systemd[1]: Starting Load/Save RF Kill Switch Status...
Sep 25 10:33:53 arch-planet-earth systemd[1]: Started Load/Save RF Kill Switch Status.
Sep 25 10:33:53 arch-planet-earth systemd-fsck[335]: hgst_drive: clean, 108249/61054976 files, 207658437/244190208 blocks
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0: ALC1150: SKU not ready 0x00000000
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC1150: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:    dig-out=0x1e/0x0
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:    inputs:
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:      Front Mic=0x19
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:      Rear Mic=0x18
Sep 25 10:33:53 arch-planet-earth kernel: snd_hda_codec_realtek hdaudioC1D0:      Line=0x1a
Sep 25 10:33:53 arch-planet-earth audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 25 10:33:53 arch-planet-earth avahi-daemon[337]: Found user 'avahi' (UID 84) and group 'avahi' (GID 84).
Sep 25 10:33:53 arch-planet-earth avahi-daemon[337]: Successfully dropped root privileges.
Sep 25 10:33:53 arch-planet-earth avahi-daemon[337]: avahi-daemon 0.8 starting up.
Sep 25 10:33:53 arch-planet-earth avahi-daemon[337]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Sep 25 10:33:53 arch-planet-earth kernel: checking generic (e0000000 8ca000) vs hw (f7800000 400000)
Sep 25 10:33:53 arch-planet-earth kernel: checking generic (e0000000 8ca000) vs hw (e0000000 10000000)
Sep 25 10:33:53 arch-planet-earth kernel: fb0: switching to inteldrmfb from EFI VGA
Sep 25 10:33:53 arch-planet-earth systemd-udevd[249]: wlan0: Process '/usr/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/wlp2s0 --prefix=/net/ipv4/neigh/wlp2s0 --prefix=/net/ipv6/conf/wlp2s0 --prefix=/net/ipv6/neigh/wlp2s0' failed with exit code 1.

Looks like a race condition (what fits the sporadic nature)
https://wiki.archlinux.org/title/Networ … face_names - it's a dumb "feature" anyway. See whether you can still reproduce it.
Also maybe go back in your journal - do other affected boots have the same pattern where "systemd-sysctl --prefix" fails?

rabarrett · 2021-10-02 17:01:12

Yes, I can now reproduce it easily. What I'm not sure of is why it wouldn't be an issue for 3 weeks and then suddenly I reboot 4-5 times and it happens each time (and can't even be fixed by reinstalling the broadcom-wl-dkms file). Today, I only eventually "fixed" it by running Network Manager and then it suddenly connected again.

First fail on Sept 26:
https://pastebin.com/xHzZKues

Second fail on Sept 26 (didn't work after reboot):
https://pastebin.com/QHJpn6fp

3rd Fail - Reinstalling broadcom-wl-dkms didn't work:
https://pastebin.com/55daDM9Y

4th Fail -- more broadcom reinstalls didn't work
https://pastebin.com/eSYrDbna

Sept 26 Success -- after several more broadcom reinstalls:
https://pastebin.com/65EBQey6

NEXT DAY:
Sept 27 Fail:
https://pastebin.com/DEfSDckw

Sept 27 Success -- after 5-6 broadcom reinstalls:
https://pastebin.com/6vhijsfi

How should I go about changing things so that I don't deal with the race condition failure?
Is there a place I edit a file to tell it which to run first OR do I change the renaming of wlan0 to wlp2s0?

Is there a surefire way to fix the connection quickly if I boot and it's not working?

seth · 2021-10-02 21:07:04

Every (failing) journal still has the inteface name change in place.
See the link I posted in #5 and deactivate the name changing rule - it's the most reliable way to prevent the race condition and w/ only two devices (wifi + ethernet) the rename can only ever make the interface names *less* predictable.

Here's the last instance where everyone agrees that's it's dumb default behavior: https://bbs.archlinux.org/viewtopic.php … 1#p1989071

rabarrett · 2021-10-08 01:13:14

I got the change to go into effect (wlp2s0 is not wlan0 all the time). But that didn't solve it. Still have intermittent connection problems, more often than not. Typically need 3-5 reboots to get it to work right. Must be something else.

seth · 2021-10-08 06:36:54

Updated journal (covering some intermittent connection problems)?

rabarrett · 2021-10-16 02:46:13

I thought the old ones were probably good, since this didn't solve the problem. But here are some more:

2021-10-14 jrnctl -b after boot without wireless working:
https://pastebin.com/rwBVHxZv

This time it worked after just one reinstall of broadcom-wl-dkms
(Sometimes I try that 5-6 times, it doesn't fix the wireless, then I start rebooting--and sometimes that takes 5+ times also.)

2021-10-14 jrnctl -b after 1 reinstall of broadcom and wireless is working again:
https://pastebin.com/aej61X0u

Any ideas? It still seems like it must be a race condition because it's intermittent, even what fixes it seems to vary a lot. But my wireless is always called wlan0 now, so that's not it.

seth · 2021-10-16 16:24:55

Because of the maaaaany scanning errors, try to disable https://wiki.archlinux.org/title/Networ … domization

Arch Linux

#1 2021-08-29 17:05:53

Getting broadcom wireless to load right consistently

#2 2021-09-04 16:30:58

Re: Getting broadcom wireless to load right consistently

#3 2021-09-04 18:59:50

Re: Getting broadcom wireless to load right consistently

#4 2021-09-25 15:48:36

Re: Getting broadcom wireless to load right consistently

#5 2021-09-25 16:07:55

Re: Getting broadcom wireless to load right consistently

#6 2021-10-02 17:01:12

Re: Getting broadcom wireless to load right consistently

#7 2021-10-02 21:07:04

Re: Getting broadcom wireless to load right consistently

#8 2021-10-08 01:13:14

Re: Getting broadcom wireless to load right consistently

#9 2021-10-08 06:36:54

Re: Getting broadcom wireless to load right consistently

#10 2021-10-16 02:46:13

Re: Getting broadcom wireless to load right consistently

#11 2021-10-16 16:24:55

Re: Getting broadcom wireless to load right consistently

Board footer