>> on a related note, there is a bad interaction [i.e. bug] between kernel 
>> printf's and normal serial I/O.    for example, if you put debugging kernel 

Is this for the alpha?

>This is a "known problem" (or at least, charles and I knew about it
>8-), but i don't know if your estimate of the problem is correct.

In general, polling an xx(x)50 shouldn't be mixed with interrupt driven
i/o.  Polling in the serial console driver is almost guaranteed to eat
output completion interrupts.

The i386 version may work because splhigh() doesn't actually mask
interrupts.  The (FreeBSD/NetBSD) software will latch the interrupt and
the interrupt will recover by testing the output-ready bit (waiting for
an output interrupt id wouldn't work).  However, you can't rely on this
for a machine-independent driver.  splhigh() will completely mask
interrupts on some machines.

The FreeBSD sio driver avoids this problem by context-switching most of
the UART registers.  An output interrupt is generated as a side effect
of restoring the interrupt enable register; this should allow the driver
to recover even if the interrupt isn't latched in software.  (The
context switching is a bit over-engineered and causes loss of input on
some buggy UARTs.)

>I believe i've also occasionally seen it lose (multiples of 16)
>characters of output on the serial console as well.  That's what

Debug with an 8250 :-) or the fifo disabled.  It tends to be easier
to see races.

Bruce