Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Software Main Store Error Injection Mechanism

IP.com Disclosure Number: IPCOM000122220D
Original Publication Date: 1991-Nov-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 104K

Publishing Venue

IBM

Related People

Dietel, JD: AUTHOR

Abstract

A method of injecting main store errors in a controlled manner is disclosed. The errors may be injected on any main store card and at any address (see Fig. 1).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Software Main Store Error Injection Mechanism

      A method of injecting main store errors in a controlled
manner is disclosed.  The errors may be injected on any main store
card and at any address (see Fig. 1).

      Requirements for Verification of Main Store Error Handling:
-  The error should be able to be injected at a single location in
main store.
-  The failing address should be flexible so all the cards and the
boundary conditions of interleaving and masking can be tested.
-  The error must be injected at the hardware level so the failure is
as 'real' as possible.  This will verify that the hardware error
detection and trapping functions work as designed.

      This invention solves the main store error injection problem by
creating a new instruction, INJMCK, meaning INJect Machine ChecK.
INJMCK is an instruction with operands to specify the injection
address and the kind of error to inject.  While other kinds of errors
may be injected, this description will focus on double-bit
correctable main store errors.  INJMCK uses special commands to the
main store cards that were intended for use by the main store
diagnostics that run at IPL time.  Because they were not designed for
normal run-time use, they must be used with caution.  These cautions
will be pointed out later.

      The diagnostic command at the core of INJMCK puts the main
store card into double-bit error mode (DBE mode).  DBE mode is a
function of the memory card and causes all fetches issued to that
card to get double-bit hard-hard correctable errors.  These errors
are very 'real' in that the failing address is trapped and reported
in the same way as one occurring naturally.  The task, then, for
INJMCK is to get into DBE mode, access main store to cause and trap
the error, and then get back out of DBE mode.

      Interleaving and masking cause complications that make it
difficult for microcode to determine which main store card
corresponds to a particular address.  So the INJMCK microcode puts
ALL cards into DBE mode.  This way the error is sure to be forced
when the operand is referenced.

      When memory cards are in DBE mode, ANY reference will cause the
error to be trapped.  Once trapped, subsequent errors are not trapped
until microcode resets the trap condition.  Since part of the test is
to verify the actual address reported by the hardware trapping
mechanism, microcode must ensure that all main store activity is
quiesced before entering DBE mode.  This will guarantee that the
address in the trap registers correspond to the INJMCK operand
address.  For a uniprocessor, two steps are needed:
1.  Set a special bit in a hardware register that blocks I/O
accesses.
2.  Read a hardware register that complet...