Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!elroy.jpl.nasa.gov!cit-vax!ktl
From: ktl@wag240.caltech.edu (Kian-Tat Lim)
Newsgroups: comp.sys.sgi
Subject: Re: Intermittent Login Problems
Message-ID: <14025@cit-vax.Caltech.Edu>
Date: 28 Feb 90 08:33:34 GMT
References: <52878@bu.edu.bu.edu>
Sender: news@cit-vax.Caltech.Edu
Reply-To: ktl@wag240.caltech.edu (Kian-Tat Lim)
Organization: California Institute of Technology, Pasadena, CA
Lines: 27
In-reply-to: eap@cs.bu.edu (Eric A. Pearce)


	We went around and around with SGI hotline personnel on this
problem last month.  It was actually reported in this newsgroup back
in December.  I finally managed to get a fix out of someone at SGI,
but apparently the hotline people have yet to hear about it.

	The cause of the problem appears to be high CPU load producing
timeouts when downloading the graphics microcode into the graphics
processor.  This supposedly only occurs on multiprocessor systems with
at least one processor saturated (100% usage).  Apparently SGI didn't
really expect us to beat on these boxes...

	The fix (which you should be able to confirm by talking to
Gretchen at the hotline or Momi, who apparently found the problem
[sorry, I didn't get last names]) is to change the variable
network_processor in file /usr/sysgen/master.d/kernel to 0 (zero) from
its default value of 1 (one).  You must then run lboot (I used lboot
-t -v -d) and reboot with the new kernel.  I suppose you might be able
to adb the kernel if you were feeling lucky, but neither SGI, I
imagine, nor I will sanction that.

	This fix has cured our problems so far, though we did have one
other suspicious hang after the fix when physical memory was very low
that has neither recurred nor been explained.

--
Kian-Tat Lim (ktl@wagvax.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)