Jeremy Herbison wrote:
Alexander wrote:
Basically, it means that we have three options WRT udev and hotplug.
1) Upgrade to their new way of handling things, (i.e., linux-2.6.15 +
patches, new udev, new rules, no hotplug).
2) Keep everything as it is currently (i.e., linux >= 2.6.12, udev,
current rules, hotplug)
3) Remove both udev and hotplug, revert to static /dev
But (1) means that we WILL break things at least for Darren Salt (i.e.,
make his computer unbootable--do you want this for your own system?).
The "unable to wait reliably for all hotplug events" problem looks
unsolvable.
(2) is not currently supported upstream, so if we choose this, we are on
our own.
This leaves us with no option other than (3). Sorry for my inability to
say anything else.
Well why not choose a sensible timeout, and put a note with an optional
sed in the bootscript instructions which says something like "Slower
machines may need more time on boot to listen for hotplug events. If you
are experiencing difficulties, try doing the following:"
Your wording is not completely technically correct and should be
improved. Try creating a short version of the text below.
What happens (at least in my case with USB) is:
1) The script creates an empty /dev/.udev/queue directory
2) The script causes the kernel to emit uevents (that's the new official
name of what formerly was called "hotplug events").
3) udevd gets those uevents, and reacts upon them. This reaction
involves, among other things, making device nodes and calling
/sbin/modprobe to load new drivers.
4) Those drivers are bound to devices by the kernel, this produces new
uevents, go to (3).
5) When the internal queue of udev becomes empty, it removes the
/dev/.udev/queue directory and the loop exits.
The problem is that some modules take longer than 0.1s to detect their
hardware (e.g., USB storage takes up to 10 seconds), so:
6) such late uevents reach udev _after_ the loop ends, and then it may
be too late.
My "solution" is to rewrite the script so that it repeatedly checks that
the queue stays empty for some period of time (i.e., retests the
existence of /dev/.udev/queue several times with delays between them)
instead of exiting immediately when the queue becomes empty for a moment.
Although I admit that the reported /dev/hda case doesn't really fit the
above scenario, since there are no modules involved.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
