You are not logged in.
I have problems with this adapter in my old Samsung laptop, sometimes I don't even get so far as to log in before it freezes and blinks Caps lock to indicate kernel panic. Have tried to catch "dmesg -v > dmesgfile" but it does not manage to write anything.
If I manage to do "down" on the interface, everything works fine. It has worked for several years with the same Arch install but seems to be getting worse lately.
Took the module out and reinserted but that did not improve (did not clean the contacts though).
Do you think this is a flaky module or a kernel issue?
Offline
Hi man, i'm in trouble for 4 days, i thought was the only and, may be, had some hardware issue on my HP with the same adapter...
Now i know that is the adapter because i have the same blinks on caps lock and with cable nothing happens and can use normally the PC.
Same here, years of no problems with arch on this notebook. If you can find something, please, help me to resolve the issue, i'll do the same for you. Thanks
Offline
I blacklisted modules b43 and brcmsmac so now it will not be started atleast.
Offline
Ok, i have hardware button for disable wi-fi and have no issue with this turned off, but, how we can use our pc without wi-fi? Hope that someone can fix this problem in some way, the notebook, with old i7 and ssd, do a great job with arch and i don't want to change it!!!
Offline
I had the exact same problem about a week ago, with my laptop freezing and the caps-lock light blinking. After extensive tinkering and googling I found that this is a kernel panic (never had one before) and that the wifi seemed to be the cause. I have the same Broadcom wireless chipset (BCM4313) which always worked fine in Arch before, using the standard driver brcmsmac which comes with the kernel.
Since the laptop got unusable and I got frustrated searching for a solution, I decided to install Manjaro and see whether the same problem occurs. In fact I had no further kernel panic and was happy at first. Unfortunately the internet connection was unstable, with NetworkManager asking for a wifi password every 20 minutes or so, which was very annoying.
After some more tinkering I found that Manjaro by default used the broadcom-wl driver, which seemed to have a problem with my two wifi access points (router + range extender). So I removed broadcom-wl so that brcmsmac is used instead and voilà, my laptop froze again after some network use. Since it is easy to switch the kernel in Manjaro, I downgraded from linux 5.8.1 to linux 5.4.58 (LTS) and did not have any issues since then using the brcmsmac driver. Of course it would preferable, if brcmsmac also worked on the newest kernel again and I could switch back to Arch without much hassle.
Long story short:
- the brcmsmac driver seems to cause kernel panic with the BCM4313 network card on the recent linux kernel version 5.8.1
- the broadcom-wl driver does not cause kernel panic (on Manjaro at least), but I had an unstable connection with it (with my machine and setup at least). It might be a solution for others.
Note that to use broadcom-wl you apparently need to blacklist the other broadcom wifi modules (b43, brcmsmac, brcmfmac, maybe others), so that they are not used automatically instead.
Offline
Just a quick update: The kernel panic now also occured on the LTS kernel for me, so I am back to using the broadcom-wl driver. For anyone who, like me, is not that experienced with driver stuff: After installing broadcom-wl you can prevent the loading of the problematic driver brcmsmac, and other potentially conflicting drivers, by adding the following blacklist commands
blacklist b43
blacklist b43legacy
blacklist ssb
blacklist bcm43xx
blacklist brcm80211
blacklist brcmfmac
blacklist brcmsmac
blacklist bcmato a file with extension .conf in the folder /etc/modprobe.d/ (for example /etc/modprobe.d/broadcom-wl.conf).
Offline
Just a quick update: The kernel panic now also occured on the LTS kernel for me, so I am back to using the broadcom-wl driver. For anyone who, like me, is not that experienced with driver stuff: After installing broadcom-wl you can prevent the loading of the problematic driver brcmsmac, and other potentially conflicting drivers, by adding the following blacklist commands
blacklist b43 blacklist b43legacy blacklist ssb blacklist bcm43xx blacklist brcm80211 blacklist brcmfmac blacklist brcmsmac blacklist bcmato a file with extension .conf in the folder /etc/modprobe.d/ (for example /etc/modprobe.d/broadcom-wl.conf).
Thanks man, i'll try this for my notebook too. It's a shame, never had trouble with this card an hope that developers will fix it. but it's old and, may be, no one will be interested... will see!
Offline
I have a problem with a Dell Latitude E6410 with the same symptoms - complete freeze with the LEDs showing a 'system board error'. I plugged in an ethernet cable and I've run the laptop for an hour or so with no problem. As soon as I switched over to wireless the machine froze. It's dual boot laptop running W10 which runs OK using the wireless connection.
Please can we have a fix asap?
See:
Index
» Laptop Issues
» Dell Latitude e6410 freezes
Last edited by zdvdcprz (2020-09-03 16:14:40)
Offline
Please can we have a fix asap?
Offline
I have the same issue and reported[0] it at Linux wireless mailing list[1] the other day, but there's no response so far. While I have to wait for more a few days, I'm concerned the way I wrote the bug report and where I send the mail to are appropriate.
[0] https://lore.kernel.org/linux-wireless/ … nakao.com/
[1] https://wireless.wiki.kernel.org/en/dev … ilinglists
Offline
The broadcom-wl driver seems to work satisfactory for me.
Offline
I also have the same problem. Downgrading to kernel 5.7.12 fixes the problem for me. I additionally opened a kernel bug report (https://bugzilla.kernel.org/show_bug.cgi?id=209367) to hopefully increase the visibility of this problem...
Offline
Hi there.
I had the same issue with my old HP ProBook. Where I had to block at least b43 module in kernel config to get a working wifi. (I never installed broadcom-wl)
Now my Laptop is always freezing when trying pacman -Syu...
I got it working again by upgrading to the latest kernel (5.8.10-arch1-1) using LAN connection (pacman -S linux linux-headers) and after rebooting installing broadcom-wl (pacman -S broadcom-wl)
No blacklisting needed because an automatic blacklist *.conf is created in /usr/lib/modprobe.d/broadcom-wl.conf when installing latest broadcom-wl (see 'cat /usr/lib/modprobe.d/broadcom-wl.conf')
I could even remove my module_blacklist=b43 from kernel parameters finally.
[j4zz@darkstar ~]$ lspci -vnn -d 14e4:
03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01)
DeviceName: WLAN
Subsystem: Hewlett-Packard Company Device [103c:145c]
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at d5000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: wl
Kernel modules: bcma, wlNo problems since.
Last edited by J4ZZ (2020-09-24 23:12:55)
Offline
Sorry for the long delay in responding.
I tried JanErik's suggestion of installing the broadcom-wl driver and my wireless is working perfectly.
zdvdcprz wrote:Please can we have a fix asap?
Quite right Loqs. I was much too eager.... Apologies.
Offline
Well, broadcom-wl is clearly not a suitable permanent fix. Just a workaround.
I am willing to investigate further and make sure upstream kernel developers fix this issue once and for all.
At least, please, help me find out, how to reliably trigger the kernel panic. Last time I used 5.8.x (and I occasionally do try another minor 5.8.x kernel) I had no issues and problems until 2 or 3 hours of wlan usage. That makes it almost impossible to investigate and know if there is still a kernel panic occurring.
Somehow, old hardware sometimes suffers from absent upstream kernel hacker usage, especially when they have to dust off their 'old equipment'.
I really wonder, why no upstream response has happened so far.
Last edited by NiceGuy (2020-10-01 02:40:30)
Offline
Well, broadcom-wl is clearly not a suitable permanent fix. Just a workaround.
I am willing to investigate further and make sure upstream kernel developers fix this issue once and for all.
At least, please, help me find out, how to reliably trigger the kernel panic. Last time I used 5.8.x (and I occasionally do try another minor 5.8.x kernel) I had no issues and problems until 2 or 3 hours of wlan usage. That makes it almost impossible to investigate and know if there is still a kernel panic occurring.
Somehow, old hardware sometimes suffers from absent upstream kernel hacker usage, especially when they have to dust off their 'old equipment'.
I really wonder, why no upstream response has happened so far.
Thanks for offering to investigate this further. I can't test it right now, but for me the kernel panic usually occurred within about 20 minutes when I tried doing a total system upgrade. I guess any heavy network usage would trigger it, so maybe you can try downloading the ubuntu iso or another large file to reproduce it. If this doesn't work, maybe the problem occurs quicker when downloading many smaller files in succession.
Offline
From the wiki:
There are two variants of the restrictively licensed driver:
the regular variant: broadcom-wl
the DKMS variant: broadcom-wl-dkms
The dkms variant is working for my bcm4313.
DELL Inspiron 14-3452, 32GB emmc, 4 GB RAM
Offline
I just tried with a Fedora 33 live USB which uses brcmsmac driver with b43 module and I tried downloading some big files and it doesn't panic so there's definitely something wrong with the ArchLinux kernel/configuration which is not in some other distributions which already have kernel 5.8.x.
[liveuser@localhost-live ~]$ lsmod | grep brc
brcmsmac 585728 0
brcmutil 16384 1 brcmsmac
cordic 16384 2 b43,brcmsmac
mac80211 1015808 2 b43,brcmsmac
cfg80211 876544 3 b43,mac80211,brcmsmac
bcma 69632 3 b43,brcmsmac
[liveuser@localhost-live ~]$ uname -r
5.8.15-301.fc33.x86_64Last edited by getaceres (2020-11-08 10:30:21)
Offline
My intel wifi card using iwlwifi started randomly dropping from the pci bus of my notebook and becoming unusable. It cannot be removed (no such device) and rescanning doesnt help either.
This started with some of the newer kernel updates a few weeks ago or so.
Offline
I just tried with a Fedora 33 live USB which uses brcmsmac driver with b43 module and I tried downloading some big files and it doesn't panic so there's definitely something wrong with the ArchLinux kernel/configuration which is not in some other distributions which already have kernel 5.8.x.
[liveuser@localhost-live ~]$ lsmod | grep brc brcmsmac 585728 0 brcmutil 16384 1 brcmsmac cordic 16384 2 b43,brcmsmac mac80211 1015808 2 b43,brcmsmac cfg80211 876544 3 b43,mac80211,brcmsmac bcma 69632 3 b43,brcmsmac [liveuser@localhost-live ~]$ uname -r 5.8.15-301.fc33.x86_64
I can confirm, that no kernal panic occurs on Fedora 33 using the default brcmsmac driver. What I do get though is the following message flooding journalctl every few seconds:
wpa_supplicant[847]: wlp2s0b1: CTRL-EVENT-BEACON-LOSSThis might somehow be related to the issue, but it does not seem to affect the wifi connection.
Maybe someone experienced can help by answering the following questions:
Do you know of any differences between the kernel versions used in Arch and Fedora (or other distributions)?
Are there additional patches applied, that might explain the kernel panic occuring on one but not the other?
Offline
Same here. Started few days before OP.
Network controller: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter (rev 01)
Switching to broadcom-wl-dkms worked for me.
Heavy network load seems to trigger the kernel panic.
Offline
Well, broadcom-wl is clearly not a suitable permanent fix. Just a workaround.
I am willing to investigate further and make sure upstream kernel developers fix this issue once and for all.
At least, please, help me find out, how to reliably trigger the kernel panic. Last time I used 5.8.x (and I occasionally do try another minor 5.8.x kernel) I had no issues and problems until 2 or 3 hours of wlan usage. That makes it almost impossible to investigate and know if there is still a kernel panic occurring.
Somehow, old hardware sometimes suffers from absent upstream kernel hacker usage, especially when they have to dust off their 'old equipment'.
I really wonder, why no upstream response has happened so far.
I use my old Notebook regularly and first encountered a kernel panic in mid June 2020.
As far, as i can tell, the kernel panic happens totally random, when downloading something. This includes watching videos on Youtube, loading games from Steam and even performing a system upgrade. I performed the latter in a tty, before using a graphical environment and i shot some (bad) photos of the error messages.
I also tried to forward the kernel panic messages into another tty, which worked, but the error message skips through too fast.
To answer your question: In my opinion, the crash most likely happens when i download something via the steam-client. It is at least still happening now (5.4.77-1-lts).
Thank you for talking to the upstream kernel developers. I do not have the time to do so or to use a kdump crashkernel to get the whole error message. If you find a use for my "screenshots" i can send them to you.
For now, i will try the mentioned workaround, too.
Edit: I just saw, that ynakao already posted a full error log to [0], so my photos are not needed.
Last edited by abranchiate (2020-11-15 14:04:03)
Offline
The patch [0] regarding with this issue was submitted and accepted now. I built the kernel with this patch and have been using it for about a week, no kernel panic happens so far even under heavy network load.
While I'm not familiar with Linux kernel release process, this issue will be resolved once the patch is merged into the mainline linux code base, I guess.
Or is it possible to backport the patch to the current Arch build at the packaging stage? Similar issues have been reported recently, especially at installation process [1], [2], [3].
[0] https://patchwork.kernel.org/project/li … rista.com/
[1] https://bbs.archlinux.org/viewtopic.php?id=260989
[2] https://bbs.archlinux.org/viewtopic.php?id=260237
[3] https://bbs.archlinux.org/viewtopic.php?id=261076
Offline
Not sure if it helps others, but just in case it might:
I placed the patch into arch-linux packages and built that.
Maybe this makes it easier for others to use:
https://github.com/Tomok/linux_kernel_w … /tree/main
However I am far from an expert in arch-linux packages... so I will gladly accept comments for improvements and/or pull requests on github.
Offline
Patch was proposed for 5.4.Y https://lore.kernel.org/stable/20201223 … ernel.org/ but not later branches and was not added to the queue for any stable branch.
It is Linus's tree for 5.11. You could open a bug report on the Arch bug tracker asking for the commit to be cherry-picked for the linux package.
Offline