Re: [PATCH RFC] USB: Add HCD fastboot

[Emanoil Kotsev]

Hi,

I'm using usb drive to boot from. I also use USB mouse and USB keyboard.

Indeed I have to put a delay in the init script in the initrd to delay and   give time for the initialization. I found out by testing that this delay should be >5sec.

I have tried compiling all the usb modules into the kernel, but this doesn't help much, now after following this discussion it might be related.

With 2.6.20 I can use the keyboard. With the same init script in 2.6.24 and 2.6.26 it is not working, but I really coudn't find time to investigate, because as Alan sais there is really not too much to do with keyboard and mouse during the bootprocess unless as I do I unlock crypted partitions.

Don't know if this information is somehow useful for you, but hope so.

I could also look at why the keyboard is not working in boot. Let me know

regards


--- On Wed, 8/6/08, Simon Arlott <simon@xxxxxxxxxxx> wrote:

> From: Simon Arlott <simon@xxxxxxxxxxx>
> Subject: Re: [PATCH RFC] USB: Add HCD fastboot
> To: "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx>
> Cc: "Rene Herman" <rene.herman@xxxxxxxxxxxx>, "Arjan van de Ven" <arjan@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, mingo@xxxxxxx, "Daniel Walker" <dwalker@xxxxxxxxxx>, "USB list" <linux-usb@xxxxxxxxxxxxxxx>, "Greg Kroah-Hartman" <gregkh@xxxxxxx>
> Date: Wednesday, August 6, 2008, 11:49 PM
> On 06/08/08 21:26, Alan Stern wrote:
> > On Wed, 6 Aug 2008, Simon Arlott wrote:
> > 
> >> No, by adding a 5 second delay you're
> intending for the device driver initcalls 
> >> to complete within that 5 seconds. If they take
> too long then the last one 
> >> blocks everything (I realise that's
> ridiculous, these initcalls take <1ms when 
> >> there are no devices yet). The best way to do is
> to make the driver initcalls 
> >> before the host ones, like you suggested.
> > 
> > Doing the HCD initcalls last certainly ought to work.
> 
> Right - so then all that's needed is to move usb/
> before most other things that 
> take a while to init, and it has some time to initialise
> usb devices in the 
> background.
> 
> >> > "it'll still have to wait..." 
> If by "it" you mean the initcall
> >> > thread, you're wrong.  If by
> "it" you mean the user, you still aren't
> >> > necessarily correct; the user can do plenty
> of other things while
> >> > waiting for USB devices to initialize.
> >> 
> >> Assuming userspace doesn't wait for all
> devices to settle and appear in /dev etc. 
> >> before continuing.
> > 
> > Whatever that involves...  /dev never truly settles;
> it's always 
> > possible to plug in a new device or remove an old one.
> 
> Yes... I'm not sure how that part would work.
> 
> >> > I suppose you could make the hub_thread delay
> time a module parameter 
> >> > for usbcore, defaulting to 0.  Then it could
> be set by just the people 
> >> > who want to use it -- many (most?) people
> keep their drivers in 
> >> > modules, and it wouldn't do them any
> good.
> >> 
> >> It really needs to have hcd initcalls done very
> early so that device init 
> > 
> > Please stop using the word "it" with no
> antecedent!  Do you mean "we"?
> 
> Yes. I'll try to avoid doing that.
> 
> >> has the rest of the (kernel and userspace) boot
> process to complete in the 
> >> background. This is negated by having device
> drivers initialised immediately 
> >> afterwards. Re-ordering initcalls and doing more
> of the init process 
> >> asynchronously is likely to expose bugs and cause
> inconsistent device order 
> >> on some systems, so if the makefile mess could be
> reduced then it can be a 
> >> Kconfig option.
> > 
> > So what exactly do you recommend?
> 
> I'm not an expert on what can be done with the Makefile
> process, perhaps there's 
> an easier way to move things around based on a config
> option. If host init is 
> moved before device init for everyone, wouldn't there
> be too many side effects?
> 
> I've not tried to use usb-storage as root but
> presumably that works. If that 
> already uses a hack of making the kernel wait X seconds
> before trying to mount 
> root then it'll still work.
> 
> >> How many people have *all* their USB components
> (hcd, drivers) as modules?
> > 
> > All the major distributions do, as far as I know.  (I
> haven't actually 
> > checked them all to be certain.)
> > 
> >> What do they do with their USB keyboards in the
> period between init and module 
> >> load?
> > 
> > Probably nothing.  What do you do on your keyboard
> while waiting for
> > system initialization to complete?
> 
> Lack of a keyboard makes it impossible to do anything if
> the module fails to 
> load... as I understand it when the HCD init runs, any BIOS
> emulation stops?
> Although if HCD is a module too...
> 
> >> If even one device driver and the hcd is compiled
> in, they'd need to 
> >> wait for every USB device to finish init before
> the usbhid probe could complete.
> > 
> > What if usbhid is the one device driver that is
> compiled in?  :-)
> 
> That was the situation I was thinking of - surely that
> would be compiled in 
> if the HCDs were?
> 
> -- 
> Simon Arlott
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html


      
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/