Actually, what Matt said isn't quite right.  I didn't just think it
was unneeded; I also tested it fairly heavily on a SPARCclassic and
was unable to reproduce the problem.

What I *think* is happening is the following:

The zs chip in the SS1 (and possibly SS1+ and SS2) is latching the
interrupt line.  There's a window between when zscnputc() is called
and when the chip finishes sending the console character, where the
interrupt may be delivered but there will be no TX bit set in RR3.
This causes the `crazy interrupt'.

Assuming that this is the problem, the correct thing to do is to send
a ZSRW0_RESET_TXINT in zscnputc() if we had to wait for the TX bit.


I'd appreciate it if someone who has one of these machines, and who
can reproduce the problem, would test this.


*** zs.c.orig	Sun Mar 29 21:39:35 1998
--- zs.c	Wed Apr  8 13:56:31 1998
***************
*** 748,751 ****
--- 748,761 ----
  	s = splhigh();
  
+ 	/*
+ 	 * If there was a transmission in process, and thus TIE is set, we
+ 	 * will get a TX interrupt after this character is sent (replacing any
+ 	 * that may have been pending when we entered this routine).  This
+ 	 * guarantees that the normal transmission will continue.
+ 	 *
+ 	 * If there was no transmission in process, TIE will not be set, and
+ 	 * we will not get a TX interrupt.
+ 	 */
+ 
  	/* Wait for transmitter to become ready. */
  	do {
***************
*** 753,756 ****
--- 763,770 ----
  		ZS_DELAY();
  	} while ((rr0 & ZSRR0_TX_READY) == 0);
+ 
+ 	/* Reset interrupt latch on some chips. */
+ 	zc->zc_csr = ZSWR0_RESET_TXINT;
+ 	ZS_DELAY();
  
  	zc->zc_data = c;