[opensuse-factory] WLAN-Firmware (Broadcom 43224 chipset) can't be loaded by Kernel
Hi all together, I'm new to this list. I joined to you because I want to give some feedback when problems appear. Now I've got some. When I installed Tumbleweed on a Dell Latitude 6510 a week ago two problems mainly arose: 1) A boot problem with GRUB2. 2) PCIe-WLAN-Card doesn't work. Due to more necessary investigations on the boot problem I will restrict my descriptions to No. 2. On the one hand, the kernel can't load the firmware that was installed subsequently by the systemd service pullin-bcm43xx-firmware.service (uses the b43-fwcutter to extract the *.fw files from FW-packages; call to be found in the script /usr/sbin/install_bcm43xx_firmware). It seems to be the wrong FW downloaded since the kernel longs for the files bcm/bcm43xx-0.fw and bcm/bcm43xx_hdr-0.fw to load. But there is no file of them in /lib/firmware/b43 and /lib/firmware/b43legacy either. Have a look at a short extract of the syslog that reports the situation after I have systemd service let subsequently fetch and install the FW: Oct 24 18:54:55 luna kernel: brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 Oct 24 18:54:55 luna kernel: ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw Oct 24 18:54:55 luna wickedd[24990]: [....] (I just use wicked for the moment as I assumed at first that NetworkManager causes the problem.) On the other hand, the kernel still reports a problem after manually fetching and installing the files the kernel longs for in the above log from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre.... The log currently looks this: Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_add_interface: dbus [...] Oct 24 18:58:05 luna kernel: ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_interface_bind(wlp2s0b [...] Oct 24 18:58:05 luna wickedd[24990]: wpa_supplicant doesn't know [...] Oct 24 18:58:05 luna wickedd-nanny[24991]: device wlp2s0b1: call [...] Although the FW-files now seem to have the right name there is still something going wrong. May I have the guess that the kernel version 4.2 is too new for any available FW? May be there isn't a bcm43xx-FW particularly for this kernel version yet? Whether my assumption is right or not I think it's a severe problem that has to be solved. To whom it may concern (the maintainer or how you call the role): Please feel free to ask me for any further information you need! Have a nice weekend! Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
25.10.2015 03:01, Thomas Michalka (MLs) пишет:
Hi all together,
I'm new to this list. I joined to you because I want to give some feedback when problems appear. Now I've got some. When I installed Tumbleweed on a Dell Latitude 6510 a week ago two problems mainly arose: 1) A boot problem with GRUB2. 2) PCIe-WLAN-Card doesn't work.
Due to more necessary investigations on the boot problem I will restrict my descriptions to No. 2.
On the one hand, the kernel can't load the firmware that was installed subsequently by the systemd service pullin-bcm43xx-firmware.service (uses the b43-fwcutter to extract the *.fw files from FW-packages; call to be found in the script /usr/sbin/install_bcm43xx_firmware). It seems to be the wrong FW downloaded since the kernel longs for the files bcm/bcm43xx-0.fw and bcm/bcm43xx_hdr-0.fw to load. But there is no file
Not "bcm/...". "brcm/...".
of them in /lib/firmware/b43 and /lib/firmware/b43legacy either.
They are in /lib/firmware/brcm (when installed), not in /lib/firmware/b43.
Have a look at a short extract of the syslog that reports the situation after I have systemd service let subsequently fetch and install the FW:
Oct 24 18:54:55 luna kernel: brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 Oct 24 18:54:55 luna kernel: ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw Oct 24 18:54:55 luna wickedd[24990]: [....]
Those files should be part of kernel-firmware package. Try to install it first.
(I just use wicked for the moment as I assumed at first that NetworkManager causes the problem.)
On the other hand, the kernel still reports a problem after manually fetching and installing the files the kernel longs for in the above log from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre.... The log currently looks this:
Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_add_interface: dbus [...] Oct 24 18:58:05 luna kernel: ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_interface_bind(wlp2s0b [...] Oct 24 18:58:05 luna wickedd[24990]: wpa_supplicant doesn't know [...] Oct 24 18:58:05 luna wickedd-nanny[24991]: device wlp2s0b1: call [...]
Are you sure you fetched them in binary mode?
Although the FW-files now seem to have the right name there is still something going wrong.
May I have the guess that the kernel version 4.2 is too new for any available FW? May be there isn't a bcm43xx-FW particularly for this kernel version yet?
Whether my assumption is right or not I think it's a severe problem that has to be solved. To whom it may concern (the maintainer or how you call the role): Please feel free to ask me for any further information you need!
Have a nice weekend!
Tom
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Andrei, Am 25.10.2015 um 06:16 schrieb Andrei Borzenkov:
25.10.2015 03:01, Thomas Michalka (MLs) пишет:
[...]
On the one hand, the kernel can't load the firmware that was installed subsequently by the systemd service pullin-bcm43xx-firmware.service (uses the b43-fwcutter to extract the *.fw files from FW-packages; call to be found in the script /usr/sbin/install_bcm43xx_firmware). It seems to be the wrong FW downloaded since the kernel longs for the files bcm/bcm43xx-0.fw and bcm/bcm43xx_hdr-0.fw to load. But there is no file
Not "bcm/...". "brcm/...".
Right, the directory in fact is brcm/ -- just 2 times the same typo here :-(
of them in /lib/firmware/b43 and /lib/firmware/b43legacy either.
They are in /lib/firmware/brcm (when installed), not in /lib/firmware/b43.
Have a look at a short extract of the syslog that reports the situation after I have systemd service let subsequently fetch and install the FW:
Oct 24 18:54:55 luna kernel: brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 Oct 24 18:54:55 luna kernel: ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw Oct 24 18:54:55 luna wickedd[24990]: [....]
Those files should be part of kernel-firmware package. Try to install it first.
Now installed. The b43-firmware is part of it. Unfortunately the log looks exactly the same as the last showed below here. Besides b43* I've got a bunch of FW that's probably unneeded. But ok, just about 100 MB. One further question is: Was the installer made so clever that it recognised that the kernel-firmware package isn't needed as there is a systemd service called pullin-bcm43xx-firmware.service which can download the only missing firmware? Or more general: Why did the Installer not install this firmware package?
On the other hand, the kernel still reports a problem after manually fetching and installing the files the kernel longs for in the above log from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre.... The log currently looks this:
Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_add_interface: dbus [...] Oct 24 18:58:05 luna kernel: ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_interface_bind(wlp2s0b [...] Oct 24 18:58:05 luna wickedd[24990]: wpa_supplicant doesn't know [...] Oct 24 18:58:05 luna wickedd-nanny[24991]: device wlp2s0b1: call [...]
Are you sure you fetched them in binary mode?
Yes. Now the manually fetched FW is overwritten by zypper, but, as said and after modprobing remove'n insert b43 and b43legacy, the problem is still remaining. Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/25/2015 05:03 AM, Thomas Michalka (MLs) wrote:
Hi Andrei,
Am 25.10.2015 um 06:16 schrieb Andrei Borzenkov:
25.10.2015 03:01, Thomas Michalka (MLs) пишет:
[...]
On the one hand, the kernel can't load the firmware that was installed subsequently by the systemd service pullin-bcm43xx-firmware.service (uses the b43-fwcutter to extract the *.fw files from FW-packages; call to be found in the script /usr/sbin/install_bcm43xx_firmware). It seems to be the wrong FW downloaded since the kernel longs for the files bcm/bcm43xx-0.fw and bcm/bcm43xx_hdr-0.fw to load. But there is no file
Not "bcm/...". "brcm/...".
Right, the directory in fact is brcm/ -- just 2 times the same typo here :-(
of them in /lib/firmware/b43 and /lib/firmware/b43legacy either.
They are in /lib/firmware/brcm (when installed), not in /lib/firmware/b43.
Have a look at a short extract of the syslog that reports the situation after I have systemd service let subsequently fetch and install the FW:
Oct 24 18:54:55 luna kernel: brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 Oct 24 18:54:55 luna kernel: ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw Oct 24 18:54:55 luna wickedd[24990]: [....]
Those files should be part of kernel-firmware package. Try to install it first.
Now installed. The b43-firmware is part of it. Unfortunately the log looks exactly the same as the last showed below here. Besides b43* I've got a bunch of FW that's probably unneeded. But ok, just about 100 MB.
One further question is: Was the installer made so clever that it recognised that the kernel-firmware package isn't needed as there is a systemd service called pullin-bcm43xx-firmware.service which can download the only missing firmware?
Or more general: Why did the Installer not install this firmware package?
On the other hand, the kernel still reports a problem after manually fetching and installing the files the kernel longs for in the above log from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre.... The log currently looks this:
Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_add_interface: dbus [...] Oct 24 18:58:05 luna kernel: ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 Oct 24 18:58:05 luna wickedd[24990]: ni_wpa_interface_bind(wlp2s0b [...] Oct 24 18:58:05 luna wickedd[24990]: wpa_supplicant doesn't know [...] Oct 24 18:58:05 luna wickedd-nanny[24991]: device wlp2s0b1: call [...]
Are you sure you fetched them in binary mode?
Yes. Now the manually fetched FW is overwritten by zypper, but, as said and after modprobing remove'n insert b43 and b43legacy, the problem is still remaining.
It is unfortunate that you have had all those typos. They make it difficult to know exactly what is happening. Loading firmware is a kernel/driver interaction. It must succeed before the system can create a network interface. As that interface is the only thing that all network control software uses, it cannot matter whether you are using wicked or NetworkManager. Your wicked logs are just a derivative result, and contribute no new information. Only the log output of dmesg or journalctl will show the actual error. Your device needs firmware from /lib/firmware/brcm/. That firmware is released by Broadcom and may be redistributed by openSUSE and other distros. Note that script /usr/sbin/install_bcm43xx_firmware is used for firmware for older devices, which Broadcom has refused to allow to be redistributed. The function of that script is to download a driver file with firmware embedded and use b43-fwcutter to extract that content. That firmware will never be used by your device. My suggestion is that you use YaST to replace the kernel-firmware package and reboot. That should clear up the missing firmware message. If not, please report back the message from the log and a long listing of /lib/firmware/brcm. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Larry, thanks for your answer. BTW: adressing to my personal address isn't necessary since I have been subscribing to the list :-) Am 25.10.2015 um 17:15 schrieb Larry Finger:
On 10/25/2015 05:03 AM, Thomas Michalka (MLs) wrote:
Hi Andrei,
Am 25.10.2015 um 06:16 schrieb Andrei Borzenkov:
25.10.2015 03:01, Thomas Michalka (MLs) пишет:
[...]
On the one hand, the kernel can't load the firmware that was installed subsequently by the systemd service pullin-bcm43xx-firmware.service (uses the b43-fwcutter to extract the *.fw files from FW-packages; call to be found in the script /usr/sbin/install_bcm43xx_firmware). It seems to be the wrong FW downloaded since the kernel longs for the files bcm/bcm43xx-0.fw and bcm/bcm43xx_hdr-0.fw to load. But there is no file
Not "bcm/...". "brcm/...".
Right, the directory in fact is brcm/ -- just 2 times the same typo here :-(
of them in /lib/firmware/b43 and /lib/firmware/b43legacy either.
They are in /lib/firmware/brcm (when installed), not in /lib/firmware/b43.
Have a look at a short extract of the syslog that reports the situation after I have systemd service let subsequently fetch and install the FW:
Oct 24 18:54:55 luna kernel: brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 Oct 24 18:54:55 luna kernel: ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw Oct 24 18:54:55 luna wickedd[24990]: [....]
Those files should be part of kernel-firmware package. Try to install it first.
Now installed. The b43-firmware is part of it. Unfortunately the log looks exactly the same as the last showed below here. Besides b43* I've got a bunch of FW that's probably unneeded. But ok, just about 100 MB.
One further question is: Was the installer made so clever that it recognised that the kernel-firmware package isn't needed as there is a systemd service called pullin-bcm43xx-firmware.service which can download the only missing firmware?
Or more general: Why did the Installer not install this firmware package?
[...]
Are you sure you fetched them in binary mode?
Yes. Now the manually fetched FW is overwritten by zypper, but, as said and after modprobing remove'n insert b43 and b43legacy, the problem is still remaining.
It is unfortunate that you have had all those typos. They make it difficult to know exactly what is happening.
I'm not quite sure whether I understand you clearly. I made exactly 2 typos: 2 times bcm/ instead of brcm/, just in my mails, but not on my filesystem.
Loading firmware is a kernel/driver interaction. It must succeed before the system can create a network interface. As that interface is the only thing that all network control software uses, it cannot matter whether you are using wicked or NetworkManager.
That's quite clear. It was just my first assumption a couple of days ago that NetworkManager caused the problem or plays a certain role in it. I recognised it very soon as a problem around the device firmware.
Your wicked logs are just a derivative result, and contribute no new information.
I posted them just to show an 'environment' of the kernel messages. Furthermore I can reproduce them only if type the command ifup wlp2s0b1.
Only the log output of dmesg or journalctl will show the actual error.
The log output came from journalctl and there's nothing more around it of essential interest. But dmesg might give us additional infos: luna:~ # dmesg | grep -C 5 brcm [82833.698696] brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 [82833.698704] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw [83645.205746] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [96233.286573] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [98124.774221] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [98634.310827] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [98649.005079] PM: Syncing filesystems ... done. -- [98657.879654] acpi PNP0501:00: Still not present [98659.185869] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx [99017.799315] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [115832.007038] Broadcom 43xx driver loaded [ Features: PMNLS ] [115851.225196] Broadcom 43xx-legacy driver loaded [ Features: PLID ] [124827.903046] brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 [124827.903055] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw [124906.050108] brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx_hdr-0.fw failed with error -2 [124906.050116] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx_hdr-0.fw [125017.557339] ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 [126600.795112] Broadcom 43xx driver loaded [ Features: PMNLS ] [126607.609767] Broadcom 43xx-legacy driver loaded [ Features: PLID ] [126655.731072] ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 [150906.829264] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [150913.254961] PM: Syncing filesystems ... done. [150913.292446] PM: Preparing system for sleep (mem) [150913.292755] Freezing user space processes ... (elapsed 0.001 seconds) done. [150913.294751] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. -- [150914.967016] acpi PNP0501:00: Still not present [150916.182851] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx [151274.879192] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [151764.379460] ISO 9660 Extensions: Microsoft Joliet Level 3 [151764.477008] ISO 9660 Extensions: RRIP_1991A [152113.452527] ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 [152393.740381] Broadcom 43xx driver loaded [ Features: PMNLS ] [152396.654661] Broadcom 43xx-legacy driver loaded [ Features: PLID ] [152433.328664] ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 [154132.614161] PM: Syncing filesystems ... done. [154132.652233] PM: Preparing system for sleep (mem) [154132.652511] Freezing user space processes ... (elapsed 0.002 seconds) done. [154132.654590] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [154132.655618] PM: Suspending system (mem) -- [156670.825619] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [157030.857571] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [164745.783949] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [165280.386126] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [169316.886288] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [169578.162647] ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 [170031.304630] dell_wmi: Unknown WMI event type 0x11: 0xffd0
Your device needs firmware from /lib/firmware/brcm/.
Quite clear meanwhile.
That firmware is released by Broadcom and may be redistributed by openSUSE and other distros. Note that script /usr/sbin/install_bcm43xx_firmware is used for firmware for older devices, which Broadcom has refused to allow to be redistributed.
That restriction of redistribution (but why allowed for openwrt.org and lwfinger.com?) is new to me but it was soon clear that the kernel wants to load firmware with other file names. Those weren't loaded into the directories /lib/firmware/b43 and /lib/firmware/b43legacy, but after installing the kernel-firmware package into /lib/firmware/brcm. But why then has the package pullin-bcm43xx-firmware been installed at all? Because my device is perhaps an older one? My notebook is about 4 years old -- a good device age in IT.
The function of that script is to download a driver file with firmware embedded and use b43-fwcutter to extract that content.
I've got it, meanwhile.
That firmware will never be used by your device.
Might this depend on the kernel version? My log clearly says that the kernel (4.2.1) wants to load brcm/bcm43xx-0.fw and brcm/bcm43xx_hdr-0.fw. But the question is: Why did the installer not install the package kernel-firmware then? And where (installer/config file or whatever?) the decision whether my wifi hardware belongs to an older or a newer generation is made and what is the right firmware to be installed thus?
My suggestion is that you use YaST to replace the kernel-firmware package
With modprobe -r br43 and modprobe -r br43legacy I wanted the kernel to also load the firmware from /lib/firmware/brcm because it explicitely says in the older log parts that "Direct firmware load for brcm/bcm43xx-0.fw failed with error -2".
and reboot.
May I draw the conclusion, because the kernel wants to _directly_ load the firmware, that it is in fact able to install the FW and make it working without a reboot? Sorry about all my questions, but I'm so curious and want to know as much as possible about how all this works.
That should clear up the missing firmware message.
Has been cleared up -- the firmware isn't missed any longer, but now there's another problem which appears to be logged and it looks this: Oct 24 18:58:05 luna kernel: ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 with version 20150907git-1.1. It seems to be something wrong with the file bcm43xx_hdr-0.fw, may be with the file size? Or may be the kernel version 4.2.1 is too new? Aah ... you wrote "replace" above. Got version 20150925git-1.1 now. The log now reads Oct 26 00:35:24 luna kernel: ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 Now it's the other firmware file that is likely out of bounds. Possibly just a reboot will actually get the situation under control ...
If not, please reportback the message from the log and a long listing of /lib/firmware/brcm.
For another reason I have to leave the system running for a few hours yet. A complete listing of the firmware directory: luna:~ # l /lib/firmware/brcm/ total 9644 drwxr-xr-x 2 root root 4096 Oct 26 00:34 ./ drwxr-xr-x 74 root root 12288 Oct 26 00:34 ../ -rw-r--r-- 1 root root 269595 Sep 24 16:07 bcm4329-fullmac-4.bin -rw-r--r-- 1 root root 96224 Sep 24 16:07 bcm43xx-0.fw -rw-r--r-- 1 root root 180 Sep 24 16:07 bcm43xx_hdr-0.fw -rw-r--r-- 1 root root 385067 Sep 24 16:07 brcmfmac43143-sdio.bin -rw-r--r-- 1 root root 397312 Sep 24 16:07 brcmfmac43143.bin -rw-r--r-- 1 root root 348160 Sep 24 16:07 brcmfmac43236b.bin -rw-r--r-- 1 root root 455745 Sep 24 16:07 brcmfmac43241b0-sdio.bin -rw-r--r-- 1 root root 403855 Sep 24 16:07 brcmfmac43241b4-sdio.bin -rw-r--r-- 1 root root 408682 Sep 24 16:07 brcmfmac43241b5-sdio.bin -rw-r--r-- 1 root root 479232 Sep 24 16:07 brcmfmac43242a.bin -rw-r--r-- 1 root root 253748 Sep 24 16:07 brcmfmac4329-sdio.bin -rw-r--r-- 1 root root 222126 Sep 24 16:07 brcmfmac4330-sdio.bin -rw-r--r-- 1 root root 451566 Sep 24 16:07 brcmfmac4334-sdio.bin -rw-r--r-- 1 root root 397378 Sep 24 16:07 brcmfmac43340-sdio.bin -rw-r--r-- 1 root root 569291 Sep 24 16:07 brcmfmac4335-sdio.bin -rw-r--r-- 1 root root 219557 Sep 24 16:07 brcmfmac43362-sdio.bin -rw-r--r-- 1 root root 493599 Sep 24 16:07 brcmfmac4339-sdio.bin -rw-r--r-- 1 root root 488193 Sep 24 16:07 brcmfmac43455-sdio.bin -rw-r--r-- 1 root root 591837 Sep 24 16:07 brcmfmac4354-sdio.bin -rw-r--r-- 1 root root 593956 Sep 24 16:07 brcmfmac4356-pcie.bin -rw-r--r-- 1 root root 557056 Sep 24 16:07 brcmfmac43569.bin -rw-r--r-- 1 root root 550333 Sep 24 16:07 brcmfmac43570-pcie.bin -rw-r--r-- 1 root root 588940 Sep 24 16:07 brcmfmac43602-pcie.ap.bin -rw-r--r-- 1 root root 590544 Sep 24 16:07 brcmfmac43602-pcie.bin After reboot you'll get my journalctl log as well as a new dmesg report and, of course, if the problem is still remaining or not. Thanks a lot for providing advice! Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, October 26, 2015 01:34:49 AM Thomas Michalka wrote:
Hi Larry,
thanks for your answer. BTW: adressing to my personal address isn't necessary since I have been subscribing to the list :-)
Just to note that the mailing list netiquette is to reply to both the list and the user. Set the Reply to field in your email software to the list if you do not wish to receive a personal copy. https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail_l...
* Chan Ju Ping
On Monday, October 26, 2015 01:34:49 AM Thomas Michalka wrote:
Hi Larry,
thanks for your answer. BTW: adressing to my personal address isn't necessary since I have been subscribing to the list :-)
Just to note that the mailing list netiquette is to reply to both the list and the user. Set the Reply to field in your email software to the list if you do not wish to receive a personal copy.
https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail_l...
The "netiquette" has been changed sometime recently and is grossly incorrect. Anyone wishing direct mail answer should state such within their post or set their own reply to address. The default action *should* be list only mail. Someone has taken great pains to alter the previous stated actiion and it should be changed back. Only people who do not read the list *should* need direct replies as they are not really interested in the list, but that action should not be forced upon list-readers. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/25/2015 09:20 PM, Chan Ju Ping wrote:
On Monday, October 26, 2015 01:34:49 AM Thomas Michalka wrote:
Hi Larry,
thanks for your answer. BTW: adressing to my personal address isn't necessary since I have been subscribing to the list :-)
Just to note that the mailing list netiquette is to reply to both the list and the user. Set the Reply to field in your email software to the list if you do not wish to receive a personal copy.
https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail_l...
Quite the opposite, please re-read the link you provided. -- Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, October 26, 2015 09:32:34 AM Ken Schneider - Factory wrote:
On 10/25/2015 09:20 PM, Chan Ju Ping wrote:
On Monday, October 26, 2015 01:34:49 AM Thomas Michalka wrote:
Hi Larry,
thanks for your answer. BTW: adressing to my personal address isn't necessary since I have been subscribing to the list :-)
Just to note that the mailing list netiquette is to reply to both the list and the user. Set the Reply to field in your email software to the list if you do not wish to receive a personal copy.
https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail _list_answers Quite the opposite, please re-read the link you provided.
It states the new policy now because Patrick Shanahan has updated the Wiki on the 26th of October. I only quoted it because I was given the document to read during my first few non-netiquette compatible postings.
* Chan Ju Ping
On Monday, October 26, 2015 09:32:34 AM Ken Schneider - Factory wrote:
On 10/25/2015 09:20 PM, Chan Ju Ping wrote:
On Monday, October 26, 2015 01:34:49 AM Thomas Michalka wrote:
Hi Larry,
thanks for your answer. BTW: adressing to my personal address isn't necessary since I have been subscribing to the list :-)
Just to note that the mailing list netiquette is to reply to both the list and the user. Set the Reply to field in your email software to the list if you do not wish to receive a personal copy.
https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail _list_answers Quite the opposite, please re-read the link you provided.
It states the new policy now because Patrick Shanahan has updated the Wiki on the 26th of October. I only quoted it because I was given the document to read during my first few non-netiquette compatible postings.
A somewhat clumsy attempt that undoubtedly needs further editing. Perhaps a history is available somewhere that can replace the current page. Someone has taken quite good efforts to prettify the page and done a spanking good job except for incorrect content. We are not m$ and do not subscribe to their very poor efforts to change the email world to *only* their liking. m$ and aol have certainly done a job on nearly making email useless. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/25/2015 07:34 PM, Thomas Michalka (MLs) wrote:
luna:~ # dmesg | grep -C 5 brcm [82833.698696] brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 [82833.698704] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw
The firmware failed to load. If the firmware is actually available, this kind of failure might occur if the wireless driver is built in. That could only happen if this is a kernel that you generated.
[83645.205746] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [96233.286573] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [98124.774221] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [98634.310827] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [98649.005079] PM: Syncing filesystems ... done. -- [98657.879654] acpi PNP0501:00: Still not present [98659.185869] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx [99017.799315] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [115832.007038] Broadcom 43xx driver loaded [ Features: PMNLS ] [115851.225196] Broadcom 43xx-legacy driver loaded [ Features: PLID ] [124827.903046] brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx-0.fw failed with error -2 [124827.903055] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx-0.fw [124906.050108] brcmsmac bcma0:1: Direct firmware load for brcm/bcm43xx_hdr-0.fw failed with error -2 [124906.050116] ieee80211 phy0: brcmsmac: fail to load firmware brcm/bcm43xx_hdr-0.fw [125017.557339] ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 [126600.795112] Broadcom 43xx driver loaded [ Features: PMNLS ] [126607.609767] Broadcom 43xx-legacy driver loaded [ Features: PLID ] [126655.731072] ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12 [150906.829264] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [150913.254961] PM: Syncing filesystems ... done. [150913.292446] PM: Preparing system for sleep (mem) [150913.292755] Freezing user space processes ... (elapsed 0.001 seconds) done. [150913.294751] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. -- [150914.967016] acpi PNP0501:00: Still not present [150916.182851] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx [151274.879192] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [151764.379460] ISO 9660 Extensions: Microsoft Joliet Level 3 [151764.477008] ISO 9660 Extensions: RRIP_1991A [152113.452527] ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 [152393.740381] Broadcom 43xx driver loaded [ Features: PMNLS ] [152396.654661] Broadcom 43xx-legacy driver loaded [ Features: PLID ] [152433.328664] ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 [154132.614161] PM: Syncing filesystems ... done. [154132.652233] PM: Preparing system for sleep (mem) [154132.652511] Freezing user space processes ... (elapsed 0.002 seconds) done. [154132.654590] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [154132.655618] PM: Suspending system (mem) -- [156670.825619] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [157030.857571] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [164745.783949] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [165280.386126] dell_wmi: Unknown WMI event type 0x11: 0xffd0 [169316.886288] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [169578.162647] ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352 [170031.304630] dell_wmi: Unknown WMI event type 0x11: 0xffd0
Your device needs firmware from /lib/firmware/brcm/.
Quite clear meanwhile.
That firmware is released by Broadcom and may be redistributed by openSUSE and other distros. Note that script /usr/sbin/install_bcm43xx_firmware is used for firmware for older devices, which Broadcom has refused to allow to be redistributed.
That restriction of redistribution (but why allowed for openwrt.org and lwfinger.com?) is new to me but it was soon clear that the kernel wants to load firmware with other file names. Those weren't loaded into the directories /lib/firmware/b43 and /lib/firmware/b43legacy, but after installing the kernel-firmware package into /lib/firmware/brcm.
The sites you refer to are distributing drivers that have the firmware built in. Yes, it is a legal distinction, but a very impportant one. Those drivers are used by other operating systems than Linux. We extract the firmware from those drivers as a means of getting around the Broadcom restrictions, but they distribute these files with no restrictions.
But why then has the package pullin-bcm43xx-firmware been installed at all? Because my device is perhaps an older one? My notebook is about 4 years old -- a good device age in IT.
It is a small package that is not a hardship to install.
The function of that script is to download a driver file with firmware embedded and use b43-fwcutter to extract that content.
I've got it, meanwhile.
That firmware will never be used by your device.
Might this depend on the kernel version? My log clearly says that the kernel (4.2.1) wants to load brcm/bcm43xx-0.fw and brcm/bcm43xx_hdr-0.fw. But the question is: Why did the installer not install the package kernel-firmware then? And where (installer/config file or whatever?) the decision whether my wifi hardware belongs to an older or a newer generation is made and what is the right firmware to be installed thus?
The firmware files needed depend on hardware type, not on kernel version. The PCI ID determines the driver, and it determines the firmware.
My suggestion is that you use YaST to replace the kernel-firmware package
With modprobe -r br43 and modprobe -r br43legacy I wanted the kernel to also load the firmware from /lib/firmware/brcm because it explicitely says in the older log parts that "Direct firmware load for brcm/bcm43xx-0.fw failed with error -2".
and reboot.
May I draw the conclusion, because the kernel wants to _directly_ load the firmware, that it is in fact able to install the FW and make it working without a reboot?
You at least need to unload and reload the driver if the firmware was made available after the system was started. I usually recommend a reboot.
Sorry about all my questions, but I'm so curious and want to know as much as possible about how all this works.
That should clear up the missing firmware message.
Has been cleared up -- the firmware isn't missed any longer, but now there's another problem which appears to be logged and it looks this:
Oct 24 18:58:05 luna kernel: ieee80211 phy0: brcms_check_firmwares: non integral fw hdr file size 5062/12
with version 20150907git-1.1.
It seems to be something wrong with the file bcm43xx_hdr-0.fw, may be with the file size? Or may be the kernel version 4.2.1 is too new?
Aah ... you wrote "replace" above. Got version 20150925git-1.1 now. The log now reads
Oct 26 00:35:24 luna kernel: ieee80211 phy0: brcms_check_firmwares: out of bounds fw file size 640352
Now it's the other firmware file that is likely out of bounds. Possibly just a reboot will actually get the situation under control ...
If not, please reportback the message from the log and a long listing of /lib/firmware/brcm.
For another reason I have to leave the system running for a few hours yet.
A complete listing of the firmware directory:
luna:~ # l /lib/firmware/brcm/ total 9644 drwxr-xr-x 2 root root 4096 Oct 26 00:34 ./ drwxr-xr-x 74 root root 12288 Oct 26 00:34 ../ -rw-r--r-- 1 root root 269595 Sep 24 16:07 bcm4329-fullmac-4.bin -rw-r--r-- 1 root root 96224 Sep 24 16:07 bcm43xx-0.fw -rw-r--r-- 1 root root 180 Sep 24 16:07 bcm43xx_hdr-0.fw -rw-r--r-- 1 root root 385067 Sep 24 16:07 brcmfmac43143-sdio.bin -rw-r--r-- 1 root root 397312 Sep 24 16:07 brcmfmac43143.bin -rw-r--r-- 1 root root 348160 Sep 24 16:07 brcmfmac43236b.bin -rw-r--r-- 1 root root 455745 Sep 24 16:07 brcmfmac43241b0-sdio.bin -rw-r--r-- 1 root root 403855 Sep 24 16:07 brcmfmac43241b4-sdio.bin -rw-r--r-- 1 root root 408682 Sep 24 16:07 brcmfmac43241b5-sdio.bin -rw-r--r-- 1 root root 479232 Sep 24 16:07 brcmfmac43242a.bin -rw-r--r-- 1 root root 253748 Sep 24 16:07 brcmfmac4329-sdio.bin -rw-r--r-- 1 root root 222126 Sep 24 16:07 brcmfmac4330-sdio.bin -rw-r--r-- 1 root root 451566 Sep 24 16:07 brcmfmac4334-sdio.bin -rw-r--r-- 1 root root 397378 Sep 24 16:07 brcmfmac43340-sdio.bin -rw-r--r-- 1 root root 569291 Sep 24 16:07 brcmfmac4335-sdio.bin -rw-r--r-- 1 root root 219557 Sep 24 16:07 brcmfmac43362-sdio.bin -rw-r--r-- 1 root root 493599 Sep 24 16:07 brcmfmac4339-sdio.bin -rw-r--r-- 1 root root 488193 Sep 24 16:07 brcmfmac43455-sdio.bin -rw-r--r-- 1 root root 591837 Sep 24 16:07 brcmfmac4354-sdio.bin -rw-r--r-- 1 root root 593956 Sep 24 16:07 brcmfmac4356-pcie.bin -rw-r--r-- 1 root root 557056 Sep 24 16:07 brcmfmac43569.bin -rw-r--r-- 1 root root 550333 Sep 24 16:07 brcmfmac43570-pcie.bin -rw-r--r-- 1 root root 588940 Sep 24 16:07 brcmfmac43602-pcie.ap.bin -rw-r--r-- 1 root root 590544 Sep 24 16:07 brcmfmac43602-pcie.bin
After reboot you'll get my journalctl log as well as a new dmesg report and, of course, if the problem is still remaining or not.
My listing of that directory is -rw-r--r-- 1 root root 269595 Oct 9 2014 bcm4329-fullmac-4.bin -rw-r--r-- 1 root root 96224 Oct 9 2014 bcm43xx-0.fw -rw-r--r-- 1 root root 180 Oct 9 2014 bcm43xx_hdr-0.fw -rw-r--r-- 1 root root 397312 Oct 9 2014 brcmfmac43143.bin -rw-r--r-- 1 root root 385067 Oct 9 2014 brcmfmac43143-sdio.bin -rw-r--r-- 1 root root 348160 Oct 9 2014 brcmfmac43236b.bin -rw-r--r-- 1 root root 455745 Oct 9 2014 brcmfmac43241b0-sdio.bin -rw-r--r-- 1 root root 403855 Oct 9 2014 brcmfmac43241b4-sdio.bin -rw-r--r-- 1 root root 253748 Oct 9 2014 brcmfmac4329-sdio.bin -rw-r--r-- 1 root root 222126 Oct 9 2014 brcmfmac4330-sdio.bin -rw-r--r-- 1 root root 451566 Oct 9 2014 brcmfmac4334-sdio.bin -rw-r--r-- 1 root root 569291 Oct 9 2014 brcmfmac4335-sdio.bin -rw-r--r-- 1 root root 219557 Oct 9 2014 brcmfmac43362-sdio.bin -rw-r--r-- 1 root root 507752 Oct 9 2014 brcmfmac4354-sdio.bin The files in question seem to be the same size. To check content, md5sum /lib/firmware/brcm/* c53608f5818b702c46a012c57b4196ee /lib/firmware/brcm/bcm4329-fullmac-4.bin b0736e3590b05d27284fbb8a3efd50e1 /lib/firmware/brcm/bcm43xx-0.fw 5e51778ee011badcb42f1e2cb4ab3956 /lib/firmware/brcm/bcm43xx_hdr-0.fw 2be9d4da43aba729bfa3417829e011df /lib/firmware/brcm/brcmfmac43143.bin dc78f76883f5a0df9f13fad30d78442b /lib/firmware/brcm/brcmfmac43143-sdio.bin f579673b5dc45640c814a9c68abcaf55 /lib/firmware/brcm/brcmfmac43236b.bin 3575f0473cd9082d5b03f0e2549a998f /lib/firmware/brcm/brcmfmac43241b0-sdio.bin 62dffd52291975a60b2c079f2b671c06 /lib/firmware/brcm/brcmfmac43241b4-sdio.bin ff610cee869375a2d0c0be6b97b107fb /lib/firmware/brcm/brcmfmac4329-sdio.bin 4ec6341cbe351f13d787aaea99141bea /lib/firmware/brcm/brcmfmac4330-sdio.bin 0e5d2b9bfaaf3b6c43077405cfe92632 /lib/firmware/brcm/brcmfmac4334-sdio.bin 678ed027a1bac420318cd54daa1e1579 /lib/firmware/brcm/brcmfmac4335-sdio.bin ce95e81aa95f9dc1a32fb8acf691dbd8 /lib/firmware/brcm/brcmfmac43362-sdio.bin a3a73454d750f6b01170c7cbaa02c952 /lib/firmware/brcm/brcmfmac4354-sdio.bin Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Andrei Borzenkov -
Chan Ju Ping -
Ken Schneider - Factory -
Larry Finger -
Patrick Shanahan -
Thomas Michalka (MLs)