Okay, so research suggests that all of the following pieces could read attributes via either /proc or /sys which if done on a prism2_usb card after it has already been intialised & setup, could cause the card to 'lock up' at some arbitrary point in the future (perhaps minutes later):
hald
usb.agent hotplug event relating to the prism2_usb card
usb.rc usb 'coldplug' script
and possibly even udev as well
With hald, I think its effect can be reduced by either
upgrading to a version >= 0.5.0 (which doesn't re-read
everything for every usb hotplug event), or by hacking
version 0.4.7 or below so it doesn't read /proc on every
usb hotplug event. Either way, you still have
the problem when hald first starts or receives the usb
hotplug event relating to the prism2_usb card.
One solution is to insert a long sleep in the script that
intialises the card (e.g. wlan.agent or similar). This has
the effect of delaying the initialising past all the above
activity, so the card only comes into use after it is 'safe'
to do so.
Another solution, which I have now implemented on my system,
is as follows:
1) Blacklist prism2_usb in hotplug (edit hotplug/blacklist
or a new file in hotplug/blacklist.d)
This stops the coldplug or regular hotplug events from loadingthe driver, and thus it won't initialise. Downside is you lose hotplug & auto-init if you plug the card in after you have booted up.
2) Create my own boot script in init.d and symlink to in
rc<n>.d with a link that will execute AFTER dbus/hald has
started. This script simply loads the prism2_usb module
(modprobe prism2_usb). Thus I forcibly load the module once
I believe it will be safe to start using the card.
[Note: you may already have a boot script or something else
that forcibly loads the prism2_usb module during boot. If you do, then either disable it and use the new script, or change it so that it executes AFTER dbus/hald has started]
The loading of the prism2_usb module should find the card, and trigger a 'add net' hotplug event, which in turn should lead to the right scripts to set up the card and establish the network using it.
3) Because the network is now coming up rather 'late' in the boot sequence, I also decided to delay the execution of all boot scripts for services that depend on the network being present, e.g. ntpdate, nfs stuff, portmap, fetchmail and so on. This is not essential, since these daemons should just whine a bit until the network is available, but I thought it would be cleaner to not start them until I new I had a network.
I did this by:
3a) Creating a new dir rc.network
3b) Moving the start symlinks for the network-dependant
services from the rc<n>.d dirs to rc.network
3c) Writing my own little script called rc.network/run_these
to execute rc.network/S*
3d) Using the 'up' option facility in /etc/network/interfaces to run this new little script
The last point is specific to debian systems (I'm on Ubuntu, which is debian based). It allows me in the specification of the network interface to declare a script that is only run once that interface has come up. There are probably ways to do this on other distros - but I don't know what they are.
Having done all the above, my boot (time to login prompt) is slightly faster (because certain services are not immediately started), and while I am logging in the network comes up and the services that depend on it automatically start. Crucially, the prism2_usb card then behaves itself!
Karl
Karl
-----------------------------------------
Email provided by http://www.ntlhome.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.