On Mon, 3 Apr 2006, Alexander E. Patrakov wrote:
> Ken Moffat wrote:
> > On this particular box, with my current kernel, the values are 236 or 237
> > for loop, and 60 for confirm. Can't get it to show anything different.
> > Adding another echo at the start of the loop confirms it goes around for 2
> > or 3 passes before the queue exists, seems to complete it within one pass
> > (display didn't stay on screen long enough to be certain), and then waits
> > for a further 60 passes before deciding it must have processed everything.
>
> Note: adding "echo -n '*'" at the start of the loop affects the timing
> seriously enough to hide the possibility of the tty uevent leak on my system.
> So don't trust those numbers. Without the echo, they are different.
That doesn't surprise me.
>
> > So, what is the derivation of this magic number 60, which I assume
> > approximates to 6 seconds ?
>
> I could say "The longest known to me in-kernel delay (5 seconds, in
> usb_storage) plus one second". But that doesn't reflect the history.
>
> Archaic tried iterating 10 times, but got leaks due to the kernel reconnecting
> his USB devices fom uhci_hcd to ehci_hcd. I got USB storage related leaks but
> was told to ignore them. Then the magic number was increased to 60, just in
> case.
>
Thanks for that explanation. I've been looking at fedora-5 (udev-084,
so still using a script) - I found that slightly easier to understand
(follows this paragraph), because it distinguishes waiting for the queue
to appear, and waiting for it to disappear. But if I read you
correctly, it's possible for the queue to disappear, then reappear a
little later, so trying to boot to e.g. a rootfs on flash might be
problematic with their code ?
wait_for_queue() {
loop=20
while test ! -d /dev/.udev/queue; do
usleep 100000;
test "$loop" -gt 0 || return 1
loop=$(($loop - 1))
done
loop=200
while test -d /dev/.udev/queue; do
usleep 100000;
if [ "$loop" -le 0 ]; then
echo -n "Wait timeout. Will continue in the
background."
return 1
fi
loop=$(($loop - 1))
done
return 0
}
Of course, I haven't been testing with USB devices, and I haven't got
any suitable devices to play with.
> FreeBSD sleeps for 15 seconds unconditionally, waiting for SCSI devices to
> settle.
>
>
Yeah, SCSI and booting quickly don't go together - my only real SCSI is
a tape drive on my old server - big delay in the bios before getting to
lilo, then another 15 second delay while the adaptec scsi driver waits.
Ken
--
das eine Mal als Trag??die, das andere Mal als Farce--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
