From owner-freebsd-current Wed Aug 15 14:17:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id 60C4737B411 for ; Wed, 15 Aug 2001 14:17:51 -0700 (PDT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 76681 invoked by uid 1001); 15 Aug 2001 21:20:58 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.59322.424480.324816@zircon.zircon.seattle.wa.us> Date: Wed, 15 Aug 2001 14:20:58 -0700 To: freebsd-current@freebsd.org Subject: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach) In-Reply-To: <200108150924.SAA06230@zodiac.mech.utsunomiya-u.ac.jp> References: <200108150924.SAA06230@zodiac.mech.utsunomiya-u.ac.jp> X-Mailer: VM 6.92 under Emacs 20.7.1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kazutaka YOKOTA writes: > Anyway, I am now considering the following experiment. > > - We make the psm driver count the number of the "out-of-sync" errors. > - When the error is detected for the first time, the psm driver will > throw few data bytes (up to entire packet size) and see if it can > get back to sync. > - If the error still persists, the psm driver disable/enable the mouse > and see if it works. > - If the error still persists and the count goes up to N (10 or 20?), > the psm driver reset and reinitialize the mouse. The counter > is reset to zero. > > Too complicated? It sounds fine to me. I was thinking that if you are truly concerned about the amount of time that the disable/enable calls take, the way to solve that is a combination of counter and timer. Increment a counter when you take the disable/enable path to prevent recursive calls. Set a timer the first time through the pair of functions to get the basic timing down. Then, limit the calls to the pair of functions so that you never call them closer than 10x the time to complete the pair. (maybe 100x the time is better? It depends on how long the function pair actually takes to complete. Is it variable depending on MB or other factors?) I think that timing the calls is important to limit the possibility of calling the functions too often in case of pathological circumstances. This seems to be the overriding concern anyway. I have only seen the problem once since I enabled that flag. What happens if you set your KVM into cyclical mode? Does it force a mouse interrupt when it switches from machine to machine? I can imagine a KVM misbehaving during the automatic rotate mode to cause a real cascade of problems. On the other hand, if you put it in the rotate mode, you probably aren't touching the mouse, so it shouldn't cause problems. How difficult is it to keep some sort of timer value in the code? If it costs too much to get a timer, then a counter is probably sufficient. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message