Bug 1052060

Summary:	Broadcom WiFi device gives error when loading firmware about non-existing file while the file is present
Product:	[openSUSE] openSUSE Distribution	Reporter:	Freek de Kruijf <freek>
Component:	Upgrade Problems	Assignee:	Larry Finger <Larry.Finger>
Status:	RESOLVED DUPLICATE	QA Contact:	Jiri Srain <jsrain>
Severity:	Major
Priority:	P5 - None	CC:	bwiedemann, freek, mpluskal, vbotka
Version:	Leap 42.3
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Freek de Kruijf 2017-08-03 11:13:06 UTC

On a system with a WiFi interface BCM43227 after upgrading from Leap 42.2 to 42.3 I got the error message about not finding the firmware in file b43/nl16initvals30.fw
This file is present in /lib/firmware/b43/nl16initvals30.fw
Also b43/ucode30_mimo.fw can not be found. This file is however in /lib/firmware/b43/ucode30_mimo.fw . After that the file b43-open/ucode30_mimo.fw is not found, which is true because folder b43-open does not exist.
After some experimentation, I found that running the command without any network connection:
install_bcm43xx_firmware
apparently loads the firmware. So after that I have a WiFi connection.
I came to this command via the systemd service pullin-bcm43xx-firmware.service which runs after the network is started.
This one shot service test for existence of a certain firmware file and exits because it exists. If it does not exists it runs the above command, which, when the network is not up, shows a number of curl failures, and, at the end apparently loads the firmware in the WiFi device.
The only reason for not being able to load the firmware is that at the moment of loading the driver, which most likely tries to load the firmware, the file system is not ready.

Comment 1 Freek de Kruijf 2017-08-03 11:36:22 UTC

A workaround is to comment out the test for existence of the firmware file in the wrapper file.

Comment 2 Freek de Kruijf 2017-08-06 14:30:05 UTC

A better workaround is giving the commands:
modprobe -r wl
modprobe wl
when the test shows the file exists.

Comment 4 Larry Finger 2017-08-06 16:09:09 UTC

There is some misinformation in this bug report, but some mystery as well.

In comment 2, a workaround using module wl is mentioned. Of course, if wl is in play, then b43, ssb, and bcma MUST be blacklisted. As it appears that you intend to use b43, then I would not expect the proprietary wl to be installed.

From Comment 1, install_bcm43xx_firmware never loads any firmware. Running it without any network should generate the curl errors and essentially exit without doing anything.

To investigate the file system not ready, please disable your special service and reboot. Once the system is up without networking, please run the following:

sudo modprobe -rv b43
sudo modprobe -v b43

Is the firmware now loaded?

At one point, there was a problem with synchronous firmware loads. For that reason, the driver was changed to do asynchronous loading, thus it will wait until the file system is ready.

Do you have anything peculiar with your setup? Is /lib on a separate partition?

Comment 5 Larry Finger 2017-08-06 17:32:36 UTC

I just realized that the final step of the script install_bcm43xx_firmware is to unload and reload the driver. That is the step that makes the firmware get loaded. Changing your special service to do that action will cure the problem without the extra work of trying to download and extract the firmware.

I have no idea why Leap 42.3 fails on the initial attempt to load firmware. It is not a problem with b43, but somewhere in 42.3's user-space code. Unfortunately, this kind of problem will be difficult to debug as the only computer I have that can run b43 can run only 32-bit systems, thus it will be difficult for me to duplicate your problem.

Comment 6 Larry Finger 2017-08-06 19:30:46 UTC

I was able to set up a test configuration and verify the problem. Note that I used kernel 4.13-rx2 for both Leap 42.2 (which worked) and Leap 42.3 (which failed). As a result, we can rule out any kernel problem.

As seen in the article at https://lwn.net/Articles/518942/, udev is the likely source of the problem. When the situation described in the article arose, and the udev developers refused to fix it, the b43 driver was rewritten to do an asynchronous loading of the firmware so that booting would not be delayed by 30 seconds. When the user-space code finally determines whether the firmware is available or not, a callback routine is entered. A simple communication model is used so that the callback routine merely needs to save the address of the firmware object, and set a completion flag. While this is happening, the main routine waits for the completion flag.

As soon as I determine the correct reassignment of this bug to udev, I will do so. In the meantime, I am removing the NEEDINFO.

Comment 7 Larry Finger 2017-08-06 21:39:33 UTC

Additional input: The difference between 42.2 and 42.3 is that the initrd for Leap 42.3 contains b43.ko - 42.2 does not. As a result, b43 starts a lot earlier. With asynchronous firmware loading, that should not matter My guess is that there is another bug present as well.

The problem could be corrected by forcing the addition of the b43 firmware to initrd, but that would make initrd be even bigger with few people even needing the new material.

This bug is a duplicate of #1037344, but I do not have enough privilege to set that duplicate.

Comment 8 Larry Finger 2017-09-25 02:04:18 UTC

Duplicate of 1037344.

*** This bug has been marked as a duplicate of bug 1037344 ***