I tried this patch, but it still gets the stray interrupts.

-Chuck


"Charles M. Hannum" writes:
> 
> 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;
> 
>