Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Why do I need a "sfcb hash table mutex lock"?
Message-ID: <4eed8f39.1bc5b@pisa.ifs.umich.edu>
Date: 31 Dec 90 16:49:57 GMT
References: <9012280914.AA03633@duc220.uni-duisburg.de>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 24

In article <9012280914.AA03633@duc220.uni-duisburg.de>, hj412fr@duc220.uni-duisburg.de (Martin Anantharaman) writes:

  We are having serious problems with a DN3550 under SR10.2 and the
  service technicians from HP are stymied themselves, so I am hoping
  for help from the GURUS out there:
  
  	At the press of a key the system (display AND processes) suddenly
  	freezes and crawls along at about 0.1 % of the usual speed (with luck I
  	am able to shut the system, but that takes 20-30 minutes). Most of the time
  	we have to reset the system, after which it runs normally for some time,
  	BUT disk salvage everytime, lots of diskless stations hanging around ...

The sfcb hash table is at the heart of the IO system.  It's sort of like
the file table in regular Unix.  It is protected by a mutex lock.  The
behavior you see happens when some process fails to unlock the table,
usually as a result of an unexpected fault with the lock held.

Look for a process dump with a traceback somewhere inside of ios.  It
probably won't be the most recent traceback, since things will have died
when they couldn't get the lock.  Also try to correlate this behavior with
something you did immediately before.

Things to watch for include out-of-sync software (/lib/streams not
compatible with /lib/clib, for example) and poorly-behaved type managers.