#9 Linux kernel 2.6 hotplug issues
Not sure if this is a weakness in the speedtouch
hotplug scheme or the linux 2.6 hotplugging architecture.
Basically the speedtouch agent gets called once for
each distinct USB bus found at boot and then again by
the standard hotplug init.rc script. Thats ugly, to say
the least.
I have three busses, so I get three executions from the
kernel and one from /etc/rc.d/init.d/hotplug.
Secondly, it's one of the first three (kernel-invoked)
attempts that eventually works - but the key is
"eventually" since it takes a while to upload the
firmware. And, as the first three attempts are
"asynchronous" to the init.d scripts, the upload
invariably completes AFTER the standard network
start-up scripts have attempted to start the network
(and, in the case of the ppp0 peer, failed due
"resource temporarily occupied"). Again, that isn't
fatal because the eventual success of the
speedtouch-start script completes the network
configuration, but by then certain daemons that rely
upon the network being up have also attempted to start,
and failed.
I have put in a three-phase hack to my scripts, but I
recognize its IS a hack:
1) i've added an "export FROM_HOTPLUG_RC=yes" line to
the init.d hotplug script.
2) i've added a "[ "$FROM_HOTPLUG_RC" = "yes" ] ||
return 0" line as the first thing in the add action in
the speedtouch hotplug agent.
3) i've put in an uncondition exit 0 after the
modem_run execution in speedtouch-start.
This has the effect of allowing low-level device
initialization when the kernel invokes the hotplug
scripts but preventing upload of the firmware until the
init.d hotplug script invokes the speedtouch agent
where the upload is synchronous with the rest of the
scripts and will, therefore, cause the initialization
of the system to wait until it is successful. It also
ensures that the standard network startup scripts (in
mandrake, at any rate) seemlessly work.
Logged In: NO
Sorry - forgot to log in before doing that - I'm Martin
Bartlett, martin.bartlett@club.fr