On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin <m...@freebsd.org> wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as hz value permits, while still be able to
aggregate events and generating minimum of interrupts.
Also this version modifies system load average calculation to fix some
cases existing in HEAD and 9 branches, that could be fixed with new
direct callout functionality.
http://people.freebsd.org/~mav/calloutng_12_17.patch
With this patch (and the previous one, I didn't test the others)
my mouse cursor is occasionally not reacting for short amounts of
time (less than a second, but long enough to be noticeable).
Every now and then the window manager (i3-wm) changes window focus
which could be explained by either phantom keyboard or mouse input,
or terminal lines are marked as if the cursor was moved with the
left button pressed.
The problems happen a couple of times per hour but I haven't
been able to intentionally reproduce them. They only seem to
occur while I'm moving the cursor, but of course I wouldn't
otherwise notice a unresponsive cursor anyway.
While the cursor is unresponsive, keyboard input and the rest
of the system works as expected as far as I can tell.
If I set debug.psm.loglevel=4 I get a "psm0: lost interrupt?"
message once per second when not moving the mouse, however that
also happens without the patch and thus might be unrelated.
I'm using moused.
Could you try to revert part of the patch, related to dev/atkbdc? I am
not strong in details of that hardware, but in comments there mention
that they are related. May be lost keyboard interrupts (which polling
rate was increased to 1 second) cause PS/2 mouse delays.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
