Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>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? > >Kazu Ok, here is an experimental patch. It tries to implement the above scheme. http://people.freebsd.org/~yokota/psm-out-of-sync.diff.gz It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds in this patch). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. Watch out for the followin messages: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" Please test if you are suffering from the out-of-sync errors! Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote: > >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. > > We are not running getty on the mouse port. So, we don't need > to worry about this. I wasn't clear, I guess. What I meant was that you might want to rate throttle the mouse resets, in case the mouse driver ends up getting into one of those loops that people are afraid it might. If the moust can only reset once a second, you can't get stuck in a tight loop resetting the mouse. If it can only do it 10 times before it backs off a minute, then this will prevent someone grabbing the mouse and wiggling it to make it work breaking it forever. In other words, you control the rate at which you reset the mouse. This keeps it from being a problem, even if the new code breaks horribly. The worst that can happen is that you reset once a second (or whatever you tune the timer for), and then only do that 10 times every two minutes (or whatever you set the second timer for). So the idea is to make it behave like init behaves with getty: init-> getty psm0-> mouse reset Does this make more sense? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>> If disable/enable sequence, which is lot simpler and takes considrably >> less time, can correct the sync problem, I think it will be better. > >It looks to me as if the mouse is automatically enabled by >default after a reset? No, the mouse is disabled after reset. We need to explicitly enable it. This will be done during our re-initialization sequence. >If this is true, then doing a disable >then a reset will result in the next mouse packet coming in >on a correct boundary. It makes the reset a tiny bit more >complicated, but makes the results more deterministic. Yes. We can expect we get the packet boundary right after the reset command followed by the enable command. And that's why we shall reset the "error counter" to zero after reset/reinitialize. >I don't know what to tell you, if the keyboard goes away during >the reset process: it seems counter-intuitive, and it means you >can't use keyboard shortcuts to get to a mouse "control panel" >to fix the problem manually... 8-(. The keyboard won't be inaccessible during the mouse reset sequence. Its data won't be lost (in theory). But, you just feel the keyboard is not responding quickly... Anyway, I shall make a patch and we test it to see how it behaves... >I think if that's unavoidable, a simple comment to that effect >in the code would save you loads of grief later. > >-- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>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). Don't worry. I was going to do this :-) >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. Yes, we need to be careful about this. As the AT keyboard data and the PS/2 mouse data must read from the same keyboard controller port on the motherboard, we want to remove the mouse data from the keyboard controller port as soon as it arrives, otherwise the keyboard data will be blocked. >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. We are not running getty on the mouse port. So, we don't need to worry about this. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote:
> While we are carrying out the reset/initialization sequence, the mouse
> pointer will be frozen on the screen. The keyboard input may not
> respond in a timely fasion because the PS/2 mouse and the AT keyboard
> share the same I/O port. Then, I suspect our user may feel uneasy and
> think the entire FreeBSD is frozen...
The keyboard freeze seems problematic; can you decouple the
reset vs. the reset complete notification, by keeping a flag
("currently resetting") that the interrupt handler can look
at? This kind of goes with your next observation:
> What do you think the average user will do in such situation? It is
> quite likely that s/he will wiggle the mouse (rather frantically?) to
> see if the mouse is dead, won't he? I am not sure our initialization
> sequence is robust enough to not be disturbed by this.
Yes, wiggling the mouse to make it work is the natural thing
for someone to do...
> If disable/enable sequence, which is lot simpler and takes considrably
> less time, can correct the sync problem, I think it will be better.
It looks to me as if the mouse is automatically enabled by
default after a reset? If this is true, then doing a disable
then a reset will result in the next mouse packet coming in
on a correct boundary. It makes the reset a tiny bit more
complicated, but makes the results more deterministic.
I don't know what to tell you, if the keyboard goes away during
the reset process: it seems counter-intuitive, and it means you
can't use keyboard shortcuts to get to a mouse "control panel"
to fix the problem manually... 8-(.
I think if that's unavoidable, a simple comment to that effect
in the code would save you loads of grief later.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
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
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
> > 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. We don't need to worry about such situation. As soon as we send the disable command to the mouse, it will stop sending data packet. So, we are not going to send another disable command before it completes, because we won't get another data byte which looks "out-of-sync" before the enable command. If we get "out-of-sync" data bytes after we send the enable command, there are two possible reasons: a) Disable/enable didn't work. The data packet is in wrong format. We need reset/re-initialization. b) The disable command was sent while the mouse was sending a data packet, and the mouse tried to send the remaining part of the packet after the enable command. This shouldn't happen for the well-behaved mouse. Logitech's technical document states that if the mouse is disabled in the middle of a data packet, the unsent part of the packet will be discarded, and the mouse will start sending a new packet after the next enable command. But, I would be rather cautious about this; there are so many wacky mice out there; they may not be as good as Logitech's :-) So, I would rather wait few more times after disable/enable and before reset/re-initialization. >What happens if you set your KVM into cyclical mode? Does it force a >mouse interrupt when it switches from machine to machine? It depends on the KVM's firmware, doesn't it? Both the mouse and the host computer do not know they are connected to a KVM. If the mouse is somehow forced by the KVM to send a data packet whenever you switch between machines, we will see the mouse interrupt. Otherwise I cannot imagine the mouse voluntarily sending data packets when you switch machines. You see, the root of the problem is here. The KVM tries to be transparent to the host computers and the mouse (and the keyboard) and there is no way for the host computer and mouse to know that it is connected to a KVM and to know exactly when the user switch between the machines. Kazu > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>Does it make sense to have a timeout (or perhaps just timestamps) in the >driver, so that after some period of inactivity, you "know" that the >next byte from the moust is the first of a multi-byte message? > >louie I haven't thought about this. Yes, it may be possible. But, when the mouse is moving rather fast, we may get continues flow of packets and this technic may not work... I will invesitgate and experiment with your idea. Thanks. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>: Too complicated? > >I like this idea. It will allow mechanical KVM switches to "work" >better than they do now (which is to say, not much at all). I also >have one KVM switch that hits the out-of-sync problem when its power >fails. Unfortunately, it has a horrible user interface: The power >button and the switch console buttons are next to each other. > >I assume that initializing the mouse is somewhat expensive and >something that you wish to avoid? Yes. Reset and re-initialization involves sending a series of commands to the mouse. It will take time. In addition, after we send the reset command to the mouse, we have to wait until it returns a status code. Loctech's technical document states that it will be between 300 and 500 msec. But, I know, from our users' reports in the past, that some mice take a lot longer time than this before sending the status. Moreover, if we have a KVM between the mouse and the FreeBSD box, there may be additional delay (I also had a report on such KVM). So, the current psm code will wait up to 2 seconds in the worst case. There have been some cases where I had to advise users to set longer wait time via the kernel compile option PSM_RESETDELAY and PSM_MAXWAIT (see the man page for psm(4)) for some mice and KVM. While we are carrying out the reset/initialization sequence, the mouse pointer will be frozen on the screen. The keyboard input may not respond in a timely fasion because the PS/2 mouse and the AT keyboard share the same I/O port. Then, I suspect our user may feel uneasy and think the entire FreeBSD is frozen... What do you think the average user will do in such situation? It is quite likely that s/he will wiggle the mouse (rather frantically?) to see if the mouse is dead, won't he? I am not sure our initialization sequence is robust enough to not be disturbed by this. If disable/enable sequence, which is lot simpler and takes considrably less time, can correct the sync problem, I think it will be better. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Does it make sense to have a timeout (or perhaps just timestamps) in the driver, so that after some period of inactivity, you "know" that the next byte from the moust is the first of a multi-byte message? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
In message <[EMAIL PROTECTED]> 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? I like this idea. It will allow mechanical KVM switches to "work" better than they do now (which is to say, not much at all). I also have one KVM switch that hits the out-of-sync problem when its power fails. Unfortunately, it has a horrible user interface: The power button and the switch console buttons are next to each other. I assume that initializing the mouse is somewhat expensive and something that you wish to avoid? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
