Bug 177373 - -ENOENT from SIOCSIFFLAGS(IFF_UP) means no firmware found, but NetworkManager keeps trying
-ENOENT from SIOCSIFFLAGS(IFF_UP) means no firmware found, but NetworkManager...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-10 00:26 EST by Bernard Johnson
Modified: 2008-05-06 20:19 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:19:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 332919 None None None Never

  None (edit)
Description Bernard Johnson 2006-01-10 00:26:27 EST
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:
Comment 1 David Woodhouse 2006-01-12 05:33:25 EST
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.
Comment 2 Bernard Johnson 2006-01-27 15:14:30 EST
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.
Comment 3 David Woodhouse 2006-01-27 17:45:25 EST
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
Comment 4 Bernard Johnson 2006-01-28 02:57:01 EST
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.
Comment 5 David Woodhouse 2006-01-28 05:29:08 EST
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. 
Comment 6 Bernard Johnson 2006-02-28 18:49:16 EST
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.
Comment 7 David Woodhouse 2006-03-22 11:08:00 EST
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.
Comment 8 Bernard Johnson 2006-03-24 04:05:13 EST
David - You might want to take a look at bug #180953.  After I upgraded kernels,
I had to reopen that bug.
Comment 9 Bug Zapper 2008-04-03 12:42:24 EDT
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.
Comment 10 Bug Zapper 2008-05-06 20:19:22 EDT
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

Note You need to log in before you can comment on or make changes to this bug.