SLC Screen Save?

[Guy Harris]

>Now the question: Has anyone solved the problem of the screen
>UN-blanking every time the modem carrier drops and a kernel printf
>prints another:
>
>	Jan 26 21:48:43 wsrcc vmunix: zs0: parity error ignored
>
>This seems to update the time on whichever device screenblank looks
>at, and it dutifully unblanks the screen.  Incidently 'X' doesn't
>unblank the screen when this happens.
>
>What parity error is this griping about anyway?  Is this a hardware
>bug where something finally notices that the 8530 SCC doesn't have a
>9-th bit,

Actually, it *does* have a 9th bit, in that it can handle 8 bits plus a
parity bit.

> or is it talking about the ascii (meta-bit) "parity" bit?

Nope.  The claim in the code is that if a character with bad parity is
received, a receive interrupt occurs that stuffs the character into the
driver's ring buffer, and then a "special receive condition" interrupt
occurs that reports the error.

If IGNPAR is not set, the special receive condition interrupt handler
tries to fish the bad character out of the driver's ring buffer, in
order to put the right thing back into the ring buffer ('\377', '\0',
and the character if PARMRK is set; just '\0' otherwise).  If it fails
to do so (e.g., because the character has already been sent upstream),
it complains "zsN: parity error ignored".

I'm not sure that's really the case; 1) the Zilog documentation I have
handy doesn't seem to indicate that there are two interrupts delivered,
and 2) as I remember when testing that by putting a tty into the wrong
parity mode and typing on it, two aren't delivered.  If it *is* the
case, something better needed to be done than something that sends the
bad character upstream anyway - and if there's nothing that can be done
about the bad character, there doesn't seem to be much point in
complaining about it.