Re: Slow boot due perhaps to locks in mouse and platform system

["Phil Endecott" <phil_dubhl_endecott@chezphil.org>]

Phil Endecott wrote:
> Arjan van de Ven wrote:
>> On Wed, 15 Oct 2008 00:17:29 +0100
>> "Phil Endecott" <phil_dubhl_endecott@chezphil.org> wrote:
>>
>>> 
>>> 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.