Browse Prior Art Database

Recovery Mechanism for Risc System/6000 Asynchronous PIO Store

IP.com Disclosure Number: IPCOM000112545D
Original Publication Date: 1994-May-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 67K

Publishing Venue

IBM

Related People

Chen, WT: AUTHOR [+2]

Abstract

A synchronous Load/Store to I/O space, also called PIO, has the drawback of holding the cpu while waiting for the access to I/O device (adapter) to complete. This holding time is significant due to the speed gap between cpu and I/O adapters. This will get worse as the cpu continues to speed up.

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

Recovery Mechanism for Risc System/6000 Asynchronous PIO Store

      A synchronous Load/Store to I/O space, also called PIO, has the
drawback of holding the cpu while waiting for the access to I/O
device (adapter) to complete.  This holding time is significant due
to the speed gap between cpu and I/O adapters.  This will get worse
as the cpu continues to speed up.

      Asynchronous PIO Store (APIOS) solves above problem by letting
the cpu continue executing next instruction much earlier than
synchronous PIO's approach.

      A new hardware, fit between cpu and Bus Unit Controller, is
required to support the asynchronous PIO (APIO).  The APIO hardware
consists of an APIO queue, a token pool control of outstanding I/O
operations for underneath bus(es) and a state machine.  The APIO
queue keeps the context of pending I/O instructions and also serves
as the re-issuing unit for recoverable errors.

The challenge for APIOS lies in the area of error recovery:

1.  Identifies the APIOS which caused the error

2.  Identifies the device and the user process which issued the APIOS

When an error detected, sometimes it is difficult to report this
error to the 'right' user because there does not have enough
information to link the error to the user process.  However, if an
APIOS is issued from the device driver there will have enough
information about the user process.  While APIOS is typically used in
kernel (device drivers), any user program can perform a APIOS
directly without using device drivers.  The main tasks for APIOS
recovery are as follows:

1.  Re-issues the APIOS and associated data if it is a recoverable
    hardware I/O error

2.  Provides an error code to the user of the device at the time of
    error if it is a non-recoverable I/O error.

      ASYNCHRONOUS BLOCK ARE...