NOTICE: zs3:ring buffer overflow
A. Karl Heller
What are these messages? And how do I stop them from crashing the system?
This is solaris 2.4
Karl
Casper H.S. Dik - Network Security Engineer
> What are these messages? And how do I stop them from crashing the system?
They don't crash your system. These message are symptoms of your system
crashing or hanging, not an indication of the cause.
Casper
Yatish Mishra
: What are these messages? And how do I stop them from crashing the system?
: This is solaris 2.4
I have been fighting this problem from day one with SunOS and Solaris on SPARC
and x86. This problem happens when I receive too much data too fast from the
serial port using hardware RTS/CTS flow control. It turns out that all of
Sun's OS are busted for inbound flow control using RTS signalling. XON/XOFF
works great for receiving ZMODEM or KERMIT but is not supported for XMODEM
or YMODEM.
Our company got around this problem by doing some tricks within our serial
communications program to prevent the buffer from overflowing. Buffer
overflow causes my system to lock up for a few minutes and then eventually
regain life. It is really annoying! I wish Sun would fix this problem.
If I am wrong about the above conclusion, please correct me. Good luck.
--
_______________________________________________
Yatish Mishra, Microlink Technologies, Inc.
yat...@microlink.com (work)
yat...@ccnet.com (personal)
_______________________________________________
Ralf-Thomas Klar
> I have been fighting this problem from day one with SunOS and Solaris on SPARC
> and x86. This problem happens when I receive too much data too fast from the
> serial port using hardware RTS/CTS flow control. It turns out that all of
> Our company got around this problem by doing some tricks within our serial
> communications program to prevent the buffer from overflowing. Buffer
We have the same problem on a SPARC10. I was told, that 'zs3' is the serial
communications driver for the keyboard. For we have no modem connected to
our SPARC, the overflow can only be caused by the keyboard or by the
mouse. I was not able to solve the problem, but I noticed, that we had
the problems only when the system was on very high load with some large
programs. It looks like the OS has no time to serve the 'zs3' buffer ;-)
--
Ralf Thomas Klar --- ua...@rz.uni-karlsruhe.de ---
Yatish Mishra
: We have the same problem on a SPARC10. I was told, that 'zs3' is the serial
: communications driver for the keyboard. For we have no modem connected to
: our SPARC, the overflow can only be caused by the keyboard or by the
: mouse. I was not able to solve the problem, but I noticed, that we had
: the problems only when the system was on very high load with some large
: programs. It looks like the OS has no time to serve the 'zs3' buffer ;-)
Oops... I didn't look at the original post very carefully. Our problem was
not with zs3 (keyboard), but zs0 (serial port). For us, buffer overflows
are common when receiving large amounts of data from the Sun serial ports
since RTS/CTS flow control does not work for inbound traffic. Serial buffer
overflows brings the system down to it's knees and can take from 1-20 minutes
to recover. Strange...
Guy Harris
>I was told, that 'zs3' is the serial communications driver for the
>keyboard.
Whoever told you that is mistaken. It's the serial port for the
*mouse*; "zs2" is the serial port for the keyboard.
Ronald F. Guilmette
Ralf-Thomas Klar <ua...@rzstud2.rz.uni-karlsruhe.de> wrote:
>Yatish Mishra (yat...@ccnet.com) wrote:
>
>> I have been fighting this problem from day one with SunOS and Solaris on SPARC
>> and x86. This problem happens when I receive too much data too fast from the
>> serial port using hardware RTS/CTS flow control. It turns out that all of
>
>> Our company got around this problem by doing some tricks within our serial
>> communications program to prevent the buffer from overflowing. Buffer
>
>communications driver for the keyboard. For we have no modem connected to
>our SPARC, the overflow can only be caused by the keyboard or by the
>mouse. I was not able to solve the problem, but I noticed, that we had
>the problems only when the system was on very high load with some large
>programs. It looks like the OS has no time to serve the 'zs3' buffer ;-)
Right, or more accurately, it doesn't have enough time to service the
serial port interrupts (sometimes) before incoming bytes start falling
out of the small FIFO buffer which is actually implemented in hardware
and contained on the serial port chip itself.
So what's the real problem here? Is the operating system too slow, or
is the FIFO buffer on the serial chip too small?
Well, it is my understanding that the real problem is that Sun used cheap
serial port chips, and that the FIFO buffers on these chips are just too
darn small, especially during periods of high system load, when CPU cycles
are necessarily being spent on other high-priority things, e.g. servicing
_other_ kinds of interrupts.
The 16550 serial port chips which are being seen more and more often
in PeeCee systems have (I think) 16 bytes worth of input buffering on chip.
In the case of the serial port chips you get on Sun systems... well... I've
heard different things, but the commonest story I've heard has been that
the serial chips Sun uses only have 3 bytes worth of buffering on them, and
that at high data rates (e.g. 38400 or beyond) this just ain't enough.
If that's all true, then there simply is no software-only fix for this
general problem. Often people suggest that users experiencing this problem
should go out and buy an expensive serial port board. I don't like that
solution myself at all, and I wish that Sun would just offer for sale
some sort of do-it-yourself serial-port upgrade kit, which with I could
get a better serial chip to handle the serial ports that I already have.
--
-- Ron Guilmette, Roseville, CA ---------- RG Consulting -------------------
---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -
John Donovan
cable.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Donovan Systems Engineer So now I think I'll leave you
jdon...@newbridge.com with your bishops and your guilt
Newbridge Networks Herndon, VA so until the next time
DOD#-96 1992 Suzuki GSX1100G have a good sin
-Iron Maiden Only The Good Die Young
The above is my personal view and is not, and should not be interpreted as,
the views, policies or position of Newbridge Networks or any of its employees.