ci_isr.c

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

#ifndef	lint
static char *sccsid = "@(#)ci_isr.c	4.3	(ULTRIX)	10/16/90";
#endif	lint

/************************************************************************
 *                                                                      *
 *                      Copyright (c) 1988 - 1989 by                    *
 *              Digital Equipment Corporation, Maynard, MA              *
 *                      All rights reserved.                            *
 *                                                                      *
 *   This software is furnished under a license and may be used and     *
 *   copied  only  in accordance with the terms of such license and     *
 *   with the  inclusion  of  the  above  copyright  notice.   This     *
 *   software  or  any  other copies thereof may not be provided or     *
 *   otherwise made available to any other person.  No title to and     *
 *   ownership of the software is hereby transferred.                   *
 *                                                                      *
 *   The information in this software is subject to change  without     *
 *   notice  and should not be construed as a commitment by Digital     *
 *   Equipment Corporation.                                             *
 *                                                                      *
 *   Digital assumes no responsibility for the use  or  reliability     *
 *   of its software on equipment which is not supplied by Digital.     *
 *                                                                      *
 ************************************************************************
 *
 *
 *   Facility:	Systems Communication Architecture
 *		Computer Interconnect Port Driver
 *
 *   Abstract:	This module contains Computer Interconnect Port Driver( CI )
 *		interrupt service routines and functions.
 *
 *   Creator:	Todd M. Katz	Creation Date:	January 14, 1986
 *
 *   Function/Routines:
 *
 *   ci_rsp_handler		Process All CI Port Responses
 *   ci_unmapped_isr		Unmapped CI Adapter Interrupt Service Routine
 *   ci780_isr			CI750/CI780 Interrupt Service Routine
 *   cibca_isr			CIBCA-AA/CIBCA-BA Interrupt Service Routine
 *   cibci_isr			CIBCI Interrupt Service Routine
 *   cixcd_isr			CIXCD Interrupt Service Routine
 *   cikmf_isr			CIKMF Interrupt Service Routine
 *
 *   Modification History:
 *
 *   16-Oct-1990	Pete Keilty
 *	Changed smp_lock cidevice locking to use the new macros define
 *	in ciscs.h. Also changed the how registers are accessed only once.
 *	Also added DELAY( 1000 ) after writing Xber register because of
 *	the CIXCD XMOV bug.
 *
 *   16-Jul-1990	Pete Keilty
 * 	Add smp_lock lk_cidevice in the cixcd_isr routine for CIXCD,
 *	software workaround for XMOV hardware bug of back to back register
 *	accesses the first one a read the second a write to a software
 *	register. Psr read Psrcr write.
 *
 *   15-Jun-1990	Pete Keilty
 *	Added temporary smp lock lk_cidevice for CIXCD because of XMOV bug.
 *	
 *   06-Jun-1990	Pete Keilty
 *	Preliminary added CIKMF ( dash ) cikmf_isr() routine.
 *
 *   08-Dec-1989	Pete Keilty
 *	1. Use new macro Get_pgrp() to get port node number until 
 *	   full subnode addressing is done.
 *	2. Mask off upper two bits of opcode. Bit 7 is the new explicit
 *	   address bit of opcode not used for now.
 *	3. Changes cixcd_isr() routine to handle errors correctly.
 *
 *   19-Sep-1989	Pete Keilty
 *	1. Add XCD support, remove XCB.
 *	2. Add pccb to Pd_to_ppd macro.
 *
 *   25-May-1989	Pete Keilty
 *	Add new macro WBFLUSH for mips cpu's.
 *
 *   20-May-1989	Pete Keilty
 *	Added support for mips risc cpu's 
 *	Changed splx( IPL_SCS ) to new macro Splscs()
 *
 *   06-Apr-1989	Pete Keilty
 *	Added include file smp_lock.h
 *
 *   24-Mar-1989	Todd M. Katz		TMK0006
 *	Fix a bug introduced by TMK0005.  Following crashing of an established
 *	path to a remote port found to be in an improper state, the PB was
 *	being unlocked twice instead of unlocking both the PB and PCCB.
 *
 *   13-Jan-1989	Todd M. Katz		TMK0005
 *	1. Whenever an IDREC is received over an established path( path state
 *	   == PS_OPEN ) a check is made as to whether the remote port state has
 *	   transitioned from PS_ENAB/PS_ENAB_MAINT.  The path is crashed if it
 *	   has.  However, this check was not being correctly made.  The remote
 *	   port state in the PB was being checked, not the state within the
 *	   IDREC itself.  Also, the PCCB was not being unlocked following path
 *	   crashing.  Fix this error path.
 *	2. Include header file ../vaxmsi/msisysap.h.
 *
 *   22-Aug-1988	Todd M. Katz		TMK0004
 *	1. Rename the Informational Event( ES_I ) mnemonic from IE -> I.
 *	2. The following Informational Events( ES_I ) have been defined as
 *	   Warning Events( ES_WE ): POWER, STRAY.
 *	3. The following Informational Events( ES_I ) have been defined as
 *	   Fatal Error Events( ES_FE ): NOCI
 *	4. The following former CI path crash codes are now defined as Error
 *	   Events( ES_E ): NOCABLES, RPORTSTATE, CLOSEDVCD; and Severe Error
 *	   Events( ES_SE ): INVRPKTSIZE, OSEQMSG, UNRECPKT, BMSE.
 *	5. The following CI local port crash codes are now defined as Severe
 *	   Error Events( ES_SE ): PORTERROR, MFQE, MSE, DSE, SANITYTIMER,
 *	   PARITY, BIPARITY, BIERROR, BIMSE, POWER, POWERUP, UNKOPCODE,
 *	   INVOPCODE, UNKSTATUS, ABORTPKT, UNKCMD, INVDPORT, INVLPKTSIZE,
 *	   BACCVIO, INVBSIZE, INVBNAME Fatal Error Events( ES_FE ): NOCI. The
 *	   local port crash severity modifier is applied by ci_crash_lport()
 *	   but only when the crashed local port is not in the process of being
 *	   cleaned up from a previous crash.
 *	6. Modify ci780_isr() and cibci_isr() to log a fatal( FE_PORTERROR )
 *         instead of a severe( SE_PORTERROR ) error event when a broken link
 *	   module( L0100 ) is discovered.
 *	7. Refer to error logging as event logging.
 *	8. Physical errors on specific paths are now processed by first logging
 *	   the specific error and then crashing the specific path with a
 *	   generic path crash code appropriate to event severity.  Formerly,
 *	   just the path was crashed.  This required a unnecessairly convoluted
 *	   callback scheme to eventually allow the CI port driver to log the
 *	   port driver specific path related event.
 *
 *   03-Jun-1988	Todd M. Katz		TMK0003
 *	1. Create a single unified hierarchical set of naming conventions for
 *	   use within the CI port driver and describe them within ciport.h.
 *	   Apply these conventions to all names( routine, macro, constant, and
 *	   data structure ) used within the driver.  Restructure the driver to
 *	   segregate most CI family and port type specific code into separate
 *	   routines.  Such restructuring requires splitting ci_isr() into
 *	   ci780_isr() and cibci_isr().  The former handles interrupts for
 *	   CI750/CI780 local ports while the latter is responsible for CIBCI
 *	   local port interrupts.
 *	2. Add support for the CIXCB hardware port type by:
 *		1) Adding routine cixcb_isr() to handle CIXCB interrupts.
 *		2) Adding include file ../vaxxmi/xmireg.h.
 *	3. Eliminate all locking from ci780_isr().  CI750 and CI780 local ports
 *	   never exist in SMP environments and so there is never any need to
 *	   lock any data structures.
 *	4. Modify cibci_isr() and cibca_isr() to properly synchronize access to
 *	   port register contents when processing errors.  Such synchronization
 *	   is required in SMP environments and is achieved through a PCCB lock.
 *	5. Modify the circumstances under which local ports are unmapped.
 *	   Unmapping is now done only when the local port adapter itself loses
 *	   power( CI750/CI780/CIBCI only ) or the port is marked broken and is
 *	   permanently shutdown.  Formerly, unmapping was done whenever a local
 *	   port was crashed, but before its re-initialization commenced; and
 *	   just immediately prior to its initial initialization.  This change
 *	   requires appropriate modifications to the comments of the routines
 *	   ci780_isr(), cibci_isr(), and cibca_isr().  The routine
 *	   ci_unmapped_isr() has also been extensively re-written to more
 *	   accurately reflect the new circumstances under which it can be
 *	   expected to be invoked.
 *
 *   02-Jun-1988	Ricky S. Palmer
 *      Removed inclusion of header file ../vaxmsi/msisysap.h
 *
 *   09-Apr-1988	Todd M. Katz		TMK0002
 *	Add support for the CIBCA-BA hardware port type.  Differentiate
 *	CIBCA-BA from CIBCA-AA hardware ports when necessary; otherwise, refer
 *	to both types as just CIBCA ports.
 *
 *   08-Jan-1988	Todd M. Katz		TMK0001
 *	Formated module, revised comments, increased generality and
 *	robustness, made CI PPD and GVP completely independent from underlying
 *	port drivers, restructured code paths, and added SMP support.
 */

