This is for the 2.6.34 kernel. Linus reduced the settling time when detecting USB devices from 5 to 1 second.
This bothers me because there have been some situations in the past where considerable settling time was required. That may have been for USB1 interfaces. Is Linus basically saying that USB1 is no longer being supported?
I don't know, but I thought it wise to flag this patch, so if we encounter any trouble with USB on older hardware, then we will be reminded what the cause might be and the cure.
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index e9f9954..bbeeb92 100644 (file)
@@ -78,7 +78,7 @@ MODULE_AUTHOR("Matthew Dharm <email@example.com>");
MODULE_DESCRIPTION("USB Mass Storage driver for Linux");
-static unsigned int delay_use = 5;
+static unsigned int delay_use = 1;
module_param(delay_use, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(delay_use, "seconds to delay before using a new device");
Comments:Posted on 14 Jul 2010, 15:29 by Sage
Fate of USB 1
It would be extremely helpful if someone respected in the IT community make it abundantly clearly to whoever that dropping support for USB 1 is and will remain utterly unacceptable. Far too much USB 1 kit around in perfect working order, we don't want more landfill.
Posted on 14 Jul 2010, 20:13 by JustGreg
1 second is short
I have a USB hard drive attach to my system (with hard disk) for experiments and testing. Lucid takes from 3 to 4 seconds for the usbstorage module to be load. I suspect that 1 second settling time will cause a problem.
Sage, the patch is not dropping support for USB 1.0 or 1.1 services. Older devices will be detected if they respond quickly enough.
Posted on 14 Jul 2010, 22:18 by technosaurus
kernel debugging process
There have been quite a few process speedups (some ~80-90%) that may have made the 5s time unnecessarily long. I like that Linus went straight to 1s so that any problems get identified more quickly in development rather than slowly scaling it back over several releases and delaying the pleasures of a fast boot.
... Does anyone else have a Dectop (usb1 only) that they plan on testing?
Posted on 15 Jul 2010, 2:32 by linuxcbon
Posted on 9 Jul 2011, 11:34 by 01micko
usb kernel issues
I have compiled 220.127.116.11 lts kernel with view of using it in spup. I have added iguleder's name patch so that it appears as 2.6.35. It works great except that the usb-storage patch (I got yours for 18.104.22.168) crashes the kernel even on a boot from CD. I wouldn't have a clue why. It boots without the patch on my lowly eee-701 via USB stick fine.(same with 22.214.171.124 too). It won't boot on a compaq laptop I have from 2008, 1.8gig celeron, 1gig RAM.
Since the usb-storage patch fails do you think the patch referred to in the OP would be of any use? Note that all aufs patches apply cleanly and other patches including vortex (though I can't test that it works).
Posted on 9 Jul 2011, 11:41 by 01micko
Forgot to mention.. if I assign the pmedia value of "sdb1" (of course this is machine specific) then I can boot on the compaq. I believe pemasu has the same issue using 126.96.36.199 in his lupu variants.
Posted on 10 Jul 2011, 8:27 by 01micko
Well I backed out the Linus "1 second" patch (reverted to 5), this time in 188.8.131.52.. some improvement ..I'm 2 out of 3 with successful booting from usb, the compaq lappy is still the trouble maker and it's fairly new. I have an old compaq evo p4 and it had no trouble. The compaq lappy boots ok with pmedia=sdc1 (it has 2 partitions on HD), with the "pausing" message and a fair bit of a wait (10 seconds?). Anyway, backing out the linus patch half works so next I'll look at init solutions.
Posted on 10 Jul 2011, 8:55 by Ted dog
USB crashes AntiMacPup
Echo, echo what prior poster posted. That is a deal breaker on MacTel since everything acts as USB. It is somewhere bombing in .init sript in most puppy versions in wide use. Lupu and lots of spin offs not using T2 have the problem. Quirky after 112 work (140,&142) as does FatPup (works great).
Posted on 10 Jul 2011, 17:45 by BarryK
Now compiling 184.108.40.206
I'll see what I can do. Right now I am compiling 220.127.116.11, without the usb-patch and with usb drivers builtin (not as modules) -- this includes usbcore, ehci-hcd, uhci-hcd, ohci-hcd and usb-storage.
I have modified the 'init' script to work with these drivers builtin. However, the settling time for usb devices to become available still has to be resolved, but I am hoping that having the drivers builtin might help.
Posted on 11 Jul 2011, 16:46 by pemasu
If you get working and usb booting kernel made of the 18.104.22.168, could you provide the patched source.
I am keenly interested to test it in the puppy build using your latest woof.