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:

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?

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.

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

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.

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).