Re: [RFC/RFT] calloutng

On 20.12.2012 15:26, Fabian Keil wrote:
> 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.

Thank you for the report. If it will be fine. you can try to reapply 
that part of the patch, just changing line:
callout_reset_flags(&sc->callout, hz, atkbdtimeout, dev, C_PRELSET(0));
to the:
callout_reset_flags(&sc->callout, hz/10, atkbdtimeout, dev, C_PRELSET(0));

It should about to restore original polling interval, but still make it 
more flexible then original.

-- 
Alexander Motin