> 1) The problem only occurs if you use a kernel driver for input an the
> firmware for output.

Hmm. Interesting.

> 2) It occurs on the com driver as well as kbd at zstty, but not with
> the zskbd driver.

What interrupt priorities do these two drivers (zstty&kbd vs. zskbd) run
at? The problematic behaviour looks (to me) like a lost interrupt.
Perhaps interrups are blocked while output is written via OF?

> Determining if it's actually happenning [input polling] is going
> to be difficult other than by actually fixing the problem.  

It's simple, just patch OF using the NVRAM so that you have a wrapper
around the routines you are interested. This exercise is a SMOP and one
that I am happy to leave as an exercise for some other reader. ;-)

> I think it's much more likely to be some issue involving latencies
> scheduling callouts to handle the TTYs rather than competition between
> the firmware and a driver.

Wibble.

> Now, the Stop-A problem is probably a different issue that was
> cause when the com driver was converted to use cnmagic().  It's
> probably conflicting with the sunkbd driver.

What sunkbd? No such device gets attached. Let me guess, the two drivers
share a cnmagic setting?

> You should check
> to see what the hw.cnmagic sysctl variable is set to.

It is set to 'M'. The cnmagic manual page describes a lot of things, but
not what 'M' means. <sly>You should complain to the author</sly>

I quite like my hypothesis of interrupts being disabled (or swallowed
somehow). If nobody goes doh, or laughs at the idea, I'll try and look
at it when I get home from work.


Cheers,
Lloyd