[PATCH] Fix for USB media not found at boot
scottl at samsco.org
Sat Oct 3 08:20:04 UTC 2009
On Oct 3, 2009, at 1:53 AM, Hans Petter Selasky wrote:
> On Friday 02 October 2009 23:11:21 Scott Long wrote:
>> I have a candidate patch to fix the problem with USB boot media not
>> 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
>> works for you.
> Your patch looks OK. Some checkpoints however:
> Does your patch work if ehci/ohci/uhci is kldloaded after system
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
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.
More information about the freebsd-current