Created attachment 266615 [details, diff] genkernel-2.4.14-r1-noslowusb.patch As some other forum posts (e.g http://forums.gentoo.org/viewtopic-t-573464.html) have already pointed out the slowusb function of genkernel adds 10 seconds extra delay to the boottime. I don't want to arque about the goal of this function but I would love to have the ability to disable it as it always gets turned on my system because I have CONFIG_USB_STORAGE=y in my kernel config. This patch will add a noslowusb option which can be passed to the init script from the kernel boot command line. For example: kernel /kernel-genkernel-x86_64-2.6.38-gentoo root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda2 udev video=uvesafb:ywrap,mtrr:1,1280x800-32@60 splash=verbose,theme:livecd-10 quiet console=tty1 dolvm nodetect noslowusb Any feedback is appreciated.
To be sure: would the machine boot just as fine with all USB drive disconnected?
(In reply to comment #1) > To be sure: would the machine boot just as fine with all USB drive > disconnected? What do you mean? It boots just fine with and without slowusb option, except it takes longer with slowusb. Anyway, I have no USB drives connected at all except the multi-memory card reader which is built-in in my monitor, although there is no memory card in it during boottime. See lsusb below: Bus 008 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120 for Business Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 018: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader Bus 001 Device 017: ID 0424:2602 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 016: ID 0424:2512 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 009: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler / Genius NetScroll 120 Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub If you need anything else, just le me know.
(In reply to comment #2) > Anyway, I have no USB drives connected at all except the multi-memory card > reader which is built-in in my monitor, although there is no memory card in it > during boottime. That's what I wanted to know. Thanks. Can you show the output of # /bin/ls -l /sys/bus/usb/drivers/usb-storage please?
(In reply to comment #3) > (In reply to comment #2) > > Anyway, I have no USB drives connected at all except the multi-memory card > > reader which is built-in in my monitor, although there is no memory card in it > > during boottime. > > That's what I wanted to know. Thanks. > > Can you show the output of > > # /bin/ls -l /sys/bus/usb/drivers/usb-storage > > please? Here you are: lrwxrwxrwx 1 root root 0 márc 21 19.50 1-2.1.1:1.0 -> ../../../../devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.1/1-2.1.1/1-2.1.1:1.0 --w------- 1 root root 4096 márc 21 19.50 bind lrwxrwxrwx 1 root root 0 márc 21 19.50 module -> ../../../../module/usb_storage --w------- 1 root root 4096 márc 21 19.50 new_id --w------- 1 root root 4096 márc 21 19.50 remove_id --w------- 1 root root 4096 márc 21 19.50 uevent --w------- 1 root root 4096 márc 21 19.50 unbind I am attaching an emerge --info output as well, in case you'd need it.
Created attachment 266757 [details] emerge --info
I do say I must question the reason why we pause 10s if there is a usb-storage unit connected to the computer even when we do not want to boot from it. Is there a reason why people needing to mount something usb in the initramfs cannot themselves add slowusb to grub/syslinux, just like people needing lvm or mdadm in the initramfs needs dolvm or domdadm? 10 seconds is a long time waiting just because you forgot to disconnect your USB-stick/USB-harddrive before shutting down/rebooting.
Agreed. By removing the scanning of /sys/bus/usb/drivers/usb-storage we may break existing setups on upgrade, though. Any ideas how we could smooth that transition?
People want things working out of the box, please don't take the shortcut of dropping a feature just because the logic that should be implemented is out of your current coding abilities. To me, same thing would apply (when possible) to all other do-something cmdline options. Back on topic: Instead, Write a patch that looks for the boot device among those exposed by sysfs and get (if found) the subsystem name on where the device is attached. If it matches usb-storage, then apply the slow usb, since 70% of usb-storage hardware would require some time to settle anyway. At the same time, make possible to disable the feature, by providing "noslowusb" or something along this line.
(In reply to comment #8) > People want things working out of the box, please don't take the shortcut of > dropping a feature just because the logic that should be implemented is out of > your current coding abilities. > To me, same thing would apply (when possible) to all other do-something cmdline > options. > I was not really suggesting dropping that feature, I was more interested in if there was any other reason for those pauses more then if you have root-on-usb or need a keyfile from usb or have swap/resume on usb or something similar. > Back on topic: Instead, Write a patch that looks for the boot device among > those exposed by sysfs and get (if found) the subsystem name on where the > device is attached. If it matches usb-storage, then apply the slow usb, since > 70% of usb-storage hardware would require some time to settle anyway. > At the same time, make possible to disable the feature, by providing > "noslowusb" or something along this line. I suggest a variant of this: we do as we do now minus that "sleep 10". Then before every option that takes a device-node as argument we run "checkdevice <device-node>" which checks if the device-node exists and if not if it is a usb-device, and if needed waiting until this node becomes available or 10s, whichever happens first. This way we can extend checkdevice if there will ever be a need of something other then usb-devices needing the delay. Any apparent flaws, or should I try implementing?
(In reply to comment #8) > Back on topic: Instead, Write a patch that looks for the boot device among > those exposed by sysfs and get (if found) the subsystem name on where the > device is attached. I found one problem here. We support stuff like "real_root=UUID=<...>", however I cannot find a way of getting this information out of sysfs (probably because it belongs to the filesystem, and the filesystem info is not available until the device is ready). So I propose a change in my initial suggestion, namely check if device-node/Label/UUID exists, and if not look for the existence of DO_slowusb. If DO_slowusb exists the function prints a message why it waits, then it enters a loop where it during 10 second checks once every second if the device may have appeared. All this skipped with noslowusb.
Created attachment 266839 [details, diff] 0001-Fix-handling-of-doslowusb-noslowusb.patch This patch is tested on my system. Without usb-stick plugged in, no pause. With usb-stick plugged in, pause. With usb-stick plugged in and noslowusb, no pause. We really should finetune so we do not wait 10 seconds every time, but only if the device in question is not found. But that is a feature we may add later.
Please also keep in mind that the "slowusb" thing is more critical than other similar (for eg: dodmraid, etc) because it is used on LiveCDs-alike media (CD/DVD usb readers, usb flash drives with a .iso file dumped). So, we must be close to paranoid there. A boot failure would make our LiveCD a paperweight.
(In reply to comment #12) > Please also keep in mind that the "slowusb" thing is more critical than other > similar (for eg: dodmraid, etc) because it is used on LiveCDs-alike media > (CD/DVD usb readers, usb flash drives with a .iso file dumped). So, we must be > close to paranoid there. A boot failure would make our LiveCD a paperweight. We use slowUSB for the LiveCD to, so it is not only used when we have a a need for usb-storage? Maybe time to rename it to slow-media...:-P
(In reply to comment #12) > Please also keep in mind that the "slowusb" thing is more critical than other > similar (for eg: dodmraid, etc) because it is used on LiveCDs-alike media > (CD/DVD usb readers, usb flash drives with a .iso file dumped). So, we must be > close to paranoid there. A boot failure would make our LiveCD a paperweight. Now that I re-read this, the examples you give are for usb-attached storage units only. is there any other use for slowusb that the "setup_slowusb" does not already detect? Because my patch sets DO_slowusb for every case "setup_slowusb" did before as long as noslowusb is passed.
(In reply to comment #11) > Created attachment 266839 [details, diff] > 0001-Fix-handling-of-doslowusb-noslowusb.patch > > This patch is tested on my system. Without usb-stick plugged in, no pause. With > usb-stick plugged in, pause. With usb-stick plugged in and noslowusb, no pause. > We really should finetune so we do not wait 10 seconds every time, but only if > the device in question is not found. But that is a feature we may add later. Looks fine for me. I will test is as soon as I can.
(In reply to comment #15) > (In reply to comment #11) > > Created attachment 266839 [details, diff] > > 0001-Fix-handling-of-doslowusb-noslowusb.patch > > > > This patch is tested on my system. Without usb-stick plugged in, no pause. With > > usb-stick plugged in, pause. With usb-stick plugged in and noslowusb, no pause. > > We really should finetune so we do not wait 10 seconds every time, but only if > > the device in question is not found. But that is a feature we may add later. > > Looks fine for me. I will test is as soon as I can. It's okay to me.
Peter's patch in Git. http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=5a33ee4b485a902051beeece531d1e70b1fa73c0 Closing on next release.
Fixed in genkernel 3.4.16, closing.
