Article View: alt.sys.sun
Article #908Justification for the use of 9-bit wide RAM modules
From: Craig Dewick
Date: Mon, 10 Jul 1995 00:00
Date: Mon, 10 Jul 1995 00:00
45 lines
3026 bytes
3026 bytes
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....
Jul 10 17:19:57 ppt vmunix: Parity error:
Jul 10 17:19:57 ppt vmunix: virtual address 0xffb6b750
Jul 10 17:19:57 ppt vmunix: errreg 0xd1
Jul 10 17:19:57 ppt vmunix: physical address 0x27d750
Jul 10 17:19:57 ppt vmunix: Parity error at SIMM U0603
Jul 10 17:19:57 ppt vmunix: panic: synchronous parity error - kernel
Jul 10 17:19:57 ppt vmunix: syncing file systems... done
Jul 10 17:19:57 ppt vmunix: 00150 low-memory static kernel pages
Jul 10 17:19:57 ppt vmunix: 00144 additional static and sysmap kernel pages
Jul 10 17:19:57 ppt vmunix: 00000 dynamic kernel data pages
Jul 10 17:19:57 ppt vmunix: 00025 additional user structure pages
Jul 10 17:19:57 ppt vmunix: 00001 segmap kernel pages
Jul 10 17:19:57 ppt vmunix: 00000 segvn kernel pages
Jul 10 17:19:57 ppt vmunix: 00184 current user process pages
Jul 10 17:19:57 ppt vmunix: 00022 user stack pages
Jul 10 17:19:57 ppt vmunix: 00526 total pages (526 chunks)
Jul 10 17:19:57 ppt vmunix:
Jul 10 17:19:57 ppt vmunix: dumping to vp ff1a7214, offset 33136
Jul 10 17:19:57 ppt vmunix: 526 total pages, dump succeeded
Jul 10 17:19:57 ppt vmunix: rebooting...
Jul 10 17:19:57 ppt vmunix: SunOS Release 4.1.1 (sun3x_80) #2: Sun Jan 22 12:11:09 EST 1995
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!
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.
Regards,
Craig.
--
Craig Dewick, located in Sydney, Australia. cdewick@orb.apana.org.au
Phone: [PSTN] (int. +612, loc. 02)-527-1292, or [GSM] 0411-158-574
Always striving for a secure long-term future in an insecure short-term world
"But wait, there's more..." - "Don't send any money, we'll bill you..."
Technical Details
Message-ID:
<3tqpb5$dl8@orb.apana.org.au>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f4671,4711ba0969b34d53,start X-Google-Attributes: gidf4671,public X-Google-Thread: f88e1,4711ba0969b34d53,start X-Google-Attributes: gidf88e1,public X-Google-Thread: 1070f0,4711ba0969b34d53,start X-Google-Attributes: gid1070f0,public X-Google-Thread: 10d053,4711ba0969b34d53,start X-Google-Attributes: gid10d053,public From: cdewick@orb.apana.org.au (Craig Dewick) Subject: Justification for the use of 9-bit wide RAM modules Date: 1995/07/10 Message-ID: <3tqpb5$dl8@orb.apana.org.au> X-Deja-AN: 105998985 distribution: inet organization: ORB - Engineering the Cyber Matrix newsgroups: alt.sys.sun,aus.computers.sun,comp.sys.sun.admin,comp.sys.sun.hardware