On Sat, 30 May 1998, David Stanhope wrote:

> I have seen this many times, and my analisis goes as follows:
> 
> in the kernel putc routine in 'com.c', assuming a program is outputing data
> (something
> started by 'init') and then the kernel wants to do a 'putc' what happens is:

> putc waits for the uart to have room, then outputs the character, then
> clears the interrupt flag, the problem with this is that this will keep
> an interrupt from signalling to the com interrupt handler that it needs
> to load more characters. When this hang occurs output will still come

I'm confused. Shouldn't another interupt be generated once the character
output by putc gets sent? Then there'd be an interupt for the tty layer to
process.

I'm not familiar with the com transmit fifo, so I'm speculating based on
what the Zilog SCC does. It has a 1 byte transmit fifo, and a status bit
to indicate if this fifo's empty.

Could this be the scenario:

1) com fifo drains, generating an interupt
2) com chip transmits last character, so transmitter's empty as well as
	fifo
3) computc transmits byte
4) since transmitter's empty, byte goes to transmitter, and fifo
immediatly becomes empty, generating an interupt
5) computc clears pending interupt

> from the kernal but all normal com output is stopped. What worked for me
> was to not clear the interrupt flag at the end of the putc routine. This
> has the affect of sometimes causing extra interrupts but since there
> isn't a lot of kernal putc activity, this should be ok. It has been a
> while since I worked with serial consoles but the code in com.c still
> looks somewhat similar. 

If the scenario I mentioned is right, just have computc test to see if the
fifo's empty after transmitting. If so, don't clear the pending interupt.
Though this can be a nasty race condition. :-)

Take care,

Bill