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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
