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. MortenReceived 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