[14229] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: cache corruption problem on Sparc5's (?)

daemon@ATHENA.MIT.EDU (Marc Horowitz)
Sun Mar 3 14:29:27 1996

To: Michael J Duff <mjduff@MIT.EDU>
Cc: cprivate@MIT.EDU, bugs@MIT.EDU, cfyi@MIT.EDU
Date: Sun, 03 Mar 1996 14:29:20 EST
From: Marc Horowitz <marc@MIT.EDU>

>> Could someone explain the problem in detail to us consultants so we
>> can better help users avoid the problem?

Unfortunately, nobody can describe the problem in detail because
nobody understands it in detail.

I have had more than ample experience with this bug, though :-( On the
sparc 5, the assembler (which is called by the C compiler, and other
things), for reasons unknown, generates bogus .o files.  The linker
doesn't expect this bogosity, and fails in "weird" ways.  Since this
isn't reproducible, recompiling the broken .o file will often work.
Recompiling a lot of .o files won't, because you'll often have the bug
recur.

I have never had this bug happen on a sparc classic, nor have I had it
happen when writing to a non-AFS device.  I do the former frequently;
I do the latter only occasionally, so the bug may not be in AFS, but
exacerbated by it somehow.

It does not seem to be an AFS cache consistency problem, because the
file in the cache and on the server are always both the same, and both
broken.

If anybody has anything to add, or real evidence to point the finger
at something besides AFS, I'd like to hear it.

>> as users could potentially lose important work.  

I'm not sure this is true, unless a user writes some code, compiles
it, deletes the code, and then realized the .o files are bad.  This
seems unlikely.

		Marc

home help back first fref pref prev next nref lref last post