Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!sun!pitstop!texsun!convex!uunet!hi-csc!giebelhaus
From: giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus)
Newsgroups: comp.sys.apollo
Subject: Re: sfcb hash table mutex lock
Message-ID: <4123bc79.1032a@hi-csc.UUCP>
Date: 28 Jan 89 19:43:00 GMT
References: <8901250632.AA00797@icaen.uiowa.edu>
Reply-To: giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus)
Organization: csdd
Lines: 29

In article <8901250632.AA00797@icaen.uiowa.edu> dbfunk@ICAEN.UIOWA.EDU (David B. Funk) writes:
>To summarize, when you have sfcb hash table problems:
>    Check for processes not exiting cleanly
>    Check revision levels of system software
>    Check for bug reports on software that you use
>
>When in doubt, reboot before things come to a grinding halt.

Very impressive Dave!  The details are much more than I know about the
system.  But I do want to be sure to say that I believe the summary to
be accurate.

I have not seen it spelled out specifically that if you BLAST process
with "sigp -b", "lo -f", or some other method that send a BLAST to
a process, you are running on borrowed time.  A reboot quite likely
will be necessary.  A blast will cause a process to not exit
cleanly which, as Dave points out, is one of the things to watch for.

I have not seen problems with the DN4000 machines having hash table
problems yet, but if you believe that things are not getting blasted,
you don't have revision mixes, and your in-house and third party
software does not have related bugs, please do call it in to the 
hot line 800 number (provided of course that you have a service
contract) or file an APR with crucr or mkapr.
-- 
UUCP: uunet!hi-csc!giebelhaus         UUCP: tim@apollo.uucp
ARPA: hi-csc!giebelhaus@umn-cs.arpa   ARPA: tim@apollo.com
Tim Giebelhaus, Apollo Computer, Regional Software Support Specialist.
My comments and opinions have nothing to do with work.