On 21 April 2013 16:29, Jiří Zárevúcky <[email protected]> wrote: > On 21 April 2013 15:52, Ján Veselý <[email protected]> wrote: >> There are two things to do: >> 1) fix fibril creation so that it won't kill the task if there is not >> enough memory. This will result in unusable mouse and probably >> stuck/ignored keys, but should prevent driver kill. >> >> 2) add single fibril interrupt handling mode to guarantee serial >> handling and hope that the added benefit of better performance is good >> enough to remedy your situation. If the performance is still not good, >> it will result in unusable mouse and stuck/ignored keys. >> >> Your setup is a nice test case so implementing 1) first might be a >> good idea. I'll try to have a look >> on both when I get some time. >> > > Without some kind of per-task resource limits, 1) will only help as > long as no task in the entire system happens to access late-reserved > pages. And there is still very little benefit in keeping a task that > consumes all memory and cpu to run for no purpose - it will be > permanently stuck anyway. > > 3) Maybe it would be better if the driver itself understood the > protocol and was able to combine the moves in-place instead of > buffering them needlessly. >
FYI, I managed to make the mouse actually usable and safe(r) to use, without changing the notification handling mechanism. To do so, I extended the CHARDEV protocol to allow reading large payloads through data_read (a useful thing in any case, since character devices are streams that can easily be buffered), and changed the buffers in i8042 to a larger size (a few kilobytes to be on the safe side). ps2mouse then simply reads a large buffer in one call and combines all the moves into a single message, instead of one message per move packet (other packets are processed as usual). These changes make it fast enough to deal even with my fast mouse and slow emulation. Note that the CHARDEV extension is really a big hack and ps2mouse changes are not complete (or nicely coded), so the attached diff is for illustration only, not for merging. Any suggestions on how to make this mergeable (especially the protocol part) are welcome. -- Jirka Z.
diff
Description: Binary data
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
