Browse Prior Art Database

I/O Device Capability Lazy Switch

IP.com Disclosure Number: IPCOM000146284D
Original Publication Date: 2007-Feb-09
Included in the Prior Art Database: 2007-Feb-09
Document File: 2 page(s) / 77K

Publishing Venue

IBM

Abstract

I/O Device Capability Lazy Switch. Using software to cool the effects of hardware problems.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 60% of the total text.

Page 1 of 2

I/O Device Capability Lazy Switch

Implementing new device capabilities introduce a potential for inserting hardware and software defects as well as the promised new function. It is very difficult to identify or even discover these incompatibilities during test because they can occur on infrequent error recovery paths. This fact is unsettling for a user who wants to utilize the new I/O capability, especially considering some hardware and software defects require that a production workload be running in order to surface. In a production system if a problem occurs an unscheduled outage may be necessary to deactivate the new function via startup parameters or worst regression of installable service. Of course one could simply deactivate the service with a switch, but for the case of I/O consider the following scenario.

Capability
Test

User of I/O
Capability

Call

  I/O
Manager

Software
Device
Representation

FAIL

  I/O Queue
Element using
new capability

  I/O Queue
Element using
new capability

  I/O Queue
Element using
new capability

Update

Input

I/O Driver
with new

capability
Processing.

FAIL

Device

DATA

Capability
Test

The two capability tests are used to prevent users in error to exploit the new capability without verifying that the capability exists. However for the purpose of data integrity, we should allow queued I/O to complete successfully once between the capabi...