schultz@mmm.serc.mmm.com (John C Schultz) (03/14/89)
We have been suffering an intermmitent problem with diskless SUN 3's
crashing after coming out of xlock under X11R2 (SunOS 3.5).
The symptoms are that after xlock ends, the system will behave nicely for
an arbitrary length of time up to perhaps 20 minutes. If you have
survived 20 minutes, the Sun will run indefinitely. However, occasionally
the display will go black and no keyboard or mouse entry is allowed. Even
L1-A does nothing. Powering off and back on is the only cure.
This happens on both 3/60M and 3/60C workstations and the problem seems to
come and go. For example about 2 weeks ago, almost every time I came out
of xlock, I had to reboot. Lately, I never crash coming out of xlock.
Although we now use X11R2, I seem to recall that the 3/60s occasionally
exhibited this same behaviour under Sunwindows although we have not used
it for about a year and my memory is vague.
Perhaps someone can offer words of wisdom or at least commiserate so we
don't feel so lonely.
Thanks.--
john c. schultz schultz@3M.Com ..!uiucuxc!mmm!schultz (612) 733-4047
3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000paul@amos.ucsd.edu (Paul Smith) (03/31/89)
schultz@mmm.serc.mmm.com (John C Schultz): >We have been suffering an intermmitent problem with diskless SUN 3's >crashing after coming out of xlock under X11R2 (SunOS 3.5). >... >the display will go black and no keyboard or mouse entry is allowed. Even >L1-A does nothing. Powering off and back on is the only cure.... Sorry I can't offer any help but at least I can commiserate. We have been experiencing similar problems with our sun 3/50s and 60s. We are running X11R3 under 4.0. I haven't connected the problem with xlock, but we do regularly run xlock. We also run X11R3 on our 4/260 but haven't had the problem there. One thing I should make clear is that the sun isn't actually "crashed". In our case it's only the monitor which has died, and the CPU board's L.E.D.s don't indicate an error. Our suns are happily babbling away on the net while the monitor and keyboard are down. Can anybody help? Paul Smith paul@amos.ucsd.edu pssmith@ucsd (619) 534-2695
stevel@sun.com (Steve Langley) (03/31/89)
We had precisely the same problem; the only thing I was ever able to figure out was that it had something to do with interference from (or with) the screensaver; if you turn the screen saver feature off using xset the crash went away. The good news is the problem vanishes entirely if you go to X11R3. Steve Langley Phone: (415)748-3658 Relational Technology, Inc. Internet: stevel@ws58s.rtech.com P.O. Box 4008 1080 Marina Village Parkway Alameda, California 94501
aperez@cvbnet2.UUCP (Arturo Perez Ext.) (04/26/89)
> schultz@mmm.serc.mmm.com (John C Schultz): > >>We have been suffering an intermmitent problem with diskless SUN 3's >>crashing after coming out of xlock under X11R2 (SunOS 3.5). >>... >>the display will go black and no keyboard or mouse entry is allowed. Even >>L1-A does nothing. Powering off and back on is the only cure.... > It turns out that there's a very (!) poor interaction between screenblank and X. Screenblank is started up by /etc/rc.local. I don't know what the exact story is but the symptoms sound very similar to yours: Machine sits around (bored) for a while (sometimes not) Machine's screen blanks out and nothing brings it back Reboot machine. Actually, one thing that does bring it back is rlogin'ing in to the machine as root and doing reset < /dev/console >& /dev/console (assuming csh syntax). However, if you kill screenblank the problem goes away; at least it does here! Arturo Perez ComputerVision, a division of Prime primerd!cvbnet!aperez
mmm%informatics.rutherford.ac.uk@nsfnet-relay.ac.uk (05/10/89)
paul@amos.ucsd.edu (Paul Smith) writes: > schultz@mmm.serc.mmm.com (John C Schultz): > > the display will go black and no keyboard or mouse entry is allowed. Even > > L1-A does nothing. > One thing I should make clear is that the sun isn't actually "crashed". > In our case it's only the monitor which has died It could be that the video is being turned off. Nothing will turn it on again, except something like screenblank - but even then only if it thinks >it< turned the video off, so you have to leave the keyboard and mouse idle for (by default) 10 minutes. Try explicitly turning the video back on again, or enquiring its status, with the following C program or the equivalent packaged into a shell script. __________ /* switch video on or off. Mark M Martin. March 1989 */ #include <sys/ioctl.h> #ifndef _IO #include <sys/ioccom.h> #endif _IO #include <sun/fbio.h> main(argc,argv)char **argv;{ int i,f; f = open("/dev/fb",0); if(f<0)exit(2); if(argc==2 && strcmp(argv[1],"off")==0){ i = FBVIDEO_OFF; exit(ioctl(f,FBIOSVIDEO,&i)<0); } if(argc==2 && strcmp(argv[1],"on")==0){ i = FBVIDEO_ON; exit(ioctl(f,FBIOSVIDEO,&i)<0); } if(argc!=1){ printf("usage: %s {on|off}\n",argv[0]); exit(2); } exit(ioctl(f,FBIOGVIDEO,&i)<0?2:(i==FBVIDEO_OFF?1:0)); } __________ #!/bin/sh # switch video on or off. Mark M Martin. RAL Jan 1989 tmp=/tmp/video$$ trap 'rm -f $tmp.*;exit 3' 1 2 3 15 case $1 in -off|off) code="i = FBVIDEO_OFF; exit(ioctl(0,FBIOSVIDEO,&i)<0);" ;; -on|on) code="i = FBVIDEO_ON; exit(ioctl(0,FBIOSVIDEO,&i)<0);" ;; '') code="exit(ioctl(0,FBIOGVIDEO,&i)<0?2:(i==FBVIDEO_OFF?1:0));" ;; *) echo "usage: $0 {on|off}" exit 1 ;; esac include=sys/ioccom.h if [ ! -f /usr/include/$include ] then include=sys/ioctl.h fi echo "#include <$include> #include <sun/fbio.h> main(){int i;$code }" >$tmp.c cc $tmp.c -o $tmp.a && $tmp.a </dev/fb save=$? rm -f $tmp.* exit $save __________ Informatics arpa: mmm%inf.rl.ac.uk@nss.cs.ucl.ac.uk Rutherford Appleton Lab uucp: ..!mcvax!ukc!rlinf!mmm Didcot, Oxon, UK. OX11 0QX mmm@rlinf.uucp Tel +44 235 44 5160 Fax +44 235 44 5831