SUMMARY (again): zs0 silo overflow

From: Loki Jorgenson (
Date: Fri Jun 14 1991 - 08:45:39 CDT

        Sorry. I am repeating this summary because I found some of the
messages that I though I had trashed and I wanted to update and repost

        Summary: Observing a "flood" of the well-known

                "zs0: silo overflow"

messages along with slowing machine, tty sessions missing key strokes,
etc. on a SUN3/50 running SUN OSv3.5.

        Thanks to: (Brent Chivers) (Dennis Morse) (Thomas Kilday) (Terry Rasmussen)

        Everyone who every had a SUN3 knows this message. Causing
consternation and confusion, it is normally a harmless message. The
device "zs0" is a serial line driver; it controls the serial ports
on the motherboard. SUN Microsystems usually advises that you ignore
this message.

        However, in our case, we were seeing several dozen per minute.
This was just after I changed a couple of Ether buffer chips on the
machine. It turned out that our modems connected to the serial ports
were in a funny state because the RS232 connectors were making
intermittent contact; they were flooding the serial ports with garbage.
And, of course, the serial circuit was probably unbalanced due to bad

        Alternately, some other helpful users mentioned these potential
sources (apologies to a couple of others whose replies got trashed):

From: (Brent Chivers)

This suggests a lot of activity on one or more serial ports.
Do you have a modem attached that's echoing back login prompts?
Or an unhappy printer?

We often get this when we reboot. Various terminals have
been queueing up keystrokes on port servers, and when the
machines wake up again a lot of garbage comes flooding in
on the serial ports.

From: (Thomas Kilday)
        This error indicates a bad keyboard. Try replacing it
        and see if that fixes it.

From: (Dennis Morse)

The "zs0" is a Zilog 8530 SCC serial communications driver. See the man
page for zs(4s). This is most likely not a hardware problem by a kernel
configuration issue. It sounds like the kernel buffers are too small.
The easiest way to fix this is to increase the "maxusers" parameter in the
kernel config file "/sys/sun3/conf/<YOUR_CUSTOM_KERNEL_NAME>".

I sure hope you are already building custom kernels, since the 3/50 is so
slow and has such limited memory that it needs all the help it can get. We
typically set our "maxusers" parameter to 10-14 for our SPARCstation
clients, depending on the amount of RAM installed. When we had Sun 3/50s
we set "maxusers" to 6 or 8. The value of 4 in GENERIC_SMALL is too low.

From: (Terry Rasmussen)

I see this one quite a bit, when I queried my Sun Rep.
the response I had received was roughly "...don't
worry about it..." This is of course, paraphrased to
condense the actual responce.

I've been seeing this since 1987 and it doesn't seem
to be adversely effecting anything and Sun has apparently
ignored it as well since it is still showing up these
days on machines running 4.1.1 of SunOS.

So my advice would be to simply not worry about it.

From: (Terry Rasmussen)


You might want to try setting the machine up as a diskless
client and see if the keyboard freeze up still happens, when
doing this test I would suggest not using the local swap
space once and then using the local swap space. If the system
still has problems as a "diskless client" with a local swap
space, but has no problems when the swap space is on another
system (via nfs) then the culprit is the system disk.

You might want to also monitor your power supply.

If all else fails there are 3/50 upgrade boards out there fairly
cheap these days (what with every one falling all over themselves
to migrate away from the MC68K chip set) from third party vendors.

                             _ _ _ _
Loki Jorgenson / / _ _ _ _ _ \ \ node: loki@Physics.McGill.CA
Grad/Systems Manager /_/_/_/_/ \_\_\_\_\ BITNET: PY29@MCGILLA
Physics, McGill University \ \ \_\_\_/_/_/ / / fax: (514) 398-3733
Montreal Quebec CANADA \_\_ _/_/ phone: (514) 398-7027

                      -* Anatomically correct *-

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT