Phil Endecott wrote:

Arjan van de Ven wrote:

quoted

On Wed, 15 Oct 2008 00:17:29 +0100
"Phil Endecott" [off-list ref] wrote:

quoted

It looks to me as if uhci holds some lock that 8250 needs before it
can complete.  Now those are both PCI drivers in the same way that
the last two that seemed to contend were both input drivers (touchpad
and speaker) [hmm, except that as Dmitry pointed out there's a
distinction between the platform bus and the serio bus].  Anyway, my
ignorant suspicion is that there's some lock related to the bus or
subsystem that they both need.  Maybe something in sysfs?

it does do this. And I know which lock... and I fixed it ;)
Just the patch for this is in Gregkh's tree since it's a change to the
device/sysfs layer and he wanted to carry it via that way.

I can dig that patch out if you want

Yes please!

Google eventually found this for me:
   http://thread.gmane.org/gmane.linux.usb.general/9923

I presume that this is what Arjan was referring to.  It causes the 
device-to-driver matching loop to not take the device lock unless the 
match function succeeds.  In my case, the need to take this look was 
preventing the pcspkr initialisation from terminating until the mouse 
initialisation was done, even though the mouse initialisation is in a 
different thread, because the pcspkr init wanted to lock the mouse to 
check if it was actually a speaker.

Fixing it has halved my boot time.


Phil.