Hi, I just looked at that bug myself and then double checked the network startup script. Comment #2 shows the catch 22 you're in. Hotplug must not be enabled "unilaterally", but the Prism54 cards cannot load their firmware without hotplug support. So... somebody's out of luck. Maybe a RFE for FC4 would be to allow hotplug to be active while the network is being brought up when entering runlevel 3 or 5 -- or at least on a per interface basis. Andrew > -----Original Message----- > From: Neil Gierman [mailto:ngierman@xxxxxxxxxxxx] > Sent: Tuesday, October 26, 2004 05:57 PM > To: ''For testers of Fedora Core development releases'' > Subject: RE: Prism54 firmware load failure only during boot > > I just updated to kernel 2.6.9-1.643 and still same issue. I was going to > file a bug and noticed the same issue already reported with RH9. I added a > comment to that bug > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113462 and am waiting > to see if they want me to start a new bug or just append to the current. > > > -----Original Message----- > > From: fedora-test-list-bounces@xxxxxxxxxx > > [mailto:fedora-test-list-bounces@xxxxxxxxxx] On Behalf Of Neil Gierman > > Sent: Friday, 22 October, 2004 14:52 > > To: 'For testers of Fedora Core development releases' > > Subject: RE: Prism54 firmware load failure only during boot > > > > Just updated to udev-039-6 with same symptoms. > > > > > -----Original Message----- > > > From: fedora-test-list-bounces@xxxxxxxxxx > > > [mailto:fedora-test-list-bounces@xxxxxxxxxx] On Behalf Of > > Neil Gierman > > > Sent: Friday, 22 October, 2004 13:21 > > > To: 'For testers of Fedora Core development releases' > > > Subject: RE: Prism54 firmware load failure only during boot > > > > > > I am at udev-039-3 :( > > > > > > > -----Original Message----- > > > > From: fedora-test-list-bounces@xxxxxxxxxx > > > > [mailto:fedora-test-list-bounces@xxxxxxxxxx] On Behalf Of > > > Dan Williams > > > > Sent: Friday, 22 October, 2004 12:10 > > > > To: For testers of Fedora Core development releases > > > > Subject: Re: Prism54 firmware load failure only during boot > > > > > > > > Update to udev-0.39-3 or later. > > > > > > > > Dan > > > > > > > > On Fri, 2004-10-22 at 14:33 +0000, Andrew wrote: > > > > > Hi, > > > > > > > > > > Join the party. I have noticed this, but I am just so glad > > > > to get it to load the firmware at all, I figured I could > > > live with it > > > > not working during boot. For the record are you running > > 2.6.9-1.640? > > > > > > > > > > With mine, even with I plug it in after the boot is > > > > complete, it fails to load the firmware anywhere from 2 > > to 4 times > > > > before getting loaded. You should also see in your > > > messages log that > > > > the /dev/0000:30.0 (or similar) was being removed by > > udev, for each > > > > failed firmware load. > > > > > > > > > > My gut tells me there is a race condition in the sysfs > > > > interface of the prism54 driver, so that the place where it > > > needs to > > > > cp the firmware to, does not exist yet when the cp actually > > > happens. > > > > Whether or not anything like udev is involved in that race > > > condition, > > > > I don't know, b/c I've not researched it enough to find > > out --- yet. > > > > > > > > > > I'm still learning a lot (and have a lot to learn) about > > > > the hotplug > > > > > environment, etc., (as you will see if you look at my bz > > > > entry for hal > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135202) > > > > > > > > > > If you do bz I would love to follow the story -- but I will > > > > keep my mouth shut :-) so could yout post the #? > > > > > > > > > > Does hal-device-manager advanced properties for your WG511 > > > > show the right MAC? > > > > > > > > > > Thanks & good luck. > > > > > Andrew > > > > > > > > > > > -----Original Message----- > > > > > > From: Neil Gierman [mailto:ngierman@xxxxxxxxxxxx] > > > > > > Sent: Friday, October 22, 2004 02:05 PM > > > > > > To: fedora-test-list@xxxxxxxxxx > > > > > > Subject: Prism54 firmware load failure only during boot > > > > > > > > > > > > I just upgraded from FC2 to FC3test3 and noticed a new > > > > behavior with > > > > > > my Netgear WG511. > > > > > > > > > > > > In FC2 I would get a failure during network init because > > > > eth1 (the > > > > > > prism54) was not found. As soon as pcmcia started then > > > the module > > > > > > would load and insert into my wireless network without > > > > any action from me. > > > > > > > > > > > > Now in FC3test3, the prism54 module loads and complains > > > about not > > > > > > being able to load the firmware (the firmware is in > > the correct > > > > > > place according to /etc/hotplug/firmware.agent). As > > > soon as get a > > > > > > shell I rmmod prism54 and modprobe prism54 and it loads > > > > and is able > > > > > > to upload the firmware just fine (which I have now added > > > > the rmmod > > > > > > and modprobe to rc.local so I can reboot remotely and > > > still gain > > > > > > access after reboot). I updated all packages (including > > > > kernel) that > > > > > > were available from yum and the same symptoms are there. > > > > I searched bugzilla and didn't see anything on the prism54. > > > > > > > > > > > > Has anyone seen this, or should it go to bugzilla? > > > > > > > > > > > > dmesg: > > > > > > > > > > > > ....... > > > > > > device-mapper: 4.1.0-ioctl (2003-12-10) initialised: > > > > > > dm@xxxxxxxxxxxxxx > > > > > > cdrom: open failed. > > > > > > kjournald starting. Commit interval 5 seconds > > > > > > EXT3 FS on hda1, internal journal > > > > > > EXT3-fs: mounted filesystem with ordered data mode. > > > > > > Adding 524152k swap on /dev/hda3. Priority:-1 extents:1 > > > > > > IA-32 Microcode Update Driver: v1.14 <tigran@xxxxxxxxxxx> > > > > > > microcode: No new microdata for cpu 0 > > > > > > ip_tables: (C) 2000-2002 Netfilter core team > > > > > > ip_tables: (C) 2000-2002 Netfilter core team > > > > > > eth1: islpci_open() > > > > > > eth1: resetting device... > > > > > > eth1: uploading firmware... > > > > > > prism54: request_firmware() failed for 'isl3890' > > > > > > eth1: could not upload firmware ('isl3890') > > > > > > eth1: islpci_open() > > > > > > eth1: resetting device... > > > > > > eth1: uploading firmware... > > > > > > prism54: request_firmware() failed for 'isl3890' > > > > > > eth1: could not upload firmware ('isl3890') > > > > > > eth1: islpci_open() > > > > > > eth1: resetting device... > > > > > > eth1: uploading firmware... > > > > > > prism54: request_firmware() failed for 'isl3890' > > > > > > eth1: could not upload firmware ('isl3890') > > > > > > eth1: islpci_open() > > > > > > eth1: resetting device... > > > > > > eth1: uploading firmware... > > > > > > prism54: request_firmware() failed for 'isl3890' > > > > > > eth1: could not upload firmware ('isl3890') > > > > > > eth1: islpci_open() > > > > > > eth1: resetting device... > > > > > > eth1: uploading firmware... > > > > > > prism54: request_firmware() failed for 'isl3890' > > > > > > eth1: could not upload firmware ('isl3890') > > > > > > cs: IO port probe 0x0c00-0x0cff: clean. > > > > > > cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 > > > 0x370-0x377 > > > > > > 0x4d0-0x4d7 > > > > > > cs: IO port probe 0x0a00-0x0aff: clean. > > > > > > i2c /dev entries driver > > > > > > lp: driver loaded but no devices found ---------------- > > > > End of boot > > > > > > eth1: removing device ---------------------------- > > rmmod prism54 > > > > > > divert: freeing divert_blk for eth1 Unloaded prism54 > > > driver Loaded > > > > > > prism54 driver, version 1.2 ---------------------- > > > > modprobe > > > > > > prism54 > > > > > > ACPI: PCI interrupt 0000:06:00.0[A] -> GSI 11 (level, > > > > low) -> IRQ 11 > > > > > > divert: allocating divert_blk for eth1 > > > > > > ip_tables: (C) 2000-2002 Netfilter core team > > > > > > eth1: islpci_open() > > > > > > eth1: resetting device... > > > > > > eth1: uploading firmware... > > > > > > eth1: firmware uploaded done, now triggering reset... > > > > > > ip_tables: (C) 2000-2002 Netfilter core team > > > > > > > > > > > > lspci: > > > > > > 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - > > > 82443BX/ZX/DX Host > > > > > > bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - > > > > > > 82443BX/ZX/DX AGP bridge (rev > > > > > > 03) > > > > > > 00:04.0 CardBus bridge: Texas Instruments PCI1450 (rev 03) > > > > > > 00:04.1 CardBus bridge: Texas Instruments PCI1450 (rev > > > > 03) 00:07.0 > > > > > > Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) > > > > > > 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 > > > > IDE (rev 01) > > > > > > 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 > > > > USB (rev 01) > > > > > > 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03) > > > > > > 00:08.0 Multimedia audio controller: ESS Technology > > > > ES1978 Maestro > > > > > > 2E (rev > > > > > > 10) > > > > > > 00:09.0 Ethernet controller: Intel Corp. 82557/8/9 > > > [Ethernet Pro > > > > > > 100] (rev > > > > > > 09) > > > > > > 00:09.1 Serial controller: Agere Systems (former Lucent > > > > > > Microelectronics) LT WinModem 01:00.0 VGA compatible > > > > controller: ATI > > > > > > Technologies Inc Rage Mobility P/M AGP 2x (rev 64) > > > > 06:00.0 Network > > > > > > controller: Intersil Corporation Intersil ISL3890 > > > [Prism GT/Prism > > > > > > Duette] (rev 01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > fedora-test-list mailing list > > > > fedora-test-list@xxxxxxxxxx > > > > To unsubscribe: > > > > http://www.redhat.com/mailman/listinfo/fedora-test-list > > > > > > > > > > -- > > > fedora-test-list mailing list > > > fedora-test-list@xxxxxxxxxx > > > To unsubscribe: > > > http://www.redhat.com/mailman/listinfo/fedora-test-list > > > > > > > -- > > fedora-test-list mailing list > > fedora-test-list@xxxxxxxxxx > > To unsubscribe: > > http://www.redhat.com/mailman/listinfo/fedora-test-list > > > > -- > fedora-test-list mailing list > fedora-test-list@xxxxxxxxxx > To unsubscribe: > http://www.redhat.com/mailman/listinfo/fedora-test-list >