On 19 April 2013 16:42, Ján Veselý <[email protected]> wrote:
> On Fri, Apr 19, 2013 at 2:27 PM, Jiří Zárevúcky
> <[email protected]> wrote:
>> On 19 April 2013 13:04, Jiří Zárevúcky <[email protected]> wrote:
>>>>>
>>>>> PS: The reason I want to disable compositor is because it still locks
>>>>> up for me (qemu i386 with or without kvm, updated Arch Linux).
>>>>>
>>>>> -- Jirka Z.
>>>>
>>>> Does it lock up on any input or just mouse input? Is it possible to
>>>> move windows with Alt+WSAD? If it is mouse exclusive, does it lock up
>>>> on mouse click, mouse move or mouse move with pressed button? Does it
>>>> happen even on the desktop background or just when you try to interact
>>>> with an active element?
>>>>
>>>> Petr
>>>>
>>>
>>> I can use keyboard, as long as I don't move the mouse. When I move the
>>> cursor just a tiny bit (no matter where), all inputs freeze. I am
>>> trying to find the cause now. Any hints on where to focus?
>>>
>>
>> So, I've learned that the problem is apparently in the i8042 driver itself.
>> The interrupt handler is not guaranteed to finish, ever. Nor is there
>> a bound on concurrently spawned handlers. With continuous mouse
>> movement, driver is flooded with requests, handlers are spawned but
>> never finished. Eventually, after a while, i8042 task crashes from
>> memory exhaustion.
>
> If this is the case than you have uncovered a symptom not the real cause.
> The i8042 buffer size is limited to 12 bytes, that means 3 or 4 ps2 messages.
> It expects someone (xtkbd or ps2mouse) to read the data.
> so the real question is why they don't do this.
>

The real cause is simply that the pipeline is too slow. The messages
get read, but as soon as some of them are not read in a timely
fashion, performace degrades quickly because of all the allocations.

I do not know how qemu deals with hw emulation, but I suspect this
problem only affected me because I own a gaming mouse (1000Hz update
rate).

> Don't get me wrong, I agree that i8042 could be more robust, but that would
> only change crash to series of "data dropped" messages. Moreover,
> you need to be careful about dropping data, if you drop single bytes
> you break ps2 protocol, and the result is unusable mouse (or keyboard).
> That's why the buffer blocks.
>

Dropping messages doesn't help much, I tried it. It prevents crash,
but doesn't allow the mouse to move fast. I think what we need is to
change how async framework processes notifications.

_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Reply via email to