[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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?
what about static dev.. ;)

Yuck :)

David Härdeman

Reply to: