Specifications

Completing an I/O Request and Handling Timeouts
8.1 I/O Postprocessing
8.1.2.3 Returning Control to the Operating System
Finally, the driver fork process returns control to the system by invoking the
REQCOM macro to complete the I/O request. REQCOM calls the system routine
IOC_STD$REQCOM. IOC_STD$REQCOM locates the address of the I/O request
packet (IRP) corresponding to the I/O operation in the device’s UCB (UCB$L_
IRP). It then writes the two longwords of completion status contained in R0 and
R1 into the media field of the IRP$L_IOST1 and IRP$L_IOST2).
IOC_STD$REQCOM then inserts the IRP in the local processor’s I/O-
postprocessing queue and requests a software interrupt at IPL$_IOPOST from
the current processor so the postprocessing begins when IPL drops below IPL$_
IOPOST.
If the error-logging bit is set in the device’s UCB (UCB$V_ERLOGIP in UCB$L_
STS), IOC_STD$REQCOM obtains the address of the error message buffer from
the UCB (UCB$L_EMB). It then writes the following information into the error
buffer:
• Final device status (UCB_DEVSTS)
• Final error count (UCB$B_ERTCNT)
• Maximum error retry count for the driver
• Two longwords of completion status (R0 and R1)
To release the error message buffer, IOC_STD$REQCOM calls
ERL$RELEASEMB.
If any IRPs are waiting for driver processing, IOC_STD$REQCOM dequeues an
IRP from the head of the queue of packets waiting for the device unit (UCB$L_
IOQFL), and transfers control to IOC_STD$INITIATE. IOC_STD$INITIATE
initiates execution of this I/O request in the driver’s fork process, by activating
the driver’s start-I/O routine.
Otherwise, IOC_STD$REQCOM clears the unit-busy bit in the device’s UCB
status longword (UCB$V_BSY in UCB$L_STS) and transfers control to IOC_
STD$RELCHAN to release the controller channel in case the driver failed to do
so. IOC_STD$RELCHAN, in turn, returns control to the caller of the driver fork
process (if the fork process issued the REQCOM macro). This is generally the
system fork dispatcher. The fork dispatcher releases the fork lock, restores saved
registers, and dismisses the fork IPL software interrupt with an REI instruction.
The remaining steps in processing the I/O request are performed by system I/O
postprocessing.
8.2 Timeout Handling Routines
The operating system transfers control to the driver’s timeout handling routine if
a device unit does not request an interrupt within the time limit specified in the
invocation of the wait-for-interrupt macro. Among its other activities, the system
software timer fork routine running at IPL$_SYNCH, scans UCBs once every
second to determine whether a device has timed out.
When the software timer interrupt service routine locates a device that has timed
out, the routine calls the driver’s timeout handling routine by performing the
following steps:
8–3