On Fri, Apr 19, 2013 at 5:49 PM, Jiří Zárevúcky <[email protected]> wrote: >>>> [...] >>> >>> 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). >> >> 1000Hz is high above ps2 limit (200Hz), unless qemu throttles it down. >> every event is 4 interrupt messages, 1 ps2 driver read msg and 1 or 2 >> event reports. >> >> 6000-7000 messages per second (not counting console and other stuff) >> just to move a mouse seems pretty high >> > > Unfortunately, I don't have any other mouse to check with. > The question is, do we try to fix this, or at least make it safe (even > if not really usable)? Or do we just assume it's a qemu bug and leave > it?
The situation is definitely pathological, but the crash should be fixed. It looks like a missing malloc check somewhere. IMO the best approach would be to just drop the interrupt if the handling fibril cannot be created, ignoring the resulting breakage. > >>> >>>> 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. >> >> Do you use KVM accel.? > > At the moment I have no idea. > >> have you tried tester pingpong? >> it should give an idea about ipc perf limits. >> > > 6490 rt/s definitely not kvm then. kvm on 2.5Ghz i5 gives 100k rt/s and even atom 1.6 (hw) reaches 33k rt/s. The mouse is just too fast for your machine :) > >> Can you try using USB mouse (either qemu emulation or pipe it directly), >> the results should be interesting? >> > > So I tried emulated USB mouse. > Again, no other mouse to compare with, but although it doesn't move > all that smoothly, it works quite well and is nicely responsive. good to hear. if you feel like doing more testing I'd like to see whether helenos can handle the device directly. Jan > > -- Jirka Z. > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
