Bug 145283

Summary: ipw2100 firmware load fails
Product: [Fedora] Fedora Reporter: Jukka Ketelaars <jukka>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ziga.mahkovec
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-21 09:45:57 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 Jukka Ketelaars 2005-01-16 22:34:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
Loading the ipw2100 module yields error messages about problems with
the loading of the firmware. Up to today this worked fine for me. The
firmware files are still in /lib/firmware, so that is not the problem.

Version-Release number of selected component (if applicable):
udev-050-1

How reproducible:
Always

Steps to Reproduce:
1. modprobe ipw2100
    

Actual Results:  ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not
available or load failed.
ipw2100: eth1: ipw2100_get_firmware failed: -2
ipw2100: eth1: Failed to power on the adapter.
ipw2100: eth1: Failed to start the firmware.
divert: freeing divert_blk for eth1
ipw2100Error calling regiser_netdev.
ipw2100: probe of 0000:02:02.0 failed with error -5


Expected Results:  Firmware should have been loaded.

Additional info:

Comment 1 Jukka Ketelaars 2005-01-23 14:51:53 UTC
The situation has improved somewhat. At the time I filed this bug, the
modprobe would always produce the firmware load error (i.e. ipw2100
did not work at all). Now the problem only occurs during boot, after
which I can load the module without problems. A lot of packages from
development have gone in since, but I can't figure out which one did
the trick. Maybe initscripts-8.04-1?

Comment 2 joe 2005-01-26 23:43:04 UTC
I get the following from modprobe ipw2100:

FATAL: Error inserting ipw2100
(/lib/modules/2.6.10-1.741_FC3/updates/drivers/net/wireless/ipw2100/ipw2100.ko):
Unknown symbol in module, or unknown parameter (see dmesg)


And dmesg:

ipw2100: Unknown parameter `irq'

Comment 3 Harald Hoyer 2005-01-27 01:52:26 UTC
joe: please remove the ipw2100 irq parameter from /etc/modprobe.conf 

Comment 4 joe 2005-01-27 20:39:43 UTC
Great - between Harald Hoyer here and Jim Lawrence at Fedora I finally
have wireless running on my 2 year old laptop - Thank you very much!

Comment 5 joe 2005-02-03 03:11:12 UTC
Harald - why did wireless still work when I upgraded my *741_FC3
kernel to *760_FC3 - just lucky? - I thought I would need to install
new modules for each new kernel.

Comment 6 Harald Hoyer 2005-02-03 10:20:30 UTC
joe: the module is provided in the kernel package... 
/lib/modules/$(uname -r)/kernel/drivers/net/wireless/ipw2100/ipw2100.ko
the problem is most likely the firmware in /lib/firmware: ipw2100-1.3.fw

Comment 7 joe 2005-02-03 22:27:39 UTC
I am very sorry Harald if I sounded sarcastic above. Wireless works
great. And I was really able to upgrade my kernel from a working
ipw2100.ko set up with 741_FC3 without doing a thing - and my wireless
continued to work with 760_FC3 even though I did nothing new. So there
is no problem at all, just wanted to know why wireless did not break
with the kernel upgrade. Thanks.

Comment 8 Ziga Mahkovec 2005-04-10 02:35:01 UTC
I'm having the same problem with the FC4 kernels (e.g. kernel-2.6.11-1.1233_FC4,
which contains ipw-1.0.3).  The ipw2100 module fails to load the firmware during
boot, with the same error message as in comment #1.  When loading the module
manually (once the system is up), it works fine.  The firmware is correctly
installed in /lib/firmware.

The project website[1] suggests increasing the firmware timeout value in
/sys/class/firmware/timeout, however that didn't help.  Neither did upgrading
the driver to 1.1.0.  There's a similar upstream bug[2] which puts the blame on
hotplug.

The only workaround I found for loading the firmware during early boot was to
add a pause before loading the module (I patched rc.sysinit to insert a 'sleep
1' when calling load_module() with ipw2100).  But even so, it takes much longer
for the module to load than usual -- about 10 seconds.  Interestingly, 10
seconds is also the default firmware timeout (and this value directly affects
the time it takes to load the module).

The best solution was to actually blacklist the module, disable kudzu and then
load the module in rc.local.  This way it works correctly and also loads fast.

[1] http://ipw2100.sourceforge.net/#issues
[2] http://www.bughost.org/bugzilla/show_bug.cgi?id=24


Comment 9 Dan Williams 2005-04-11 15:12:37 UTC
What doesn't exactly get explained is why it _doesn't_ take 10s to load the
firmware once you've booted and had to do a 'rmmod ipw2100; modprobe ipw2100'. 
Sometimes it loads for me, sometimes it doesn't, now its about 75% of the time
it does load on boot.  About two weeks ago, it was almost never, but something
(kernel?) changed to help the problem.

Comment 10 Ziga Mahkovec 2005-04-12 13:11:54 UTC
After further investigation, this turned out to be a udevd problem:

The problem only occurs if udevsend is used for hotplug events.  Upon startup,
udevd expects to service a hotplug event with a SEQNUM of 0.  Since the actual
SEQNUM of the first event is something like 477, the message queue will only get
serviced after a timeout (EVENT_TIMEOUT_SEC, which is set to 10 seconds).

The default firmware timeout is also 10 seconds, so by the time udevd relays the
firmware hotplug event, the kernel will already give up on the device.  It's
actually a race, which explains why this does work on occasion, and why sticking
a sleep before 'modprobe ipw2100' helps.  The reason this only occurs during
boot is that eventually udevd gets on track with the sequence numbers.

The good news is that upstream udev-056 introduces a separate init timeout (2s),
which should take care of this issue (and I see that udev was updated to 056 in
CVS).


Comment 11 Ziga Mahkovec 2005-04-21 00:44:44 UTC
Verified that firmware loading works fine with udev-057-1.