From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5 Description of problem: Apparently the new kernel has native support for my wireless chip: Jan 4 14:15:33 localhost kernel: bcm43xx driver 0.0.1 Jan 4 14:15:33 localhost kernel: bcm43xx: Chip ID 0x4306, rev 0x2 Jan 4 14:15:33 localhost kernel: bcm43xx: Number of cores: 6 Jan 4 14:15:33 localhost kernel: bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jan 4 14:15:33 localhost kernel: bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled Jan 4 14:15:33 localhost kernel: bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jan 4 14:15:33 localhost kernel: bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jan 4 14:15:33 localhost kernel: bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jan 4 14:15:33 localhost kernel: bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jan 4 14:15:33 localhost kernel: bcm43xx: Ignoring additional 802.11 core. Jan 4 14:15:33 localhost kernel: bcm43xx: PHY connected Jan 4 14:15:33 localhost kernel: bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jan 4 14:15:33 localhost kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jan 4 14:15:33 localhost kernel: bcm43xx: Radio turned off Jan 4 14:15:33 localhost kernel: bcm43xx: Radio turned off I don't currently have firmware extracted but the kernel keeps attempting to load it. This really pollutes the log files. Jan 4 14:15:57 localhost firmware_helper[2344]: Loading of /lib/firmware/bcm43xx_microcode4.fw for bcm43xx driver 0.0.1 driver failed: No such file or directory Jan 4 14:15:52 localhost NetworkManager: <WARNING> (): nm_system_device_set_up_down_with_iface() could not bring device eth1 up. errno = 2 Jan 4 14:15:57 localhost NetworkManager: <WARNING> (): nm_system_device_set_up_down_with_iface() could not bring device eth1 up. errno = 2 Jan 4 14:15:57 localhost kernel: bcm43xx: Error: Microcode "bcm43xx_microcode4.fw" not available or load failed. Jan 4 14:15:57 localhost firmware_helper[2344]: Loading of /lib/firmware/bcm43xx_microcode4.fw for bcm43xx driver 0.0.1 driver failed: No such file or directory Jan 4 14:15:57 localhost NetworkManager: <WARNING> (): nm_system_device_set_up_down_with_iface() could not bring device eth1 up. errno = 2 Version-Release number of selected component (if applicable): kernel-2.6.15-1.1819_FC5 How reproducible: Always Steps to Reproduce: 1. Boot kernel 2. tail -f /var/log/messages 3. Actual Results: Message is diplayed about every second. Additional info:
Presumably this is because NetworkManager keeps trying to bring the device up? It should probably give up if it keeps failing. I think the driver is doing the right thing -- if you do install the firmware and attempt to bring the device up, then it'll work. Until you have firmware, attempts to bring the device up will fail.
I believe that David's assertion on Comment #1 is correct. I finally got around to loading the firmware to see what happens and the message is not repeated ad infinitum once it finds the few firmware files it's trying to load. It does seem that the driver should give up, or at least throttle back, after a few load failures. It's not like firmware files are going to magically appear. After loading the firmware files, the driver still does not work. I'm curious as well, since I have a bcm43xx and I'm currently using ndiswrapper with it - what is the expected support for the bcm43xx in FC5? If it's going to be supported, I'll start making bug reports - otherwise, if it's a trial only, or preview-ware, I'll keep quiet.
The driver doesn't keep trying and can't give up. It's NetworkMananger which keeps trying. The inclusion of the bcm43xx driver is experimental right now -- we may drop it before FC5, or maybe just drop the PCI ID table so that it doesn't get automatically loaded. There are known problems with automatically backing down to slower rates when necessary, and with the precise ordering of configuration commands (you have to bring it up before setting essid etc). But mostly it works OK once it's set up. The best thing you can do is join the mailing list: http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Let me correct myself in comment #2. What I meant to say was "It does seem that NetworkManager should give up, or at least throttle back, after a few load failures." As far as the bcm43xx driver working or not - I have read some of the information from other bug reports and tried bringing up the driver the the very strict order and conditions required (by hand) - however, it still does not work for me. I get a specific error message each time. I will post that when I get my hand on my laptop again.
Bring the link up (ip link set eth1 up), then set the rate to something low enough to work (iwconfig eth1 rate 11M), then set the encryption key if you have one, then set the ESSID. Then look at the kernel messages ('dmesg') and see that it's associated. Run 'tcpdump -i eth1 -l -n' and observe other traffic on the network. You should already have an IPv6 address and IPv6 connectivity should be working. Then run 'dhclient eth1' if you want Legacy IP to also work. None of this is at all relevant to NetworkManager, whose bug we're polluting. Best to take it to the mailing list linked above.
I think should be a FC5 target if not blocker. Otherwise, unsuspecting users of FC5 might wind up with a good deal of disk space taken up by logs for hardware they didn't even think they needed the firmware for. *Especially* since getting that firmware requires a program (fwcutter) not even included in FC5.
We disabled the automatic loading of bcm43xx for FC5. However, the 2.6.16-1.2070_FC5 kernel (building now) should fix the problems with initialisation -- if you load it manually, it should work OK with either NetworkManager or the normal initscripts. Once the 2070 kernel is available, please try again and let me know if you have problems with it. Back on the topic of the bug though -- NetworkManager should probably interpret 'No such file or directory' errors when bringing up the device as 'Firmware not found' and report that to the user appropriately -- and then stop trying.
David - You might want to take a look at bug #180953. After I upgraded kernels, I had to reopen that bug.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp