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

Reply via email to