Date: Wed, 15 Aug 2001 23:43:40 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Cc: freebsd-current@FreeBSD.ORG Subject: Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach) Message-ID: <3B7B6B9C.3866D87C@mindspring.com> References: <200108150924.SAA06230@zodiac.mech.utsunomiya-u.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Kazutaka YOKOTA wrote: > 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? Nope; looks right, actually. You might want to go further, though, if you are concerned about relinitializtion time, and repeats (someone suggested that resetting the mouse might result in interrupts, which could result in an "out of sync", which could result in a reset, ...). o If you are going to reset, disable and drain the input queue before you do it; this will make the mouse lose buffered data, making a partial send with a disable in the middle not resume (e.g. it is no longer an issue for you). o Because reinitialize can take a relatively _long_ time, split the "reset" and "reset" complete operations across a tsleep() (or msleep) so that the rest of the system doesn't stall (I think the number I saw was 2 seconds?!?). If you get an interrupt on the reset complete because it always sends data, then that's not a real issue: the tsleep becomes a guarantee, rather than a requirement. o You may want to implement a rate throttling mechanism; init will stop respawning a getty on a port, if it is exiting too rapidly, while inetd will rate limit the number of connection attempts a second, as well. I guess you probably don't want to disable it, ala init, but limiting the number of reinitialize/resets per interval would address the "too expensive" and "reset causes additional resync errors" cases. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B7B6B9C.3866D87C>