Stats

Many times on the forum someone has reported that they used the Network Wizard and it worked, but after rebooting the network was not working. They then had to rerun the Network Wizard, after every bootup. I'm wondering if a discovery I made today explains that.

My new 'pup_event_backend_d' script receives kernel uevents and proceses them. I also put in a debug mode, that logs various things to files. To one file it logs all of the uevents, with some timing information, so I was able to see the sequence of events and the timing.

While testing the 'acx.ko' wireless networking kernel module, I discovered something quite alarming. When 'pup_event_backend_d' loads the acx module, the module then makes a request for firmware, however there is then a delay of 10 seconds before the module notifies the kernel that it has made the /dev/wlan0 device available. That's an incredibly long time. Perhaps the acx module is abnormal.

Quite a long time ago, it was actually Puppy version 0.9.4 and the forum member at that time who reported this was 'wacha'. Member wacha reported that the 'e1000' module was slow in making its interface available and required a 3 second delay. So from that time there is a 'sleep 3' in /etc/rc.d/rc.network.

But, perhaps a much bigger delay is required. Perhaps this would explain the problem as stated at the beginning of this post. It's tentative at this stage, and I need to test some more wifi hardware. I've got new USB and PCMCIA wifi cards, but I don't know if they use kernel modules that require firmware -- as I suspect that firmware loading may be a major cause of the delay -- based upon my singular experience with the acx module (the firmware files had already been installed to /lib/firmware so that was not an issue in my testing). I'll test them this evening.

Anyway, something to consider. If you are having wifi trouble, try bumping that 'sleep 3' up to 'sleep 10'.

One thing I will think about is to get pup_event_backend_d to watch out for any uevents that notify of a network interface becoming available and log that somewhere.

Posted on 18 Jun 2008, 13:02

Comments:

Posted on 18 Jun 2008, 14:14 by RaffyRT73 in ClassmateRT73 in the Classmate PC must be a good test device, as (in kernel 2.6.18) it uses firmware.

My experience with the card is that the first "scan" in the network wizard does not detect networks. It usually needs re-"scan".

Posted on 18 Jun 2008, 16:50 by robDelayIf you reorder the events so the network module is loaded earlier, then non-network related things are processed, would this reduce the amount of delay required?

Posted on 18 Jun 2008, 17:12 by Dougal10 Second DelayI'm quite positive someone reported in the past that they had to make it "sleep 10" to get it working for them, too, so it is probably a good idea.

Posted on 19 Jun 2008, 8:55 by Springersleep considered harmfulLet's see if we can figure out how to eliminate the underlying cause of the loading delays before we work around them! Ideally, there will be exactly ZERO "sleep" commands in the startup scripts.

Sleeping in scripts is evil and the stack-up of a bunch of "just a couple of seconds" sleeps across a couple of dozen startup scripts is deadly.

Yes, I realize we're largely at the mercy of the folks that write the drivers, but I personally think a policy of "sleep ONLY as a last resort" is the right way to go, especially for a lean distro like Puppy.

Posted on 20 Jun 2008, 16:48 by Dougalsleep considered harmfulSpringer: rc.network is run in the background, so it doesn't add to boot time.