ci_isr.c

<B>Digital的Unix操作系统VAX 4.2源码</B>

 *    Processor 3.  The thread processing the interrupt( T3 ) detects the error
 *    but is unable to lock the appropriate PCCB because it is locked by T2.
 *    It spins waits waiting for the PCCB lock to become available.
 * 4. T1 resumes execution, checks for errors, notices that an error exists,
 *    and attempts to lock the appropriate PCCB.  It too spin waits waiting for
 *    the PCCB lock( locked by T2 ) to become available.
 * 5. T2 checks its cached register contents for errors, discovers the soft
 *    error, clears/ignores it, unlocks the PCCB, and proceeds to determine
 *    whether responses are available for processing.  As there are responses
 *    available, it proceeds to process them even though a fatal error has
 *    occurred since response availability was initially signaled.  Thread
 *    execution is terminated following processing of all available responses.
 * 6. T1 wins the race with T3 for the PCCB lock.  After obtaining the lock, it
 *    caches register contents, checks them, and determines that a fatal error
 *    has occurred.  It proceeds to crash the local port, unlock the PCCB and
 *    terminate thread execution.
 * 7. T3 obtains the PCCB lock, caches register contents, checks them, and
 *    discovers the lack of an error.  It does not find an error because
 *    crashing of the local port by T1 involved disabling it, and the act of
 *    disabling a local port resets its registers.  Thus, when T3 caches
 *    register contents, it caches contents which do not display an error.  T3
 *    proceeds to unlock the PCCB and continue as if no error had been
 *    initially detected.  When T3 checks explicitly for response availability
 *    it finds none, once again begin the registers have been reset, and the
 *    interrupt is dismissed.
 *
 * Many scenarios such as this one are possible.  What is evident in all of
 * them is that a potential for side effects is introduced when error
 * interrupts occur while prior interrupts are currently being processed.
 * There is no way to eliminate them short of always locking the PCCB when an
 * interrupt occurs and this choice is unacceptable for performance reasons.
 * Fortunately, the impact of such side effects may be minimized and that has
 * been one of the guiding principles during development of the methodology for
 * processing errors in SMP environments.
 * 
 * One final note, differences do exist in how individual interrupt service
 * routines go about executing the general steps outlined above on initial
 * detection of errors.  This is to be expected because of the differences in
 * port interfaces between the various hardware port types.  If such
 * differences did not exist there would be no need for separate interrupt
 * service routines in the first place.  However, every CI port driver
 * interrupt service which must be prepared for execution within SMP
 * environments( cibci_isr(), cibca_isr(), cixcd_isr()) does follow these
 * general steps on detection of adapter reported errors.
 *
 * NOTE: This discussion pertains only to processing in SMP environments by the
 *	 primary interrupt service routines( ci780_isr(), cibci_isr(),
 *	 cibca_isr(), cixcd_isr()).  It does not pertain to any processing by
 *	 the special routine( ci_unmapped_isr()) used as interrupt service
 *	 handler by local ports temporarily without power( CI750/CI780//CIBCI
 *	 only ) or marked broken and permanently shutdown.  The special routine
 *	 itself contains a full description of any additional processing
 *	 requirements brought about by the introduction of SMP environments.
 */

/* Libraries and Include Files.
 */
#include		"../h/types.h"
#include		"../h/param.h"
#include		"../h/systm.h"
#include		"../h/vmmac.h"
#include		"../h/time.h"
#include		"../h/ksched.h"
#include		"../h/errlog.h"
#include		"../h/smp_lock.h"
#include		"../io/xmi/xmireg.h"
#include		"../io/scs/sca.h"
#include		"../io/scs/scaparam.h"
#include		"../io/scs/scamachmac.h"
#include		"../io/ci/cippdsysap.h"
#include		"../io/ci/cisysap.h"
#include		"../io/msi/msisysap.h"
#include		"../io/bi/bvpsysap.h"
#include		"../io/gvp/gvpsysap.h"
#include		"../io/uba/uqsysap.h"
#include		"../io/sysap/sysap.h"
#include		"../io/ci/cippdscs.h"
#include		"../io/ci/ciscs.h"
#include		"../io/msi/msiscs.h"
#include		"../io/bi/bvpscs.h"
#include		"../io/gvp/gvpscs.h"
#include		"../io/uba/uqscs.h"
#include		"../io/scs/scs.h"
#include		"../io/gvp/gvp.h"
#include		"../io/ci/cippd.h"
#include		"../io/ci/ciport.h"
#include		"../io/ci/ciadapter.h"

/* External Variables and Routines.
 */
