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