[Sunhelp] Thanks for everyone's responses on the rebooting is sue!

[Almazan_Hector at emc.com]

You need to replace CPU 3. The problem is the ecache not the CPU, but the
ecache is part of the CPU Module.
There has been a problem with SUN's ecache made by IBM. They said that the
new CPU will fix this problem.



> -----Original Message-----
> From:	Adams, Christopher [SMTP:CAdams at starbase.com]
> Sent:	Wednesday, September 06, 2000 3:53 PM
> To:	Sunhelp (E-mail)
> Subject:	[Sunhelp] Thanks for everyone's responses on the rebooting
> issue!
> 
> The Oracle DBA had a few things to say about Hal Flynn's comment.
> ..hehe.., but I really liked your idea Hal, thanks! 
> 
> As for our rebooting issue, the only reason why I asked about it, was
> after we rebooted it ran well for about a day then Oracle caused a panic
> and the 450 rebooted and when it came back up FSCK was asking that I do a
> manual FSCK on the Oracle partitions "/ora_system" and "/ora_tmp" (these
> partitions may not be Oracle Universal).  When I ran the FSCK against
> those two partitions Solaris reported back or FSCK reported back with:
> UNKNOWN FILE TYPE: <giving the inode number> . CLEAN?  y or n    And it
> did this on 1000's of files within both of these partitions.  
> 
> I tried to respond with "no" to all of them at first using the "-f" switch
> to force it, but this caused the partitions to still be unmountable.  So I
> did the reverse and replied yes to them (getting some bad block errors
> along the way).  After it was finished both parititions were mountable and
> Oracle "seemed" to start up fine, but the next day the system crashed,
> only reporting 
> 
> To keep this from being a drawn out Oracle question here is the error that
> I found in the /var/adm/messages log file: 
> 
> <date / time hostname> inetd[11129]: telnet/tcp: bind: Address already in
> use 
> <date / time hostname> unix: panic[cpu3]/thread=300002ef6a0: 
> <date / time hostname> unix: 
> <date / time hostname> syncing file systems.. 
> <date / time hostname>   3 
> <date / time hostname>   done 
> <date / time hostname> dumping to /dev/dsk/c0t0d0s6, offset 55050240 
> . 
> . 
> . 
> . 
> . 
> 
> 
> <date / time hostname> savecore: reboot after panic: CPU 3 Ecache
> Writeback Data Parity Error: AFSR 0X00000000. 00800200 AFAR 0x00000000.
> 7f530a00
> 
> Can anyone make anything out of this error? 
> 
> Thanks again for your suggestions and help.. 
> 
> 
> Christopher A. 
> 
> 
>