Summary: cache corruption

> On Wed, 21 Nov 2001 10:40:36 EST, Donald.McLachlan@crc.ca writes:
>
> Recently I have periodically been getting the following error message in
> the console window of my Solaris box:
> 
>  Nov 21 08:29:18 obelix unix: WARNING: cachefs_ffhold: filegrp corrupt,
> run fsck
> 
> The box is an autoclient, and uname -a reports:
> 
>  SunOS obelix 5.7 Generic_106541-17 sun4u sparc
> SUNW,UltraSPARC-IIi-Engine
> 
> What is the command to report whether it is running the 32/64 bit kernel
> again? [ I know it is the 64 bit, but do not remember how to show you
> that. ]
> 
> Is there any way to track down the source of this corruption? Is this an
> early indication of disk problems?



As for my first question they all pointed me to isainfo.  Thanks.
It appears this is not an early indication of disk problems.  Whew.

The only "solution" I was given was to try "boot -f".  I did so, and it
did not look like it did anything different than a normal boot, but the
problem has not resurfaced.  I'm not sure that means anything as the problem
only occurred occasionally anyway.

Other answers were:

-----

> It's a cachefs kernel problem; the SunSolve Bug ID is 4451611.  I have a
> call open with Sun on it.
> 
> The Bug ID was escalated to engineering, but as far as I know Sun hasn't
> fixed it yet.
> 
> The problem may also cause occasional panics.

-----

I was told to check /var/adm/messages to see whether the box has rebooted
itself (appears not), and to

	grep -i bad   /var/adm/messages*
	grep -i score /var/adm/messages*

(bad and score not found)

> during an ecache dump, it is possible to show that data is corrupted, and
> it will write to the message file the word bad.
> 
> also grep -i score, it is possible you have processor going bad.  Most of the
> processors are going bad because of the bad ecache chips.
> 
> If you find the box has been rebooted by itself and any messages with score
> in them, I would contact sun and they will instruct you on what they will
> need to determine if its a bad processor.

Thanks to:

	From: Dan Astoorian <djast@cs.toronto.edu>
	From: Badri narayanan <pnbadri@yahoo.com>
	From: "Steve Hastings" <stevehas@us.ibm.com>
	From: "Osama Ahmed" <osama@ieee.org>

Don