Bug 113462 - Network scripts invalidate hotplug... problem for Prism54
Network scripts invalidate hotplug... problem for Prism54
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2004-01-14 00:17 EST by Gavin Kan
Modified: 2014-03-16 22:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-26 21:04:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gavin Kan 2004-01-14 00:17:23 EST
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
   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

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.
Comment 1 Harald Hoyer 2004-01-14 04:43:02 EST
reassigning to initscripts
Comment 2 Bill Nottingham 2004-01-14 14:23:02 EST
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.
Comment 3 Gavin Kan 2004-01-14 18:33:30 EST
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.


Gavin Kan  
Comment 4 Andrew Rechenberg 2004-02-06 10:40:55 EST
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.
Comment 5 Neil Gierman 2004-10-26 13:40:45 EDT
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
Comment 6 Bill Nottingham 2004-10-26 21:04:44 EDT
No, the test3 problem is a udev bug. This should be generally fixed now.

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