Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!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: <4ef7cdb8.1bc5b@pisa.ifs.umich.edu>
Date: 2 Jan 91 17:42:56 GMT
References: <9012280914.AA03633@duc220.uni-duisburg.de> <1990Dec30.194240.17416@alphalpha.com>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 23

In article <1990Dec30.194240.17416@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes:

  Anyway, at SR10.2, at least on my 3500, the following code clears
  the lock...

  main()
  {
      char *p;
      p = (char *) 0x3B6F8072;
      *p = 0;
  }

Now that's what I call magic.  That number will change with every release of
the system and model of hardware.  You can find the lock by following
pointers down from sfcb_$puid_ptr, but I don't recommend this.

Part of the fun is getting your unlock program to run.  If the lock is
stuck, then every attempt to acquire it results in a 90 second timeout.

I used to have a daemon that would check the sfcb lock every minute, and if
it found the lock stuck (held and ec not advancing) it would shut down the
node.  This won't work any more because reboot() no longer does a shutdown,
it signals process 1 to do the shutdown (why was this changed?).