Re: [PATCH] Fix for USB media not found at boot

On Oct 3, 2009, at 1:53 AM, Hans Petter Selasky wrote:

> On Friday 02 October 2009 23:11:21 Scott Long wrote:
>> All,
>>
>> I have a candidate patch to fix the problem with USB boot media not  
>> being
>> found in time at boot, leading to the "mountroot" prompt instead of a
>> booting system.  Please apply both patches below and let me know if  
>> it
>> works for you.
>
> Hi,
>
> Your patch looks OK. Some checkpoints however:
>
> Does your patch work if ehci/ohci/uhci is kldloaded after system  
> startup?
>

That's a good question, I forgot to check that case.  It should,  
though, given how the config_intrhook API is designed to work.

> Does your patch work if CAM is not in the kernel?
>

The change has no dependence on CAM.

> I have a simple imporovement to your patch:
>
> I would just add a synchronously blocking call to the end of  
> "usb_bus_attach".
>

This isn't needed.  The config_intrhook system will sleep after all  
hooks have been launched, and will wakeup as needed.  There is no  
longer a race with CAM as CAM no longer uses the config_intrhook  
system, and is explicitly placed in order after it.

Unfortunately, my patch doesn't solve the problem.  It holds off the  
boot only while the root hub is explored.  Hubs below the root get  
queued back to the explore thread and enumerated after the root hub  
has signaled to disestablish the config hook, leading to devices  
further down the chain getting discovered late.  It's no better than  
the code that I deleted.  I'm thinking through how to solve this.   
Ideally, a refcount/semaphore is kept during discovery.  Every time a  
new hub is found, the semaphore is increased, the hub is reset/ 
configured, and control returns upwards until a config interrupt comes  
in.  Then we look at each port on the hub, probe/attach new devices,  
and then down the semaphore at the conclusion.  If one or more ports  
had hubs on them, then they would recurse this process.

I'm not familiar enough with USB to know if this is even possible.  I  
assume that a hub has to be reset before its ports can be probed, but  
I have no idea if there's a reliable way to know when the reset action  
has started and ended, other than to hope to get a config interrupt  
for one or more of the ports.  But if a hub is empty of child devices,  
will any interrupts be generated?  Maybe instead of relying on  
interrupts, we should just poll the ports for a period of time to see  
if they come alive.  Dunno.  I need to start reading specs.

Scott