> Ok, I can try to find out where the references come from. Please do.
> Right now what I am doing is to read from kbd byte by byte. I will change > it to read many bytes at once (as much as the internal buffer is), and then > process the local buffer first, before reading more. However, reading byte > by byte should also work I would think. Yes, it should. The only issue should be if you aren't keeping up with draining the internal buffer. > I just released a key (let's say "p"), but I only read F0. I tried to reproduce this with the examples/x86/i8042.c test program and tweaks of it, but could not in the few minutes I spent trying. I have appended the hacked version of the test program, which cycles the LED state frequently (tweak foo in gdb to adjust how fast) so you can try to type at the same time and see if they interfere. It is entirely possible there is a bug in the driver with this. When you do a write, the driver puts that in its tiny output queue (8 bytes), and sends it out the port. Then it watches the input bytes to notice 0xfa or 0xfe, which are the device ACK/NAK of each command byte, and eats the 0xfa or 0xfe bytes until it has ACKs for all the bytes it sent (output queue is drained). As it is now, it delivers the final 0xfa byte as data, which tells you your full command was received by the keyboard; you will read one 0xfa for each oskit_stream_write you did, but actually in oskit-mach the code in oskit/ds_asyncio.c will pause in the middle of your device_write buffer and do another oskit_stream_write when the queue drains, so if there are multiple asynchronous device_writes going on you are really getting an 0xfa for each time the output buffer filled + 1. I think probably I should just make it eat the final 0xfa as well. Change to "break;" to "continue;" in "case KBC_DEVCMD_ACK:" to make that happen. It would be ideal if you could find a way to tweak this test program and a pattern of using it that produces a problem. That stuff I can debug right now. If not, it might actually be an interaction with the oskit-mach glue code. If working oskit-mach and hurd are required to debug it, I won't get to it as soon. > Another serious bug is that my I/O permission stuff is not working properly. > There seems to be a race of some sort. In that case you really want to put a bkpt at i386_exception or suchlike and find exactly what is happening. > Of course it could be something very subtle like the need to flush or > update something after installing the IO ports at a task switch. It looks to me like the switching code does the very same thing I see in the Linux sources. > Or maybe it's just that I am not pausing (I am using out, not out_p, but > I think that should work, and not cause a SIGKILL anyway). Figure out what machine trap is happening and all the available machine state at the time before speculating more. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
