[2869] in SIPB-AFS-requests
Re: ra paniced
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Oct 19 18:37:52 1997
Date: Sun, 19 Oct 1997 18:37:42 -0400
To: mhpower@MIT.EDU
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[2868] in SIPB-AFS-requests"
From: John Hawkinson <jhawk@MIT.EDU>
| This may be a symptom of a hardware problem that occurs on Sparc 5s.
| I've attached two messages about it below. We might want to try
It may be, but I think that sort of decision has the potential to be
premature. Asynchronous memory faults can mean a lot of things, but
usually they're best interpreted in concert with some other sort of
diagnostic that may occur. If no other diagnostics actually occurred
[could someone verify], maybe then we should try mucking with memory.
Sun Infodoc #14171 has some recommendations (attached).
--jhawk
INFODOC ID: 14171
SYNOPSIS: kernel tips: Causes of asynchronous memory fault panics
DETAIL DESCRIPTION:
What causes an "asynchronous memory fault" panic?
There are two main causes of asynchronous memory fault panics.
1) The CPU cache did not flush properly to main memory.
The CPU can modify cache rows in its cache, such as cached data which has
been changed by a program. This data must be written out to main memory
at some point if it is to be accessed by other processors or stored onto
disk. The write that takes place is asynchronous to the part of the CPU
that uses the data (the part which makes calculations, etc). It takes
place from an on-chip write buffer, to which cache rows are queued;
writes from this buffer out to main memory are completed by a different
part of the chip. The "asynchronous memory fault" occurs when the
asynchronous write from the cache to main memory terminates with an
error.
(Note that the actual write always takes place from the on-chip write
buffer regardless of whether the MMU is in write-through or copy-back
mode, or uses data that is marked non-cacheable.)
The error can be due to any hardware along the path between the cache
itself and the memory, including the CPU module, the motherboard or the
memory. Look elsewhere for more clues as to what could be causing the
problem, to narrow down the bad hardware. Check the /var/adm/messages
files and dmesg output for other kinds of errors, perhaps (ecc) memory
errors which would indicate memory problems, other kinds of CPU errors
which would indicate a bad cpu module, Mbus timeout errors (which point
to a potentially bad motherboard), and so on.
2) An external device attempted to read or write a bad memory address.
This could be a hardware problem where the device was properly set up
but accessed a bad address, or the memory could be bad; or it could be a
software problem, because a device driver did not set up its device to access
the proper part of memory. Such a memory fault is asynchronous with
respect to the CPU, because the device tried to do DMA to the memory,
independent of the CPU.
The way to tell whether or not the case is (1) or (2) is to observe the
logistics of when the problem happens. Does this problem happen
consistently while a particular thing is going on? Software problems
tend to be consistent, predictable and replicable; whereas hardware
problems tend to be more random. Things to look for:
- Is there a third party device, which, when operated, triggers this
panic condition?
- Are there DMA errors in the /var/adm/messages file to point the way
to a suspect device?
PRODUCT AREA: Kernel
PRODUCT: crash
SUNOS RELEASE: any
HARDWARE: any
----------------------------------------------------------------------------
