Bug 177869 - /etc/init.d/net.wlan0 always fails on first start since driver takes several seconds to initialize
Bug#: 177869 Product:  Gentoo Linux Version: 2006.1 Platform: x86
OS/Version: Linux Status: RESOLVED Severity: enhancement Priority: P2
Resolution: FIXED Assigned To: phreak@gentoo.org Reported By: mreincke@gmx.net
Component: Ebuilds
URL: 
Summary: /etc/init.d/net.wlan0 always fails on first start since driver takes several seconds to initialize
Keywords:  
Status Whiteboard: 
Opened: 2007-05-09 22:10 0000
Description:   Opened: 2007-05-09 22:10 0000
Hi,
I'm using the ipw3945 wlan driver which happens to take some seconds to
initialize. The driver gets autoloaded by /etc/init.d/net.wlan0, but therefore
the script always fails with the error message 
rc-scripts: network interface wlan0 does not exist

The option sleep_scan_wlan0 does not help, it apparently requires the device to
be present to sleep ;-)

A workarround is adding the following in /etc/conf.d/net:
preup(){
        if [[ ${IFACE} = "wlan0" ]]; then
                sleep 3
        fi
        return 0;
}

Reproducible: Always

------- Comment #1 From Roy Marples (RETIRED) 2007-05-09 22:13:49 0000 -------
Actually udev autoloads the driver and tells baselayout "start now", so please
fix the driver.

------- Comment #2 From Roy Marples (RETIRED) 2007-05-09 22:17:45 0000 -------
Thinking about it, this maybe fixable interim with a udev rule that sleeps for
3 seconds.

------- Comment #3 From Momsen Reincke 2007-05-10 06:58:25 0000 -------
(In reply to comment #1)
> Actually udev autoloads the driver and tells baselayout "start now", so please
> fix the driver.
> 

Suppose we can't fix the driver for technical reasons, I think it would be
reasonable to have an option to tell the init-script that it has to wait for
some seconds. E.g. on older systems one cannot necessarily expect a device to
be present immediately after the driver was loaded.

------- Comment #4 From Roy Marples (RETIRED) 2007-05-10 07:02:01 0000 -------
(In reply to comment #3)
> Suppose we can't fix the driver for technical reasons, I think it would be
> reasonable to have an option to tell the init-script that it has to wait for
> some seconds. E.g. on older systems one cannot necessarily expect a device to
> be present immediately after the driver was loaded.

Then the option will be as you describe. The ebuild for the driver will
document the preup() workaround.

------- Comment #5 From Momsen Reincke 2007-05-10 07:08:57 0000 -------
What if it's different from machine to machine (I think that's the case here,
as I heard from no one else with this problem)? What if it only occurs on old
machines? I think something like WAIT_FOR_DRIVER="some time" in /etc/conf.d/net
would be much cleaner. Anyway, I think I'll file a bug for the ipw3945 driver
then.

------- Comment #6 From Roy Marples (RETIRED) 2007-05-10 07:12:26 0000 -------
(In reply to comment #5)
> What if it's different from machine to machine (I think that's the case here,
> as I heard from no one else with this problem)? What if it only occurs on old
> machines? I think something like WAIT_FOR_DRIVER="some time" in /etc/conf.d/net
> would be much cleaner. Anyway, I think I'll file a bug for the ipw3945 driver
> then.

This is the bug for the driver now - it's been assigned to phreak, the ipw3945
maintainer.

And we're not in the habit of adding sleep workarounds (or any other
workarounds really) that are driver specific. We used to, but that caused to
many problems later on when said issues were solved, so we no longer. No
exceptions.

But as I said, this may be fixable in a udev rule instead.

------- Comment #7 From Matthias Schwarzott 2007-05-12 16:45:03 0000 -------
(In reply to comment #0)
> Hi,
> I'm using the ipw3945 wlan driver which happens to take some seconds to
> initialize. The driver gets autoloaded by /etc/init.d/net.wlan0, but therefore
> the script always fails with the error message 
> rc-scripts: network interface wlan0 does not exist
> 
How exactly the driver gets loaded? Does udev autoload it, or really the
net.wlan0-init-script?

> The option sleep_scan_wlan0 does not help, it apparently requires the device to
> be present to sleep ;-)
That now depends if you added net.wlan0 to some runlevel, or rely on
udev/baselayout calling it, as soon as the device appears.

