Re: oskit driver for i8042 keyboard controller

[Roland McGrath]

> 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.