moves in a
very
choppy motion (painfully slow).
Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008).
Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1).
Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008).
Oct 1 09:46:17 squirm kernel: psmintr: discard a by
hoppy motion (painfully slow).
Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008).
Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1).
Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008).
Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2).
Oct 1 09:
tter of seconds, other times I have left if for about 20+mins.
> Interestingly enough, pinging the laptop from another computer will always unfreeze
> it immediately.
>
> As this occurs the following is printed to the console:
>
> Mar 27 11:23:57 opal kernel: psmintr: out of sync
lways unfreeze it immediately.
As this occurs the following is printed to the console:
Mar 27 11:23:57 opal kernel: psmintr: out of sync (00c0 != ).
Mar 27 11:23:58 opal kernel: psmintr: discard a byte (1).
The above appears for each freeze, and every now and again this appears:
Mar 27 11:23:57
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
conds 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: d
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 p
>> 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
enab
>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 d
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 un
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
>
> > 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
>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 m
>: 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
>
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
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" i
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
Ok, I am back.
There are so many issues to be explained and discussed. I will tackle
them one by one
- Flags 0x8000 for psm and "out-of-sync" error
As many people want to make it default, and my initial intent to make
it an option didn't work out well as a hindsight, we had better make
it
Ok, folks. This is a test patch for the psm driver. I would like you
to do some test for me.
This is NOT the fix for the infamous "psmintr out of sync" message,
but is a test patch to see how things are on your machines. The patch
is for both CURRENT and STABLE.
Please apply th
19 matches
Mail list logo
