Newsgroups: comp.arch
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Workstation Data Integrity
Message-ID: <1990Aug12.011532.5622@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <40694@mips.mips.COM> <2399@crdos1.crd.ge.COM> <1990Aug10.171744.9639@zoo.toronto.edu> <1990Aug10.223619.6223@portia.Stanford.EDU>
Date: Sun, 12 Aug 90 01:15:32 GMT

In article <1990Aug10.223619.6223@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes:
>>...They were horrified to discover that
>>their parity circuit didn't work...
>    Wait - what do you mean, the parity circuit didn't work?  That it
>couldn't detect parity errors, or what?

He wasn't specific, but the implication was that under at least some
circumstances it falsely reported errors.

>On the IBM PC, and most clones,
>I think, a parity error raises a non-maskable interrupt.  Under DOS, this
>is not a recoverable error - i.e., a parity error hangs the system.  DOS
>just prints some dumb message, and stops dead in its tracks.  I suppose
>commercial software could patch the interrupt vector to try to recover
>from the error, but no one bothers.

What he said was that, based on their experience, *everyone* bothers --
or did at the time (this wasn't recent) -- and the "recovery" consisted 
of ignoring the error completely.  Since I avoid Intel processors :-),
I can't confirm or deny this myself.

>As far as I know, yes, there isn't a
>way for software to tell if the parity system is working, but then
>wouldn't that be a bit much to expect on a PC?

Had the Japanese designed it, you can bet it would have been testable.
(Another input to the parity encoder, controlled by software or even
a DIP switch, would suffice.)  The only way you can improve quality
is if you can measure it.
-- 
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  henry@zoo.toronto.edu   utzoo!henry