Date: Sat, 3 Oct 2009 02:19:57 -0600 From: Scott Long <scottl@samsco.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Fix for USB media not found at boot Message-ID: <3307DF7C-2FEF-468B-85F4-095BB7E3EE8F@samsco.org> In-Reply-To: <200910030953.17359.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910030953.17359.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3307DF7C-2FEF-468B-85F4-095BB7E3EE8F>