Over the years there have been numerous reported incidents of "panic:
crazy interrupts" at level 12 (the `zs' interrupt level). I've just
discovered why this may happen if the console is on the serial line:
there's a race for the chip's Interrupt Pending bits when doing
regular tty output and kernel `v_putchar's simultaneously.

When zscnputc() has a character to print it waits for the chip's
output buffer to become empty, then writes the character into
the output register. Now, if the chip was busy shipping out a
character from the regular tty output discipline, then

	(1) TX interrupt will have been enabled
	(2) processor interrupt are disabled: zscnputc runs at splhigh
	(3) writing the data in zscnputc() clears the interrupt
	    condition on the chip.
	(4) after zscnputc() return from splhigh, the interrupt is taken
	    but the zs interrupt handler finds nothing to handle.

This probably wouldn't be really disastrous if it weren't the case
that this condition is brought to attention by sending the string
"stray interrupt: <etc>" through the line immediately after this happens.

A fix would probably include some mechanism to defer data sent through
zscnputc() if it finds TX interrupts enabled until the zs interrupt
handler runs, using, say, a high priority (1 byte) queue, or somesuch.

-pk