https://bugzilla.novell.com/show_bug.cgi?id=823645 https://bugzilla.novell.com/show_bug.cgi?id=823645#c1 --- Comment #1 from Hannes Reinecke <hare@suse.com> 2013-06-06 11:34:52 UTC --- This is does have nothing to do with multipathing. Even with multipathing disabled you want to load these modules if you talk to LUNs from certain arrays. The reason why these modules are preloaded is that the need to be _present_ by the time the system probes for these LUNs. If they are not probing will take _ages_. Hence you cannot delegate the task to udev, as by the time udev kicks in the devices are already probed for. And you've already suffered the delay. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=823645 https://bugzilla.novell.com/show_bug.cgi?id=823645#c3 Hannes Reinecke <hare@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|hare@suse.com | --- Comment #3 from Hannes Reinecke <hare@suse.com> 2013-12-09 11:12:43 UTC --- Chicken-and-egg problem. The scsi_dh_* driver have to be present by the time SCSI disks are probed; if not you're likely to see I/O errors which not only causes confusion but also increase boot time (or stall the machine entirely). And the disks are probed during module_init() from any SCSI HBA driver. Ergo they have to be loaded prior to the SCSI HBA modules. But then there's no-one who would be able to call 'request_module' ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=823645 https://bugzilla.novell.com/show_bug.cgi?id=823645#c5 Jean Delvare <jdelvare@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |hare@suse.com --- Comment #5 from Jean Delvare <jdelvare@suse.com> 2013-12-09 12:53:22 UTC --- But again we're only talking about actual SCSI hardware here, not SATA, right? I asked in comment #2 already but am under the impression that you only replied to my last question in that comment. I don't care if scsi_dh* modules are included and loaded on any system with a SCSI host adapter, even when that system doesn't need it. As soon as you have SCSI in a machine, you really don't care about initrd size and boot time. And your explanation in comments #3 and #4 convinced me there is no solution to this part of the problem anyway. What I really want is that systems which do NOT have SCSI at all, don't get these scsi_dh* modules in mkinitrd. We should be able to check for PCI devices with class 0100 (SCSI) and 0107 (SAS) and only include the scsi_dh* modules if at least one such device is present, right? I think we already do this kind of magic in mkinitrd for other devices, don't we? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=823645 https://bugzilla.novell.com/show_bug.cgi?id=823645#c7 --- Comment #7 from Jean Delvare <jdelvare@suse.com> 2013-12-09 15:18:22 UTC --- If we include the modules as soon as we find any device from your class list in comment #6, I'm afraid it'll happen on 99% of the machines. And I'm probably being optimistic. All systems where I really would like scsi_dh* to not be loaded do have USB controllers. But SCSI over USB or FireWire, really, does anyone do that? And booting from such devices? This sounds crazy. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.