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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
