home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.vms
- Path: sparky!uunet!psinntp!vitro.com!v7.vitro.com!vaxs09
- From: vaxs09@v7.vitro.com
- Subject: Re: Question about RMS and MSCP-pair
- Message-ID: <1993Jan7.080321.1@v7.vitro.com>
- Lines: 25
- Sender: news@vitro.com (USENET News System)
- Organization: Vitro Corporation
- References: <1993Jan4.115621.29717@news.th-darmstadt.de> <61050100@acf3.NYU.EDU> <1ia8nhINNa8k@nz12.rz.uni-karlsruhe.de>
- Date: Thu, 7 Jan 1993 13:03:21 GMT
-
- In article <1ia8nhINNa8k@nz12.rz.uni-karlsruhe.de>, DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
- > My experiences:
- > 1) EDT crashed some years ago with ACCVIO on VMS4.x (*not* forced error!).
- > ANALYZE/RMS or ANALYZE/IMAGE showed forced error.
-
- There was (and perhaps still is) a problem with the RD54 disk drive that
- could cause this sort of behavior. Normally, a forced error on a page fault
- read tags the page in question and eventually results in a page read
- error (SS$_PAGRDERR) when the page is referenced. Unfortunately, the IOSB
- filled in after a read from an RD54 completes with a forced error bit set
- indicates a number of bytes transferred that includes the block with the
- error. The RA81 (and, I presume all DSA drives) by contrast fill in a byte
- count that does not include the problem block.
-
- The result of this is that page fault handling code believes that the bad
- block is one page farther along in memory than it really is. A good page
- is tagged as bad and the bad page (filled with zeroes as it turns out)
- is tagged as good.
-
- We stumbled on this behavior several years ago when a forced error bit
- in the middle of ADA.EXE on an RD54 caused access violations. An identical
- copy of ADA.EXE (I have a program that can set forced error bits) on
- an RA81 properly reported page read errors instead.
-
- John Briggs vaxs09@v7.vitro.com
-