Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!cit-vax!ucla-cs!zen!ucbvax!CC2.BBN.COM!ado
From: ado@CC2.BBN.COM (Buz Owen)
Newsgroups: comp.emacs
Subject: Re: emacs convenience bug fix
Message-ID: <8709142254.AA05163@ucbvax.Berkeley.EDU>
Date: Mon, 14-Sep-87 17:37:54 EDT
Article-I.D.: ucbvax.8709142254.AA05163
Posted: Mon Sep 14 17:37:54 1987
Date-Received: Wed, 16-Sep-87 01:17:35 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 32

Here's an update on this bug:

Either we didn't run Binkeley and newtest on our machine yet,
or David Abe, who was going to do it, didn't tell me the result
yet.

However, I have some new data on this bug.

1) Tom Blackadar and others had suggested to me that I was
having switch contention problems, and that running "toset 2000"
might help.  It tried this and it makes no difference.

2) we swapped the hanging processor on our machine with a
processor in another slot.  The bug moved to the new slot.
This normally indicates a hardware problem, but keep reading.

3) When the problem occurs, the node is STILL UP.  You can run
processes on it from other nodes.  However, the processes never
complete.  Instead, they hang after producing all their output.

4) Curious about this and the fact that "lf" and "showmem" hang,
I looked at the code of the latter two a little bit.  I concluded
that they were stuck in "For_All_Objects" looking at objects
on the node in question.  I wrote a test program that just called
For_All_Objects and printed the oid.  It turns out that For_All_Objects
correctly passes a few oids correctly, and then gets stuck looping
on a single object.  So the program prints a few oids, and then starts
printing the same oid over and over.  This is strongly indicative
of a software bug, not a hardware bug.

For the moment, I am just getting the node into the system cluster
and keeping it out of general use.