extern	PB		*cippd_get_pb();
extern	u_long		gvp_queue_retry, ci_map_port();
extern	void		ci_crash_lport(), ci_dealloc_pkt(), ci_init_port(),
			ci_log_dev_attn(), ci_log_packet(), ci_rsp_handler(),
			ci_unmap_lport(), ci_update_cable(), cippd_crash_pb(),
			cippd_receive(), cippd_reqid_snt(), gvp_add_dg(),
			gvp_add_msg(), scs_data_done(), scs_dg_rec(),
			scs_msg_rec(), scs_msg_snt();


/*   Name:	ci_rsp_handler	- Process All CI Port Responses
 *
 *   Abstract:	This routine is responsible for processing all entries on a CI
 *		port's response queue.  It is invoked by a CI port interrupt
 *		service routine whenever a port places a response onto a
 *		previously empty response queue and requests an interrupt to
 *		notify the port driver of the queue transition.
 *
 *		There are several types of responses including:
 *
 *		1. Received packets.
 *		2. Locally initiated port commands with requested statuses.
 *		3. Locally initiated port commands with error statuses.
 *		4. Local port initiated commands with error statuses.
 *		5. Remotely initiated port commands with error statuses.
 *
 *   Inputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   pccb			- Port Command and Control Block pointer
 *   gvp_queue_retry		- Queuing failure retry count
 *
 *   Outputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   pb				- Path Block pointer
 *	ppd.cippd		-  CI PPD specific PB fields
 *	    pstatus.path_closed	-   Path already closed by port flag
 *   pccb			- Port Command and Control Block pointer
 *	pd.gvp.pqb.rspq		-  Port response queue
 *
 *   SMP:	The PCCB is locked for PB retrieval and prevents premature PB
 *		deletion.  This is required only when processing packet
 *		reported errors and when updating cable statuses following the
 *		reception of identification requests and loopback response
 *		packets.  PCCB addresses are always valid because these data
 *		structures are never deleted once their corresponding ports
 *		have been initialized.
 *
 *		PBs are locked to synchronize access and prevent premature
 *		deletion.  This is required only when processing packet
 *		reported errors and when updating cable statuses following the
 *		reception of identification requests.
 *
 *		Access to port response queues is by means of memory
 *		interlocking queuing instructions.
 */
