This is a summary of the answers I was sent for the following two
questions, for the benefit of anyone else who may be experiencing the
same symptoms. Many thanks to all those who replied.
***** Question 1: frequent lockups in OpenWindows under Solaris 2.1 *****
Eckhard R"uggeberg <eckhard@ts.go.dlr.de> said:
>I consider Solaris2.0 to be Solaris2alpha and Solaris 2.1 to be Solaris2beta
>I can only recommend to quickly get Solaris2.2.
Ken <kenyee@ksr.com> said:
>Get 2.2...2.1 is really buggy wrt X. remote xterms to a Sol2.1 machine
>are totally broken. This went away with 2.2.
I am trying to lobby our sysadmin to upgrade to 2.2...
Ken Taylor <kenichi@beach.cray.com> said:
>I had the same problem. Change your input focus to follow mouse to get
>around the bug. You can also run openwin with "openwin -server
>/usr/bin/X11/X" because the bug appears to be with xnews.
Changing the input focus to "follow mouse" appears to fix the problem!
This was also suggested by the next answerer. Unfortunately I do not
have a built copy of the MIT X distribution, although I am tempted
to build Motif and be done with it!
Jim Prescott <jgp@ee.rochester.edu> provided a solution from
Tim Steele <tjfs@tadtec.co.uk>:
>Add the following lines to your .Xdefaults, then quit & restart
>OpenWindows.FocusLenience: True
>OpenWindows.ServerGrabs: False
>OpenWindows.SetInput: followmouse
>olwm.WindowCacheSize: 0
I did this and haven't had any problem for a whole day now (that must
mean it's fixed!). Thanks to Jim (and Tim).
Richard Walker <walker@island.com> suggests that I restrict the apps I
run to those in /usr/openwin/bin, rather than standard X11 apps.
I am doing this, as the xterm I run is in /usr/openwin/bin.
Donaldo Carvalho <ccdonald@sunvis1.vislab.olemiss.edu> suggested applying
the patch 100895-02. This fixes the problem of OpenWindows hanging when
focus mode is set to "click to type" in Solaris 2.1. The patch can be
downloaded from sunsite.unc.edu in /pub/sun-info/sun-fixes.
SUMMARY: the problem is specific to the "click to type" focus mode.
The easy way out is to change to "follow mouse" focus mode.
This can be done from Workspace Properties or by changing the
.Xdefaults file as shown above.
In order to fix the problem for "click to type" mode, the
100895-02 patch is required.
Don't run standard X11 software, stick to /usr/openwin/bin.
Of course the best alternative is to upgrade to Solaris 2.2!
***** Question 2: zs3: silo overflow message before a kernel panic *****
Jim Prescott <jgp@ee.rochester.edu> said:
>The message basically means that the low-level driver is dropping characters
>because the high-level driver isn't taking them out of the FIFO fast enough.
>This frequently happens before a panic since the high-level driver is in the
>process of panic'ing and thus isn't reading from the FIFO.
>Hence the message is usually just a sympton of the panic and not its cause.
Scott Barman <scott@asd.com> said:
>Actually the problem may be unrelated to your upgrade, just
>coincidental. I had that same type of problem on a Sun 4/110. What
>happened was the keyboard was broken and was sending out spurrious
>codes. We changed the keyboard and had no problems since.
>.............. This is an error message from the ol' DEC days--right
>out of the original BSD code. It figures Sun wouldn't change this but
>change other cute messages (like make's). The silo is the input silo,
>or buffer, on the serial controller or virtual interface. If you have
>something that keeps sending data into a serial port that doesn't
>respect xon/xoff or rts/cts protocols, then you will fill up those
>buffers faster than the kernel can process the interrupts. If you
>overrun those buffers, or silos, then you will get the panic message
>because the kernel doesn't know how to handle those interrupts.
>It usually happens when a modem is connected to a noisy line. The
>purpose of the silo is to interrupt the kernel when the first character
>is received and just store the rest until the kernel gets to it. When
>a silo fills, or reaches a certain threshold, the hardware is designed
>to interrupt on every character. Too many of these interrupts do not
>sit well with the kernel, so it causes a panic trap and the system dies.
>There are limited cases where the kernel can recover, but if data keeps
>coming in, recovery can be impossible and the kernel will just throw up
>its (virtual) hands and give up.
Now that IS an interesting idea. The reason? Just two weeks ago, Sun
came over to swap my keyboard for a new one because the old one developed
a stuck Return key. Now that I think about it, the problems started just
after I got the new keyboard installed, and the new keyboard is a slightly
different model to the old one... I think there's a solution brewing here!
SUMMARY: This may be caused by the wrong keyboard model (not sure yet)
Again, thanks to everybody for replying so quickly. Now maybe I can use
my SPARCstation for continuous periods of over 3 hours without
having to restart OpenWindows :-)
-- /------------------------------------------------\ / Ellis Brover ellis@cpsg.com.au \ / Software Engineer ph. +61-3-243-2300 \ / CP Software Group fax +61-3-243-2301 \ / 4/493 St. Kilda Rd., Melbourne 3004, Australia \ /------------------------------------------------\
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:00 CDT