If doing it that way the mentioned sleep_scan_wlan0 also should work.

------- Comment #8 From Momsen Reincke 2007-05-12 22:37:05 0000 -------
(In reply to comment #7)

> How exactly the driver gets loaded? Does udev autoload it, or really the
> net.wlan0-init-script?
net.wlan0 init script... at least 
RC_PLUG_SERVICES="!net.wlan*"
is set.

> That now depends if you added net.wlan0 to some runlevel, or rely on
> udev/baselayout calling it, as soon as the device appears.
> 
> If doing it that way the mentioned sleep_scan_wlan0 also should work.
Which way? net.wlan0 is added to my "home"-runlevel.

------- Comment #9 From Matthias Schwarzott 2007-05-13 07:16:34 0000 -------
(In reply to comment #8)
> (In reply to comment #7)
> 
> > How exactly the driver gets loaded? Does udev autoload it, or really the
> > net.wlan0-init-script?
> net.wlan0 init script... at least 
> RC_PLUG_SERVICES="!net.wlan*"
> is set.

This sounds to me like changing RC_PLUG_SERVICES to not ignoring the device
should work, but this could require to have different RC_PLUG_SERVICES settings
for different runlevels!?

Else you could need some own scriptlet to wait until the device appear.
Either as pre_up, or as second script to just wait until device is there.

I suggest to not let net.wlan0 load the module, but add it to modules.autoload,
or allow udev to coldplug it, to gain some seconds.

------- Comment #10 From Momsen Reincke 2007-05-13 09:52:19 0000 -------
(In reply to comment #9)
> This sounds to me like changing RC_PLUG_SERVICES to not ignoring the device
> should work, but this could require to have different RC_PLUG_SERVICES settings
> for different runlevels!?
Indeed. The problem is being worked arround with the above preup function,
nevertheless I'm looking for a cleaner solution, which would e.g. be an udev
rule as proposed in comment 2.
> 
> Else you could need some own scriptlet to wait until the device appear.
> Either as pre_up, or as second script to just wait until device is there.
> 
> I suggest to not let net.wlan0 load the module, but add it to modules.autoload,
> or allow udev to coldplug it, to gain some seconds.
In both cases I have the driver loaded no matter which runlevel I'm in which is
bad for power saving reasons.
> 

------- Comment #11 From Matthias Schwarzott 2007-05-14 07:01:48 0000 -------
(In reply to comment #10)
> Indeed. The problem is being worked arround with the above preup function,
> nevertheless I'm looking for a cleaner solution, which would e.g. be an udev
> rule as proposed in comment 2.

I have no idea how such udev rule should look like, as the network device that
could trigger the rule does not exist at that moment.

Uberlord: Isn't it possible to have different RC_PLUG_SERVICES settings for
different runlevels we boot in?

------- Comment #12 From Roy Marples (RETIRED) 2007-05-14 07:12:34 0000 -------
(In reply to comment #11)
> Uberlord: Isn't it possible to have different RC_PLUG_SERVICES settings for
> different runlevels we boot in?

Not with baselayout-1 it's not.
Could be possible in baselayout-2, but I'd have to talk to people as I'm not
sure that having runlevel specific conf.d/rc would be a good thing.

------- Comment #13 From Roy Marples (RETIRED) 2007-05-15 15:57:36 0000 -------
This will be possible with baselayout-2.0.0_alpha4

It won't be possible with baselayout-1 due to a chicken and egg situation - we
need to load /etc/conf.d/rc so we where to look to work out what runlevel we're
in.

------- Comment #14 From Roy Marples (RETIRED) 2007-05-31 06:12:07 0000 -------
(In reply to comment #13)
> This will be possible with baselayout-2.0.0_alpha4

This should be fixed in alpha3-r1, so that's base-system part of this done :)

------- Comment #15 From Christian Heim (RETIRED) 2007-09-09 08:39:24 0000 -------
OK, I added a postinst hook suggesting the preup snippet you pasted. This is
only a workaround, since I really can't (and won't) fix the ipw3945 driver to
immediately be ready when loaded.