Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!shelby!portia.stanford.edu!dhinds From: dhinds@portia.Stanford.EDU (David Hinds) Newsgroups: comp.arch Subject: Re: Workstation Data Integrity Message-ID: <1990Aug10.223619.6223@portia.Stanford.EDU> Date: 10 Aug 90 22:36:19 GMT References: <40694@mips.mips.COM> <2399@crdos1.crd.ge.COM> <1990Aug10.171744.9639@zoo.toronto.edu> Organization: AIR, Stanford University Lines: 28 In article <1990Aug10.171744.9639@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >> The IBM PC, AT, and PS/2 models use per-byte parity, as do all of the >>clone machines built by other vendors. This provides adequate >>protection... The term PC includes both business PCs, with minicomputer >>features, and machines intended primarily for games and home use, which >>are built as cheaply as possible... > >But, but, but... virtually all MSDOS software *explicitly ignores* >parity errors. A friend of mine, working for a clone builder, had >an interesting story to tell. They were horrified to discover that >their parity circuit didn't work... after a good many of the machines >were in the field and functioning fine! It hadn't been caught in >the factory because there is no way that software can test the IBMPC >parity system, and it hadn't been caught by the customers because all >the commercial software just ignored it. > Wait - what do you mean, the parity circuit didn't work? That it couldn't detect parity errors, or what? 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. 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? -David Hinds dhinds@popserver.stanford.edu