the PS/2 mouse problem
mail at morten-johansen.net
Thu Nov 6 17:27:29 PST 2003
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
>> 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
> 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.
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.
More information about the freebsd-current