/*			Interrupt Processing Philosophy
 *
 * The CI port driver's interrupt processing philosophy is to optimize its
 * primary interrupt service routines for response processing.  This is because
 * the placement of responses by local CI ports onto previously empty response
 * queues is the most like cause of interrupts.  Response processing is
 * optimized for by minimizing the number of checks made for errors.  It is
 * necessary to make some checks because most port detected errors represent
 * very serious situations which can only be recovered from by crashing and
 * re-initialization of the affected port.  In such instances responses are
 * never processed.  Instead, additional time is spent determining the exact
 * cause of the error before the local port is crashed.
 *
 * One major consequence of the minimization of error detection arising from
 * the optimization of response processing is the use of separate routines as
 * interrupt service handlers by different local CI ports and for all CI ports
 * when they are unmapped.  Different hardware port types require different
 * checks to be made for errors and the requirements for processing of
 * interrupts by unmapped local ports are radically different from the
 * requirements of mapped ones.  Whenever processing requirements sufficiently
 * diverge the CI port driver employs a different routine as interrupt service
 * handler for the local port.  
 */

/* 		    Interrupt Processing in SMP Environments
 *
 * In a SMP environment it is conceivable that multiple threads may be brought
 * into existence to simultaneously process interrupts.  For example, a local
 * port may signal an interrupt to report response availability.  While
 * processing of this initial interrupt is proceeding the same port may signal
 * another interrupt to again report response availability.  This scenario is
 * possible because the port status register in which response availability is
 * reported is released prior to initiating response processing.  It is also
 * possible that a second or even third interrupt may be signaled by the same
 * port to report an error either within the port status register or a bus
 * specific error register.  The end result is the same, each interrupt
 * potentially activates a new thread, each thread executes the same
 * ( appropriate ) interrupt service routine, and all such threads may be
 * simultaneously active( on separate processors ).
 *
 * The existence of multiple threads all executing the same interrupt service
 * routine never poses a problem provided all interrupts were signaled by the
 * local port to report response availability.  Only one caveat exists: it may
 * not be assumed that the absence of errors implies availability of responses
 * awaiting processing.  The existence of responses is always explicitly
 * checked for before the port status register is released and responses are
 * processed.
 *
 * The situation is not so straightforward when adapter reported errors are
 * involved.  The major source of complexity originates in the following facts:
 *
 * 1. Not all adapter reported errors are equal, an error hierarchy actually
 *    exists: soft error -> port( PSR ) error -> bus( non-port ) error in
 *    ascending order.
 * 2. Occurrence of a new interrupt wipes out the state of previous interrupts(
 *    interrupt state is reported within bus and port registers ).
 *
 * The error hierarchy allows an interrupt reporting response availability, to
 * be followed by an interrupt reporting a soft error, to be followed by an
 * interrupt reporting a port error, to be followed by an interrupt reporting a
 * bus error with the occurrence of each interrupt wiping out the state of
 * prior interrupts.  This sequence of ever more serious error interrupts would
 * never pose a problem in a single processor environment where only one
 * interrupt is processed at a time and is processed to completion.
 * Unfortunately, this is not the case in a SMP environment.  Multiple
 * interrupts may be processed simultaneously, some signaled to report
 * response availability while others to report errors.  Each new interrupt
 * potentially affects how previous interrupts are processed by completely
 * independent and concurrent threads.  Even the relative order in which
 * interrupts are processed to completion may not reflect the order in which
 * they were initially signaled due to temporary suspension of some threads
 * for handling of higher priority interrupts.
 * 
 * While processing of error interrupts is potentially a very complicated
 * situation in SMP environments it is by no means a hopeless one.  It is made
 * manageable by having the appropriate interrupt service routine execute the 
 * following general steps once it detects an adapter reported error:
 *
 * 1. The PCCB is locked to synchronize access to port registers.
 * 2. Bus and port register register contents are cached.
 * 3. A second determination is made as to whether an error is being reported
 *    by the adapter using the cached register contents.
 * 4. Interrupt processing is allowed to proceed( after unlocking the PCCB ) if
 *    no error is detected on the second check for errors.
 * 4. Soft errors are cleared or ignored and interrupt processing is allowed to
 *    proceed( after unlocking the PCCB ) as if no error had been detected.
 * 5. Hard errors crash the local port and terminate interrupt processing(
 *    after unlocking the PCCB ).
 *
 * The major benefit derived from executing this general sequence is that
 * threads complete error processing in the order in which they obtain the
 * appropriate PCCB lock after detecting an error.  This adds back a
 * deterministic element to error processing in SMP environments.
 *
 * A second benefit derived from this sequence is the reduction in the effect
 * new error interrupts have on existing threads attempting to process previous
 * adapter reported errors.  This reduction is achieved through utilization of
 * cached register contents in the determination of the nature of the reported
 * error.  It allows error processing to proceed in a consistent fashion.  New
 * error interrupts may still occur and still change register contents;
 * however, processing of new interrupts by newly spawned threads no longer has
 * major affect on error processing by existing threads.
 *
 * Use of cached register contents is not without its disadvantages though.
 * While determination of the nature of the error proceeds from cached
 * contents, logging of the event utilizes the contents of the registers
 * themselves.  Thus, registers logged may bear no relation to the event logged
 * when multiple virtually simultaneous( ie - one after the other ) errors
 * occur.  Such synchronicity should be extremely rare and does not outweigh
 * the advantages of using cached register contents.
 *
 * Use of cached register contents also does not completely eliminate the
 * effect of new error interrupts on processing of previous interrupts by
 * completely independent and concurrent threads.  This can best be observed
 * through use of a hypothetical example.  Consider the following set of time
 * sequential virtually simultaneous interrupts originated on the same local
 * port:
 *
 * 1. Interrupt to report response availability occurs.
 * 2. Interrupt to report soft error occurs.
 * 3. Interrupt to report a fatal error occurs.
 *
 * The following scenario may be concocted in order to demonstrate that while
 * side effects on interrupt processing resulting from new error interrupts in
 * SMP environments may be minimized, it may never be completely eliminated.
 *
 * 1. The interrupt reporting response availability occurs and is received by
 *    Processor 1.  Before the thread processing the interrupt( T1 ) has the
 *    opportunity to check for errors it is pre-empted by an interrupt with a
 *    higher priority.
 * 2. The interrupt reporting the soft error occurs and is received by
 *    Processor 2.  The thread processing the interrupt( T2 ) detects the
 *    error, locks the appropriate PCCB, and caches register contents.
 * 3. The interrupt reporting the fatal error occurs and is received by