Subject: Re: Scc driver parity bug [was Re: parity bug? Tty line numbers broken?]
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Per Fogelstrom <pefo@enea.se>
List: port-pmax
Date: 09/25/1995 20:35:48
> 
> 
> [[description of pmax SCC output stripping chars with even parity
>   and large delays]]
> 
> >        if (tp->t_flags & (RAW|LITOUT))
> >                cc = ndqb(&tp->t_outq, 0);
> >        else {
> >   I========>>  cc = ndqb(&tp->t_outq, 0200);
> >   I            if (cc == 0) {
> >   I                    cc = getc(&tp->t_outq);
> >   I                    timeout(ttrstrt, (void *)tp, (cc & 0x7f) + 6);
> >   I                    tp->t_state |= TS_TIMEOUT;
> >   I                    goto out;
> >   I            }
> >   I    }
> >   I
> >The second call to 'ndqb' is done with flag = 0x80. This will catch chars
> >with the parity bit set and that char will be treated as a delay value.
> 
> My driver already *has* this (see below).  So does the Alpha driver.
> I'm not sure what the Alpha port.  I'm not sure what you're suggesting
> an appropriate fix is.  Is it to remove or #ifdef out the delay code??
> 
Sorry, i was in the middle of my dinner :-). What i meant was that this
*is* the problem. Characters with the 'parity bit' set starts timeouts
instead of being printed. I just ripped the piece of code out. Sorry for
being unclear.

The resulting code is as follows (replaces the above code piece):

        cc = ndqb(&tp->t_outq, 0);

Some drivers use (if they have local buffers to increase throughput):

	cc = q_to_b(&tp->t_outq, ser_outbuf, cc);

Someone might be able to explain what the ndqb code is good for. I don't
know. Perhaps if you use a teletype!! :-)

Per