zs3: silo overflow crashes

[Guy Harris]

>My system is a 3/260 under 4.0.1.  On the average of once a week, my
>system crashes with a zs3: silo overflow.  Device zs3 is not mentioned in
>my kernal configuration file - not even in a comment line.  The only zs
>devices there are zs0 and zs1.

Each "device zsN" line that appears in a "config" file refers to *two*
serial ports; a Zilog Z8530 SCC chip has two channels.  You probably have
a line like

	device		zs0 at obio ? csr 0x20000 flags 3 priority 3

which refers to devices "zs0" and "zs1" (the fact that it says only "zs0"
on the line nonwithstanding; the nomenclature for devices in the sense of
a line in a config file, and in the sense of something with a minor device
number all its own, are separate), and a line like

	device		zs1 at obio ? csr 0x00000 flags 0x103 priority 3

which refers to devices "zs2" and "zs3" (again, the "zs0" and "zs1" in the
"device" lines are not the same as the "zs0", "zs1", "zs2", and "zs3" in
the error messages; "device" line "zsN" refers to devices that would
appear as "zs(2N)" and "zs(2N+1)" in error messages).

>These crashes seem to be associated with mouse activity

Not at all surprising.  Three guesses how the mouse is attached to the
host....

The two ports on "device zs1", which are referred to as "zs2" and "zs3"
in error messages, are for the keyboard and mouse, respectively.

>- usually, but not always rapid mouse activity.

Especially mouse activity while the system is crashing for some other
reason.  If the system is crashing, it is probably printing a lot of stuff
with the kernel's "printf" routine, and doing so at a very high interrupt
priority, so that the "zs" devices can't interrupt the CPU.  As the mouse
moves, it generates a stream of 5-byte (as I remember) motion events;
that's not one 5-byte event per movement of the mouse, that's several of
them - one for each little increment the mouse moves.  The Z8530 chip has
an on-chip silo, but it only holds two bytes; if the CPU doesn't respond
pretty quickly to an interrupt request, the silo will overflow.  Once the
interrupt priority is lowered to the point where the Z8530 can interrupt
the CPU again, the interrupt comes in, the device driver notes that the
silo overflowed, and prints a message to that effect.

In other words, the "zs3: silo overflow" messages may be a *consequence*
of the crash, not a *cause* of it.