SUMMARY: SRAM error Ultra1

From: Chris Stoddart (c.stoddart@dcs.shef.ac.uk)
Date: Wed Sep 22 1999 - 11:20:53 CDT


Thanks to the following folks, who all told me more-or-less the same
thing - poorly CPU or poorly cache:

Jim Craven <craven@cg.NRCan.gc.ca>
rsaddler@cccis.com
Lucia Gonzalez <luciag@meta4.com>
Dylan Carlson <dylan.carlson@mciworld.com>
Richard Felkins <richardf@gso.saic.com>
Karl_Sprules@ACML.COM
Adrian Stovall <adrians@solarsystems.com>
Scott Kulp <skulp@lucent.com>
"Schultz, Juergen" <Juergen.Schultz@m.dasa.de>
"Newman, Timothy L" <tim.newman@amp.com>
"Thomas Carter"<tcarter@memc.com>
sunsrv@blr.cmc.net.in
strombrg@nis.acs.uci.edu

Sun confirmed it was a CPU problem and replaced the CPU (we have a
maintenance contract). It turned out that they had to replace the
whole mainboard since the CPU was a fixture. I notice that the new
mainboard had a /huge/ heatsink and no fan - obviously a redesign because
we have had to replace two Ultra-1 CPU fans in the last year (including
the one on this machine).

Cheers again everyone,

Chris

Original message below:

> I have an Ultra1/170 running Sol 7 that has experienced a couple of
> crashes recently with the error:
>
> panic[cpu0]/thread=70cf7340: CPU0 Ecache SRAM Data Parity Error:
> AFSR 0x00000000.00400002 AFSR 0x00000000.37effff0
>
> Does this mean that one of the memory SIMMs is misbehaving? If so, any
> ideas how to find out which one from that lot above? Or indeed to deciper
> it into something more practical?
>
> Any info gratefully received.

-- 
Dr Chris Stoddart: Unix SysAdmin,
Department of Computer Science, 
Sheffield University, U.K.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:25 CDT