Subject: Re: SCC silo overruns -- Re: X11 problems on 5000/133
To: Toru Nishimura <nisimura@is.aist-nara.ac.jp>
From: emanuel stiebler <emu@ecubics.com>
List: port-pmax
Date: 01/31/1998 11:30:13
Hi all,
a note to this,
all of this serial I/O is handled by this SCC, right ?

I notice since i got the "new" january release of 1.3 sometime a weird
behaviour of my vt220 terminal. ( Sorry, i don't know it was fixed before).
looks like if the buffers are overrun, the chip/software copies some
characters into the input buffer, and they appear ont the command line.
this happens by 9600 and 19200 baud.

cheers,
emanuel

P.S. i thought, this behaviour was fixed on one of the late 1.3 betas. for
a short time i had no problems using x-windows.

----------
> From: Toru Nishimura <nisimura@is.aist-nara.ac.jp>
> To: port-pmax@NetBSD.ORG; pcw@mesanet.com
> Subject: SCC silo overruns -- Re: X11 problems on 5000/133
> Date: Friday, January 30, 1998 8:49 PM
> 
> Hi.
> 
> In article <34D2325B.41C67EA6@mesanet.com>
> pcw@mesanet.com wrote
> 
> >> I just installed 1.3 (binary using the generic kernel) on my 5000/133
> >> (64M, PMAGB-BA, RZ25 disk) and was pleased at how simple it was using
> >> the sysinst utility.
> >>    [ .... ]
> >> I noticed also that the kernel reports SCC silo overflows if
> >> you move the mouse before X is started, is this normal?
> 
> Not normal.  It needs to be fixed, eventually.  If you do not mind
> kernel build process, try follows and report the results to me;
> 
> In a file arch/pmax/tc/scc.c, function sccintr(), locate a if-clause;
> 
> 	} else if (rr2 == SCC_RR2_A_RECV_DONE ||
>                 rr2 == SCC_RR2_B_RECV_DONE || rr2 ==
SCC_RR2_A_RECV_SPECIAL ||
>                 rr2 == SCC_RR2_B_RECV_SPECIAL) {
> 	    ....clause-body-for-receive....
> 	}
> 	else if (...
> 
> Insert lines enclosing the whole branch;
> 
>            do {
> 	   	....original if-clause body....
> 		SCC_READ_REG(regs, chan, SCC_RR0, cc);
> 	   } while (cc & ZSRR0_RX_READY);
> 
> Besides this NetBSD/pmax internal has deep deficiencies about how to
> handle interrupt masks.  Jonathan could explain details.
> 
> Tohru Nishimura
> Nara Institute of Science and Technology