Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dev8o.mdcbbs.com!campbell From: campbell@dev8o.mdcbbs.com (Tim Campbell) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: Memory Parity. Is It Really Needed Message-ID: <1991Apr8.183732.1@dev8o.mdcbbs.com> Date: 8 Apr 91 18:37:32 GMT References: <3370017@hpsgwp.sgp.hp.com> <1991Mar24.094904.9519@eecs.wsu.edu> <2217@pdxgate.UUCP> <1865@svin02.info.win.tue.nl> <2258@pdxgate.UUCP> Organization: McDonnell Douglas M&E, Cypress CA Lines: 46 Nntp-Posting-Host: dev3 Nntp-Posting-User: sandy In article <2258@pdxgate.UUCP>, berggren@eecs.cs.pdx.edu (Eric Berggren) writes: > wsineel@wsooti01.info.win.tue.nl (Eelco Vriezekolk) writes: > >>In article <2217@pdxgate.UUCP> berggren@eecs.cs.pdx.edu (Eric Berggren) writes: >>>wbonner@eecs.wsu.edu (Wim Bonner) writes: >>> nice touch ;) -v >>>>In article <3370017@hpsgwp.sgp.hp.com> plim@hpsgwp.sgp.hp.com (Peter Lim) writes: >>[PC with and without memory parity] >>> >>> The part about memory parity I don't understand is that I am told one >>>wants memory parity checking done to "prevent loss of important data". Well >>>everytime I got a memory parity error, I lost important data because it >>>brought the whole system to a halt. What next? Helicopters with emergency >>>ejector seats? wierd... > > I agree, but I would rather be advised and allow me to make a decision > about how I would handle it. In some databases (and probably some spread- > sheets too) if you don't close up properly, you may lose everything. Of > course, that's what backups are for. When a write-verify fails on a disk, > it doesn't erase the disk for you. It gives you an error and, depending, > on the application, allows you to use another disk. > My main point was not necessarily the concept of memory parity (which > I probably left the subject a little) but more how most systems handle it. > Anyway, no big deal. It doesn't happen that often... > If you get parity errors - somethings WRONG - you should probably do something about it (like replace the chip, clean the dust out of the computer (now there's an interesting concept) or check to make sure all the chips are properly seated on the boards (SIMMs properly seated in slots)). You _CAN_ control what happens when the error occurs. The occurance of the error generates an interrupt. Anyone can attach that interrupt vector (sorry, don't recall which interrupt it is - 02h or 03h come to mind). The default action is to print a rather cryptic error message (which allegedly tells you at what address the error occured - fingering the bad chip) and promptly locking your machine. If you want you can plug in a far pointer to an IRET instruction in which case the machine will do absolutely nothing (although _I_ personally wouldn't advise this approach) and proceed merily along with corrupt data. --------------------------------------------------------------------------- In real life: Tim Campbell - Electronic Data Systems Corp. Usenet: campbell@dev8.mdcbbs.com @ McDonnell Douglas M&E - Cypress, CA also: tcampbel@einstein.eds.com @ EDS - Troy, MI CompuServe: 71631,654 (alias 71631.654@compuserve.com) P.S. If anyone asks, just remember, you never saw any of this -- in fact, I wasn't even here.