Date: Fri, 07 Nov 2003 02:27:39 +0100 From: Morten Johansen <mail@morten-johansen.net> To: Scott Long <scottl@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: the PS/2 mouse problem Message-ID: <3FAAF50B.9030105@morten-johansen.net> In-Reply-To: <3FAA2CEB.6000403@morten-johansen.net> References: <3FA966B2.9040704@morten-johansen.net> <20031105202947.A43448@pooker.samsco.home> <3FAA2CEB.6000403@morten-johansen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FAAF50B.9030105>