> However, even then I got crazy interrupts eventually.  My suspicion is
> that it happens when an "esp0: ESP100 work-around activated" message
> happens during the printing of something else, and running with output
> going into a file and then using tail -f on the file simply makes it
> more likely that something else will be printing when the esp message
> prints.


I fixed the race condition that was causing this earlier this year
in the previous version of the zs driver.  I fear that change was
not ported to the current driver.

Here's a description of the problem that I posted to port-sparc/port-sun3
a while ago:


> 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.
>