void
ci_rsp_handler( pccb )
    register PCCB	*pccb;
{
    register PB		*pb;
    register GVPH	*cibp;

    /* Each response is removed from the specified port's response queue and
     * checked for errors.  These errors fall into one of the following
     * categories based upon the level of error recovery required.
     *
     * 1. Informational Errors.
     *	  The error is processed and response processing continues as if the
     *	  error had never been reported.  This may involve placing the response
     * 	  onto the appropriate free queue if this is what the port would have
     *	  done itself had it not needed to report the error.  Errors classified
     *	  as informational include:
     *
     *		- Cable Failed but Port Command Succeeded.  This status is
     *		  returned whenever a cable fails during the successful
     *		  execution of those local port commands which initiate packet
     *		  transmission and do not explicitly specify the cable to be
     *		  used.  Error processing consists of updating PB cable status
     *		  and logging any good->bad cable transition.  Such processing
     *		  is required only for fully established paths.
     *
     *		- Lack of a Good Cable Forced Local Port Command Failure.  This
     *		  status may be returned by locally executed REQID and SNDLB
     *		  port commands.  Both commands initiate packet transmission
     *		  over specific cables; however, the meaning of this status is
     *		  different for each command as is the error processing on
     *		  detection of this status.
     *
     *		  SNDLB: A NOPATH status indicates failure to loopback to the
     *			 local port over the specified cable.  No error
     *			 processing is required and the packet is immediately
     *			 disposed of.  Note that final disposition of the
     *			 packet is NOT the same as if the error had never
     *			 occurred.  There is no need to queue the packet to
     *			 the appropriate local port datagram free queue for
     *			 reception of a loopback response because no response
     *			 is forthcoming due to failure of the port command.
     *			 Instead the packet is just deallocated.
     *
     *		  REQID: A NOPATH status indicates failure of the specified
     *		  	 cable and is considered only informational in nature
     *		  	 whenever no record of the path currently exists within
     *		  	 the system-wide configuration database, the path is
     *			 not established, or at least one other operational
     *		  	 cable is still known.  Error processing consists of
     *			 updating the PB's cable status, logging any good->bad
     *		  	 cable transition, and forcing transmission of a REQID
     *		  	 over the other cable to determine if it too is bad.
     *			 Such processing is required only for fully established
     *			 paths.
     *
     *		- Unrecognized Packet.  This status is generated whenever the
     *		  port receives a SNDSTRT or SNDRST maintenance packet while in
     *		  the enabled state.  Such statuses are not totally unexpected.
     *		  Remote MSCP clients request resetting and restarting of local
     *		  ports whenever their logical SCS connections to the local
     *		  MSCP server times out and local ports are always to be found
     *		  in the enabled state.  Error processing consists of just
     *		  disposing of the response.
     *
     * 2. Severe Errors.  
     *    The error is logged, the appropriate path is crashed and the response
     *	  is disposed of either by deallocating the buffer( locally executed
     *	  command packets with the R bit set ) or adding it to the appropriate
     *	  port free queue( received packets, local port generated port command
     *	  packets and locally executed port command packets with the R bit
     *	  clear ).  Response processing continues with the next response on the
     *	  queue.  Errors classified as severe include:
     *
     *		- Virtual Circuit Closed by Previous Command.  This status may
     *		  be returned by locally executed port commands which initiate
     *		  packet transmission over a virtual circuit.  The current
     *		  response is just disposed of.  There is no need to log the
     *		  event or crash the path because these actions have already
     *		  taken place.
     *
     *		- Lack of a Good Cable Forced Local Port Command Failure.  This
     *		  status may be returned by any locally executed port commands
     *		  which initiate packet transmission.  The occurrence of such
     *		  an error may close the associated virtual circuit.  The path
     *		  is crashed provided it has not already failed.  Additional
     *		  error processing is also required in the case of those REQIDs
     *		  which had attempted packet transmission over specific cables
     *		  previously thought to be good.  Such processing includes
     *		  updating the PB's cable status and logging any good->bad
     *		  cable transition before logging the error and crashing the
     *		  path.
     *
     *		- Buffer Memory System Error Occurred.  This status may be
     *		  returned within block data transfer packets which return
     *		  status about block data transfer operations.  The occurrence
     *		  of such an error also automatically closes the associated
     *		  virtual circuit.
     *
     *		- Packet Size Violation.  This status may be returned by
     *		  remotely initiated locally executed port commands which
     *		  initiate packet transmission and also within received
     *		  packets.  The occurrence of such an error may also
     *		  automatically close the associated virtual circuit.
     *
     *		- Unrecognized Packet.  This status is generated whenever the
     *		  port receives a packet with an illegal opcode or flags field,
     *		  or an invalid source source address, or a maintenance packet
     *		  when the port is in the enabled state.
     *
     *		- Out-of-Sequence Message Received.  This status may only be
     *		  returned within received packets.  It MAY now be obsolete.
     *		  It is not documented and might just have been used in some
     *		  interim CI ucode for debugging purposes.  Presumably, the
     *		  occurrence of such an error also automatically closes the
     *		  associated virtual circuit.
     *
     *		- Message Received with Closed Virtual Circuit Descriptor.
     *		  This status may only be returned only within received
     *		  packets.  It MAY now be obsolete.  It is not documented and
     *		  might just have been used in some interim CI ucode for
     *		  debugging purposes.  Presumably, the occurrence of such an
     *		  error also automatically closes the associated virtual
     *		  circuit.
     *
     * 3. Fatal Errors.
     *	  The local port is crashed and response processing is immediately
     *	  terminated.  The response is disposed of and any responses remaining
     *	  on the queue are flushed during crashing of the port.  Errors
     *    classified as fatal include:
     *
     *		- Invalid Local Buffer Name.  This status may be returned by
     *		  local block data transfer port commands.  The occurrence of
     *		  such an error also automatically closes the associated
     *		  virtual circuit.
     *
     *		- Local Buffer Length Violation.  This status may be returned
     *		  by local block data transfer port commands.  The occurrence
     *		  of such an error also automatically closes the associated
     *		  virtual circuit.
     *
     *		- Access Control Violation during Local Buffer Access.  This
     *		  status may be returned by local block data transfer port
     *		  commands.  The occurrence of such an error also automatically
     *		  closes the associated virtual circuit.
     *
     *		- Packet Size Violation.  This status may be returned by
     *		  locally executed port commands which initiate packet
     *		  transmission.  In addition, loopback responses( LBREC ) may
     *		  also return this status.  These responses are both locally
     *		  initiated and executed because of how loopback is used by the
     *		  CI port driver.  The occurrence of such an error may also
     *		  automatically close the associated virtual circuit.
     *
     *		- Invalid Destination Port.  This status may be returned by
     *		  those locally and remotely initiated, locally executed port
     *		  commands which require specification of a destination port.
     *		  The occurrence of such an error may also automatically close
     *		  the associated virtual circuit.
     *
     *		- Unknown Local Port Command.  This status is generated