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.
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.
FreeBSD sleeps for 15 seconds unconditionally, waiting for SCSI devices to settle. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
