🚀 go-pugleaf

cdewick@orb.apana.org.au (Craig Dewick) writes:


>I never knew that the kernel logged not only the location details but also
>the number of the RAM module as shown on the 3/80 schematic! 

neat huh?

>Anyway, I'm a little confused as to how this error was actually detected,
>and since it hasn't occured again would I be right to assume that it might
>have been a random thing and not a *real* RAM problem? I was under the

COuld just be a 'soft' error.

>impression that RAM integrity checking was only ever done as part of the
>power-on self test. 

No, the parity logic is working round the clock. It wouldn't make much
sense on systems who have 100s of days uptimes otherwise.


>Craig.
>     Craig Dewick, located in Sydney, Australia. cdewick@orb.apana.org.au

Wilko

cdewick@orb.apana.org.au (Craig Dewick) writes:

>I'd never really given much time to think about the benefits of parity
>checking of RAM, but this afternoon I have come home to find that my 3/80
>had self-rebooted at 17:19 when the kernel detected a parity error. I'll
>let the log file speak for itself.... 

[...]

>Anyway, I'm a little confused as to how this error was actually detected,
>and since it hasn't occured again would I be right to assume that it might
>have been a random thing and not a *real* RAM problem? I was under the
>impression that RAM integrity checking was only ever done as part of the
>power-on self test. 

The whole point of parity ram is that you detect errors while the machine
is running. Dynamic ram, being essentially a capacitor, can be discharged
by radiation - it's actually not that uncommon for single bit errors to
occur.

The NCR machines that I used to use had error correcting ram - they would
log a correction about once every six months (these machines generally had
uptimes in the order of years).

--
Andrew McNamara
System Engineer
connect.com.au Pty Ltd

In <1995Jul14.030358.28194@taylor.infi.net>, Mark Davis <mark@taylor.infi.net>:
>Parity RAM is next to useless.  It is really a waste of valuable bits.
>The only logical approach is to use no parity, or use ECC RAM.
>Parity memory can't even detect but SOME memory errors, and can't do
>ANYTHING about it, except warn (or as pointed out, just go ahead and
>crash the system anyway).

A Unix system could do much better than just crashing the system.
If the parity error occurs in a clean page the OS could just reload
the page from the FS or swap.  If it occurs in a dirty page the OS
could kill just the affected process(es).  Only parity errors in
the OS itself should require a reboot.

ECC is much better (though it also only detects SOME memory errors)
but it is also more costly.  Parity seems to have a useful niche in
the cost/benefit tradeof.
-- 
Jim Prescott - Systems Staff	jgp@seas.rochester.edu	ur-valhalla!jgp
School of Engineering and Applied Sciences, University of Rochester, NY

andrewm@connect.com.au (Andrew McNamara) writes:

>cdewick@orb.apana.org.au (Craig Dewick) writes:

>>I'd never really given much time to think about the benefits of parity
>>checking of RAM, but this afternoon I have come home to find that my 3/80
>>had self-rebooted at 17:19 when the kernel detected a parity error. I'll
>>let the log file speak for itself.... 

>[...]

>>Anyway, I'm a little confused as to how this error was actually detected,
>>and since it hasn't occured again would I be right to assume that it might
>>have been a random thing and not a *real* RAM problem? I was under the
>>impression that RAM integrity checking was only ever done as part of the
>>power-on self test. 

>The whole point of parity ram is that you detect errors while the machine
>is running. Dynamic ram, being essentially a capacitor, can be discharged
>by radiation - it's actually not that uncommon for single bit errors to
>occur.

Parity RAM is next to useless.  It is really a waste of valuable bits.
The only logical approach is to use no parity, or use ECC RAM.
Parity memory can't even detect but SOME memory errors, and can't do
ANYTHING about it, except warn (or as pointed out, just go ahead and
crash the system anyway).

>The NCR machines that I used to use had error correcting ram - they would
>log a correction about once every six months (these machines generally had
>uptimes in the order of years).

Our Altos 15,000 uses ECC Ram.  In 2.5 years, it has found and corrected
13 single bit errors.  Any one of those errors had the potential to bring
the system down, but ECC prevents it from happening.  The ECC system can
detect a lot more than single bit errors, and can correct single, double, and
some other memory errors (don't have the docs in front of me). The Altos 15000
has an INCREDIBLE uptime- it has never failed and seems to keep running
forever.  ECC RAM is a must for a serious computer system.

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis     | Lake Taylor Hospital | Norfolk,VA (804)-461-5001x431 |
  | Director/SysAdmin | Information Systems  |    mark@taylor.infi.net       |
  \--------------------------------------------------------------------------/

mark@taylor.infi.net (Mark Davis) writes:

>Parity RAM is next to useless.  It is really a waste of valuable bits.
>The only logical approach is to use no parity, or use ECC RAM.
>Parity memory can't even detect but SOME memory errors, and can't do
>ANYTHING about it, except warn (or as pointed out, just go ahead and
>crash the system anyway).

I disagree.  Without parity, single-bit errors will silently corrupt data.
This can be very problematic.  A system panic is often preferable.

Of course, ECC memory provides significantly more protection than parity, but 
the extra two bits per byte makes it more costly.  Parity is a reasonable 
compromise for desktop workstations.

Regards,

John
--
John DiMarco <jdd@cdf.toronto.edu>                        Office: EA201B
Computing Disciplines Facility Systems Manager            Phone: 416-978-1928
University of Toronto                                     Fax:   416-978-1931
http://www.cdf.toronto.edu/personal/jdd/jdd.html

jgp@stiletto.ceas.rochester.edu (Jim Prescott) writes:

>A Unix system could do much better than just crashing the system.
>If the parity error occurs in a clean page the OS could just reload
>the page from the FS or swap.  If it occurs in a dirty page the OS
>could kill just the affected process(es).  Only parity errors in
>the OS itself should require a reboot.

If SunOS/Solaris detect a parity error, it can recover from those conditions
and I've seen it happen.

It will panic if it can't recover. 
If the page is clean, it will be reloaded.  If it's dirty, the affected
processes will be killed.  The memory location causing the error
will be checked and it will be put out of service if the error is permanent
and it will be put backin service if the error is transient.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.