Bug#401916: Bug 401916: analysis and suggested solution
On Mon, Feb 19, 2007 at 11:02:10PM +0100, maximilian attems wrote:
Quoting David Härdeman <david@hardeman.nu>:
I've attached a patch against the udev and initramfs-tools source
packages that implement the following changes...please review:
...
2) Checks in udev for scsi/firewire/usb have been added and will add 10
seconds of sleep if found
hmm this seems to affect any modern board,
so urrgs.
Yes...urgh
but your grep on the usb_storage thread was not successfull,
so maybe we need here build depend logic?!?
I've realised that usb_storage thread grepping / usb_storage module
grepping will not work because the usb-storage module is loaded
asynchronously and udevsettle will return when the usb host driver
is loaded, not when the usb_storage driver has been loaded. The
usb-storage driver might be loaded at an arbitrary time later...and the
same goes for the kernel scanning threads.
On most machines with most usb devices this apparently takes place fast
enought to work, on Mika's it doesn't.
In addition, the grepping would not solve the more generic case
(firewire, sas, fibre channel, you name it).
I'm still seeing three possible short-term fixes:
Auto-decide that scsi/usb/whatever is in use and sleep a couple of
seconds
Let the affected users specify the sleep interval using the rootdelay
parameter
Add another parameter in addition to rootdelay...let's call it
rootdelaydev, then affected users can set that parameter to something
sane (e.g. /dev/sdb) and the udev script can sleep until that dev
appears.
None of the three options are magic bullets but rather bandaids...and
all of them would need some documentation
3) The module scsi_wait_scan will be loaded by udev if scsi is detected,
modprobe should only return from loading that module once all scsi
busses have been scanned (I found that module yesterday...pretty
nifty band-aid solution to the problem, does not help with
usb/firewire though).
ack, but not for etch:
The relevant commit happend for 2.6.20 with the note:
"This patch only handles drivers which call scsi_scan_host.
Fibre Channel, SAS, SATA, USB and Firewire all need additional work."
Oh, I missed that...darn
so it would already be of a help for uname = 2.6.20.
willy was pushing this work, so we'd have the expertise for a postetch
kernel fixes.
Postetch we won't need that, since we'll implement a udev-driven
asynchronous wait-for-root-dev-on-boot...right? :)
How would MODULES=MOST create stuff under /dev then?
oot
what about static dev.. ;)
Yuck :)
--
David Härdeman
Reply to: