Re: the PS/2 mouse problem

From: Morten Johansen <mail_at_morten-johansen.net>
Date: Fri, 07 Nov 2003 02:27:39 +0100
Morten Johansen wrote:
> Scott Long wrote:
> 
>> One thought that I had was to make psmintr() be INTR_FAST.  I need to
>> stare at the code some more to fully understand it, but it looks like it
>> wouldn't be all that hard to do.  Basically just use the interrupt 
>> handler
>> to pull all of the data out of the hardware and into a ring buffer in
>> memory, and then a fast taskqueue to process that ring buffer.  It would
>> at least answer the question of whether the observed problems are due to
>> ithread latency.  And if done right, no locks would be needed in
>> psmintr().
>>
>> Scott
> 
> 
> 
> I can reproduce the problem consistently on my machine, by moving the 
> mouse around, while executing e.g this command in a xterm:
> 
> dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
> 
> when the sync'ing sets in the mouse attacks.
> It is very likely due to interrupt latency.
> 
> I'd be happy to test any clever patches.
> 
> 
>   Morten
> 
> 


Wow. You are completly right!
By using a MTX_SPIN mutex instead, and marking the interrupt handler 
INTR_MPSAFE | INTR_FAST, my problem goes away.
I am no longer able to reproduce the mouse attack.
I have not noticed any side-effects of this. Could there be any?
I will file a PR with an updated patch, unless you think it's a better 
idea to rearrange the driver.
Probably the locking could be done better anyway.


   Morten
Received on Thu Nov 06 2003 - 16:27:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:28 UTC