Bug 183273
Summary: | bcm43xx firmware should be easy to install, or else the hardware should be ignored | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stuart Jansen <bugzilla+redhat> |
Component: | kernel | Assignee: | John W. Linville <linville> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7 | CC: | beland, bjohnson, cebbert, davej, jos, mattdm, notting, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-11-02 19:20:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Stuart Jansen
2006-02-27 21:09:04 UTC
ipw2xxx is in the same boat. Really, we'd have to trap the firmware event somehow via udev/hal and post errors if there is no firmware available. This is not a hal issue. Ideally the kernel should issue one error and unload the driver or just have it stop complaining. If you want a feature in HAL that flags the device as not having firmware I would ask upstream. A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you. The same issue is present in Fedora 6, at least up to kernel-2.6.19-1.2895.fc6 or thereabouts. The manual workaround, I'm told, is to install bcm43xx-fwcutter and follow the instructions in README.fedora. I have a bcm43xx pcmcia card that works fine (I used bcm43xx-fwcutter to generate the firmware from the xp driver) using kernel 2.6.19-1.2895.fc6 - but using any newer kernels breaks the wireless. (In reply to comment #5) > I have a bcm43xx pcmcia card that works fine (I used bcm43xx-fwcutter to > generate the firmware from the xp driver) using kernel 2.6.19-1.2895.fc6 - but > using any newer kernels breaks the wireless. You might need newer firmware. Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] As noted above, this is present in released versions of Fedora 6, but I do not have the power to change the version number assigned to this bug. Thanks, and sorry about that. Updated to FC6. (clearing needinfo bit) I too had bcm43xx working, but no longer in the most recent FC6 kernels. It originally worked using a jwltest kernel, then it worked in standard FC6 kernels, but now some recent change has evidently broken it. Still a problem in Fedora 7, though I do not have permission to change the indicator. The hardware is detected, but Anaconda doesn't configure it properly. There is no warning message in system-config-network about the firmware needing an upgrade, though /var/log/messages does contain a helpful pointer to: http://linuxwireless.org/en/users/Drivers/b43#devicefirmware (Which says that the firmware is copyrighted and cannot be freely distributed.) I think it would be far better to relay the kernel messages, or to put something in a dialog box recommending checking the firmware, rather than simply ignoring the hardware. I'm not sure what part of "cannot be freely distributed" is unclear... Anyway, rest assured that we are aware of this issue and would very much like to resolve it -- there just aren't many options. I'm not sure what part of "give the user a useful explanation" is unclear... Anyway, rest assured we are annoyed by system-config-network pretending to work then not and would very much like to resolve it -- there just doesn't seem to be anyone with the knowledge or will to do it. Did you forget to attach a patch? Dude, if you plan on just ignoring this bug instead of adding a simple, useful error message of some type, just say so. Don't pretend a firmware license is preventing you and don't insult users when they provide feedback. Your hostility is unwelcome. Please take it elsewhere. Comment 15 means "if you have a detailed suggestion, please make it". Requesting a "message of some type" leaves lots of room for interpretation. If you read comment 12, there is already a "message of some type" in /var/log/messages. Encoding knowledge of every driver that may need firmware or some other enablement into system-config-network just doesn't scale and would be a maintenance problem. Without that, system-config-network would have no way to know which devices should be ignored (e.g. the ones that need firmware but don't have it). Ideally, we would just ship the required firmware and install it either unconditionally or upon detection of the matching hardware. However, the firmware for the devices in question is not provided under any license that clearly allows for that. So while your request may seem reasonable, there is no obvious and reasonable way to fulfill it. Mocking those assigned to work on the bug is unlikely to help. The actual errors in /var/log/messages I got were: Aug 26 21:51:29 localhost kernel: b43-phy0 ERROR: Microcode "bcm43xx_microcode5.fw" not available or load failed. Aug 26 21:51:29 localhost kernel: b43-phy0 ERROR: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the correct firmware (version 4) Aug 26 21:51:29 localhost firmware_helper[29110]: Loading of /lib/firmware/bcm43xx_microcode5.fw for b43 driver failed: No such file or directory Aug 26 21:51:31 localhost NetworkManager: <WARN> nm_device_802_11_wireless_scan(): could not trigger wireless scan on device wlan0: Network is down It seems NetworkManager knows that *something* is wrong, and the kernel knows why. It would be unnecessary to create a database of known hardware problems for system-config-network if the information from the kernel could be somehow captured. /var/log/messages isn't a particularly user-friendly place to dump important messages for everyday users, though it's useful to dump technical information there in case an everyday user files a bug so they can be asked to check the logs during the diagnostic process. A user-friendly notification mechanism would involve the GUI. It doesn't so much matter whether it's NetworkManager spontaneously popping up a notification error when you put the card in (which would be great) or a big red X in a system-config-network list. It could even be something as generic as "Wireless card ___ is not working. Problem with hardware, driver, or firmware?" The point is to give the user a heads-up that they are having more fundamental problems than simply not having their network settings input correctly. Or at least, that's the solution I would propose which I think would be more useful than making the hardware mysteriously disappear from system-config-network (as implied by the title of this bug). I'm sorry, but I don't think this is going to really change. Either eventually we will find a legal way to ship a b43 firmware package and none of this will matter, or things will stay as they are and people will have to heed the information in /var/log/messages. The suggestions in the last paragraph of comment 18 are outside the scope of a kernel bug. Feel free to raise them in the mailing list for NetworkManager. |