Re: [RFC/RFT] calloutng

From: Fabian Keil <freebsd-listen_at_fabiankeil.de>
Date: Thu, 20 Dec 2012 14:26:00 +0100
Alexander Motin <mav_at_FreeBSD.org> wrote:

> On 20.12.2012 12:56, Fabian Keil wrote:
> > Alexander Motin <mav_at_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.
 
I reverted the changes to sys/dev/atkbdc/* about an hour ago
and so far it's looking good. I'll report back tomorrow after
some more testing.

Fabian

Received on Thu Dec 20 2012 - 13:20:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC