Morten Johansen wrote: > 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 > > > Great! By all means, please submit a PR and assign it to me. ScottReceived on Thu Nov 06 2003 - 22:09:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:28 UTC