Description of problem: in the script, etc/rc.d/init.d/network, while interfaces are being booted up, sysctl is run to set kernel.hotplug = /bin/true. This is ok for existing drivers but for the Prism54 driver, kernel.hotplug must equal /sbin/hotplug otherwise the driver firmware cannot be loaded to the prism card. Version-Release number of selected component (if applicable): Came with standard RH9 release. Kernel I am using is 2.6.0 but is reproducable on 2.6.1. My friend has the same problem on 2.4.22 though. How reproducible: on every system I;ve used as listed above Steps to Reproduce: 1.Install a Prism54 card on 2.6.0. Ensure /sys is mounted before network script is up and running. 2.Make sure card is plugged in 3.when network script is run, it will display "firmware cannot be loaded" Actual results: Expected results: Additional info: I fixed the problem by modifying the network script as follows: 1) Look for -> action $"Bringing up interface $i: " ./ifup $i boot 2) Change it to -> if [ "$i" != "eth1" ] ; then action $"Bringing up interface $i: " ./ifup $i boot else sysctl -w kernel.hotplug=$oldhotplug > /dev/null 2>&1 action $"Bringing up interface $i: " ./ifup $i boot sysctl -w kernel.hotplug="/bin/true" > /dev/null 2>&1 fi Obviosuly, my script is poorly constructed but it does fix the problem... i could do a better job but wanted your input on the best solution possible. Sorry if this bug is a little lame or if it's poorly written/assigned... it's my first submission.
reassigning to initscripts
Hm, unfortunately, you can't really unilaterally enable hotplug during the network script; otherwise, you'll get interfaces brought up even though you configured them not to come up.
Hi Bill, Prism54 drivers require that an ARM firmware be loaded before the card can be initialized. Is there anyway to selectively turn-on the hotplug when it encounters a Prism54 card? Or to delay the startup of these devices until after hotplug is turned on? For example, by putting something into the ifcfg-ethX file such as TYPE=PRISM54? Unfortunately, I've only started studying these init scripts so I don't fully understand the impact of what I've done to my script. Regards, Gavin Kan
I'm not sure if there are other conditions to consider, but this is the way that I fixed the issue for the prism54 module. I added a HOTPLUG=y to my ifcfg-eth1 and then I check for that variable in the network startup script. If it exists I reset the /proc hotplug entry, bring up the interface and the reset hotplug. Else I just startup as normal.
I'm seeing this sam problem when I went from Fedora FC2 to FC3test3. Since it is exactly the same issue I wasn't sure if I should open a new bug or just append to this one. I had not actually thought to modify the init scripts but on my laptop when I went from FC2 to FC3T3 and started seeing this problem, I just reloaded the prism54 module at the end of the rc.local script: rmmod prism54 modprobe prism54 just reloading the module after pcmcia and hotplug are running allows the firmware upload to work just fine. Also probably not the most eligant solution but it keeps me up after a reboot. I'm thinking about making a seperate init scrip for the prism54 reload so that I can have my network up and running for the services that need it (NFS mount for example).
No, the test3 problem is a udev bug. This should be generally fixed now.