Subject: Re: Serial console hangs
To: Bill Studenmund <skippy@macro.stanford.edu>
From: Todd Whitesel <toddpw@best.com>
List: port-i386
Date: 09/04/1998 23:46:57
> I don't think this is the solution. I think the reason putc is clearing
> the interupt is to make its activities have zero impact on the tty system,
> which it does when the tty is silent. Your whole (valid) point is that
> this scheme has a big impact when the tty is active.
> 
> I think a better solution is to make the interupt clearing happen only if
> the tty is not transmitting. If it's transmitting, leave the interupt. If
> the tty's silent, clear it.

Perhaps this has been settled offline. If not:

Allowing both interrupt and non-interrupt code to access the same device
registers without mutex protection is, in general, wrong. For all but the
simplest (or most well-designed) devices, there will be many potential race
conditions, which are often much harder to reproduce than the 4800 baud test
case that was mentioned.

Here is the worst-case guaranteed safe algorithm for the non-interrupt code:

    1. raise the irq level to ignore the UART.
    2. disable interrupt requests in the UART itself.
    3. restore the old irq level.
    4. do whatever it intends to do to the device, including direct calls to
	the normal interrupt handler for that device.
    5. raise the irq level to ignore the UART.
    6. re-enable interrupt requests in the UART itself.
    7. restore the old irq level.

This can be simplified if the actions in step 4 always take constant time.

Unless we are certain that all possible interleaved executions of the
interrupt and non-interrupt code will not conflict in their use of the
device registers, we should be prepared to use the 7-step algorithm
described above.

Todd Whitesel
toddpw @ best.com