cippd_error.c

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

				 Scaaddr_low( pb->pinfo.rport_addr ));
	    } else {
		( void )cprintf( "? )\n" );
	    }
	    break;

	case CF_SWTYPE:
	    ( void )cprintf( "\n\t- remote system software type: %4s\n",
			     &pccb->Elogopt.rswtype );
	    break;

	case CF_SYSAPNAME:
	    ( void )cprintf( "\n\t- local sysap name: %16s\n",
			     pccb->Elogopt.sysapname );
	    break;

	case CF_LPORTNAME:
	    ( void )cprintf( "\n\t- local port name: %4s\n",
			     &pccb->lpinfo.name );
	    break;

	case CF_RPORT:
	    ( void )cprintf( "( remote port: %u )\n",
			     (( pb ) ? Scaaddr_low( pb->pinfo.rport_addr )
				     : pccb->Elogopt.port_num ));
	    break;
    }
}

/*   Name:	cippd_csyslev	- Process CI PPD Common System Level Events
 *
 *   Abstract:	This routine processes CI PPD common system level events.  Such
 *		events are associated with specific remote systems and not with
 *		specific ports on those systems.  They are normally ascertained
 *		indirectly from received CI PPD datagrams or messages although
 *		such packets are never passed to this routine.
 *
 *		CI PPD common system level event processing has a single goal:
 *		to determine whether or not a reported event should be logged.
 *		This determination is based upon whether the event has been
 *		previously reported for the system in question.  If it has,
 *		logging of new event reports is bypassed.  If it has not, the
 *		event is logged and kept track of.  This state is allowed to
 *		persist until the condition underlying the event is reported to
 *		no longer be associated with the system.
 *
 *		To allow this goal to be met this routine is called both to
 *		report the discovered presence and absence of the following
 *		CI PPD common system level events:
 *
 *		1. E_TALKDOWN  - CI PPD protocol mismatch: Can not talk down
 *		2. W_TALKUP    - CI PPD protocol mismatch: Attempt to talk up
 *		3. W_BADSWTYPE - Remote system has unsupported software type
 *
 *		The first of these events is serious as its severity level
 *		indicates.  The local CI PPD never attempts to talk down to a
 *		remote CI PPD running an earlier CI PPD protocol version.  The
 *		latter two events are less serious and require only warnings to
 *		be given.  Communication with the remote CI PPD is allowed to
 *		continue( or at least be attempted ).
 *
 *		NOTE: The static structure, event_to_flag[], within this
 *		      routine must be updated for each and every new common
 *		      system level event.
 *
 *   Inputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   cippd_sli_db		- CI PPD Common Sys Level Logging Info Database
 *   event			- W_BADSWTYPE, W_TALKUP, E_TALKDOWN
 *   sb				- System Block pointer
 *   option			- SET or CLEAR
 *   pccb			- Port Command and Control Block pointer
 *	ppd.cippd		-  CI PPD specific PCCB fields
 *	    elogopt.protocol	-   CI PPD protocol information
 *	    elogopt.rswtype	-   Remote system software type
 *
 *   Outputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   cippd_sli_db		- CI PPD Common Sys Level Logging Info Database
 *
 *   SMP:	The SCA database is locked( EXTERNALLY ) for both traversal and
 *		modifications of the CI PPD common system level logging
 *		informational database, and to prevent SB deletion.
 *
 *		The PCCB is locked( EXTERNALLY ) as required by cippd_log_sys()
 *		in case logging becomes necessary.
 *
 *		SBs NEVER require locking.  Neither do SLIBs.
 */
void
cippd_csyslev( pccb, sb, event, option )
    PCCB			*pccb;
    register SB			*sb;
    register u_long		event;
    u_long			option;
{
    register cippd_slibq	*slib;
    register u_long		flag, i;
    static struct {
	u_long	event_code;
	u_long	event_flag;
    } event_to_flag[] = {
	{ W_BADSWTYPE,	SWTYPE	 },
	{ W_TALKUP,	TALKUP	 },
	{ E_TALKDOWN,	TALKDOWN },
	{ 0,		0	 }
	};

    /* Processing of common system level events proceeds as follows:
     *
     * 1. The common system level event code is verified.
     * 2. The CI PPD system level logging information database is searched for
     *    the SLIB corresponding to the remote system associated with the event
     *	  being processed.
     * 3. The event is processed according to whether its presence or absence
     *	  is being reported.
     *
     * A bitmask is retrieved if the common system level event code is
     * satisfactorily verified( Step 1 ).  This mask designates the bit within
     * the logging flags field of the appropriate SLIB which is to be set or
     * cleared according to whether the event being reported is present or
     * absent.  A panic occurs whenever code verification is presented with an
     * unknown common system level event and fails.
     *
     * Failure to retrieve a SLIB( Step 2 ) indicates that no common system
     * level events were previously associated with the system in question.
     * This is not a problem but represents the normal situation especially
     * when it is the absence of a event being reported.  However, when it is
     * the presence of an event being reported, failure to retrieve a SLIB
     * does trigger allocation of a new SLIB to represent the system in
     * question.  This SLIB is inserted into the SLIB database from which it is
     * retrieved during processing of subsequent event reports.
     *
     * Processing of event absences( Step 3 ) is dependent upon whether a SLIB
     * corresponding to the system in question was retrieved( Step 2 ).  If one
     * was not, event processing is immediately terminated.  This is the normal
     * and preferred outcome of event processing.  If a SLIB was retrieved then
     * the bit corresponding to the absent event within the the logging flags
     * field of the retrieved SLIB is cleared.  The SLIB is itself deallocated
     * whenever the corresponding system is discovered to be currently devoid
     * of all reported common system level events.  The SLIB is removed from
     * the SLIB database before deallocation.
     *
     * Processing of event presences( Step 3 ) involves determining whether
     * existence of the reported event was previously associated with the
     * system in question.  This is accomplished by checking the appropriate
     * bit within the logging flags field of the retrieved SLIB.  If the bit is
     * set then the event was previously reported and processing of the current
     * report is immediately terminated.  If the bit is not set then existence
     * of the event was not previously detected.  The bit is set to indicate
     * observation of the event, and the occurrence of the event is logged.
     *
     * NOTE: New SLIB allocations can fail.  Such failures do not substantially
     *	     affect event processing and event detections continue to be
     *	     logged.  What is affected is the keeping track of reported events
     *	     for the system in question.  All subsequent reports of any events
     *	     associated with the system result in event loggings.  This state
     * 	     persists until such time as a SLIB can be successfully allocated,
     *       even though such multiple loggings runs contrary to the goal of
     *	     common system level event processing.
     */
    for( flag = 0, i = 0; event_to_flag[ i ].event_code; i++ ) {
	if( event_to_flag[ i ].event_code == Mask_esevmod( event )) {
	    flag = event_to_flag[ i ].event_flag;
	    break;
	}
    }
    if( flag == 0 ) {
	( void )panic( PPDPANIC_UNKSLC );
    }
    for( slib = cippd_sli_db.flink;
	 slib != &cippd_sli_db;
	 slib = slib->flink ) {
	if( Comp_node( Slib->node_name, sb->sinfo.node_name )) {
	    break;
	}
    }
    if( slib == &cippd_sli_db ) {
	if( option == CLEAR ) {
	    return;
	} else {
	    KM_ALLOC( slib,
		      cippd_slibq *,
		      sizeof( CIPPD_SLIB ),
		      KM_SCA,
		      KM_NOW_CL_CA )
	    if( slib ) {
		Slib->size = sizeof( CIPPD_SLIB );
		Slib->type = DYN_CIPPDSLIB;
		Move_node( sb->sinfo.node_name, Slib->node_name )
		Insert_entry( Slib->flink, cippd_sli_db )
	    }
	}
    }
    if( option == CLEAR ) {
	if(( Slib->log_flags &= ~flag ) == 0 ) {
	    Remove_entry( Slib->flink )
	    KM_FREE(( char * )Slib, KM_SCA )
	}
    } else {
	if( slib == NULL || ( Slib->log_flags & flag ) == 0 ) {
	    if( slib ) {
		Slib->log_flags |= flag;
	    }
	    ( void )cippd_log_sys( pccb, sb, NULL, event );
	}
    }
}

/*   Name:	cippd_log_path	- Event Log CI PPD Path Specific Events
 *
 *   Abstract:	This routine logs CI PPD path specific events.  It also
 *		currently logs CI PPD remote port specific events.  All of
 *		these events are normally ascertained indirectly from a
 *		received CI PPD datagram or message.  The event is also
 *		optionally logged to the console.
 *
 *		Eight classes of events are currently logged by this routine:
 *
 *		1. Path establishments.
 *		2. Path establishment failures.
 *		3. Path failures due to local port failures.
 *		4. System-wide database conflicts.
 *		5. SCS and CI PPD protocol violations.
 *		6. Local SYSAP requests for path termination.
 *		7. Remote system requests for path termination.
 *		8. Remote system requests for path restarts( ie - breakage and
 *		   re-establishment of an existing path ).
 *
 *		Of all of these events only the system-wide database conflicts
 *		are considered CI PPD remote port specific events.  The
 *		remaining events logged by this routine are CI PPD path
 *		specific events.
 *
 *		Many of these events represent serious errors and are logged to
 *		save relevant information before drastic steps are attempted to
 *		resolve them.  Others are less serious and are logged only to
 *		give a warning or for informational purposes only.
 *
 *		NOTE: While all events logged therein arise indirectly from CI
 *		      PPD packets, the logging of each event does not
 *		      necessarily involve logging of the packet itself.
 *
 *		NOTE: Only packets with CI PPD headers( CI PPD datagrams or
 *		      messages ) may be passed to this routine.
 *
 *		NOTE: This routine does NOT log events arising external to the
 *		      CI PPD with the exception of those SCS error and severe
 *		      error events which are candidates for application of the
 *		      path crash severity modifier( ESM_PC ).  It also does NOT
 *		      currently log any CI PPD events which are candidates for
 *		      application of the local port crash severity modifier(
 *		      ESM_LPC ).
 *
 *   Inputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   cippdbp			- Address of CI PPD header( OPTIONAL )
 *   event			- Event code
 *   lscs			- Local system permanent information
 *   pb				- Path Block pointer( OPTIONAL )
 *   pccb			- Port Command and Control Block pointer
 *	ppd.cippd		-  CI PPD specific PCCB fields
 *	    elogopt.dbcoll	-   Database collision event information
 *          elogopt.port_num	-   Remote port number
 *				     ( required ONLY when PB not provided )
 *	    elogopt.sysapname	-   Name of local SYSAP
 *
 *   Outputs:
 *
 *   IPL_SCS			- Interrupt processor level
 *   pccb			- Port Command and Control Block pointer
 *	lpinfo.nerrs		-  Number of errors on port
 *
 *   SMP:	The PCCB is locked( EXTERNALLY ) to synchronize access and
 *		prevent premature PB deletion when a PB is provided.
 *
 *		PBs do NOT require locking when provided because only static
 *		fields are accessed.  SBs NEVER require locking.
 */
void
cippd_log_path( pccb, pb, cippdbp, event )
    PCCB			*pccb;
    PB				*pb;
    register GVPPPDH		*cippdbp;
    register u_long		event;
{
    register struct el_rec	*elp;
    register u_long		opt_size, size;
    register SB			*sb = (( pb ) ? pb->sb : NULL );
    register u_long		severity = Eseverity( event );

    /* The steps involved in logging CI PPD path specific and remote port
     * events include:
     *
     * 1. Logging the event to the console.
     * 2. Incrementing the counter of local port errors.
     * 3. Computing the size of the application portion of the event log
     *	  record.
     * 4. Allocating an event log record and initializing the record's sub id
     *	  packet fields.
     * 5. Initializing the portion of the record common to all CI PPD events.
     * 6. Initializing the portion of the record reserved for identifying
     *    specific CI PPD paths.
     * 7. Moving any optional information into the record.
     * 8. Validating the event log record.
     *
     * The ability of the CI PPD to log the event is validated during console
     * logging( Step 1 ).  A panic occurs whenever the CI PPD is not prepared
     * to log the reported event.  Note that console logging only validates the
     * ability of the CI PPD to log the event, NOT the ability of this routine
     * to correctly log it.  Therefore, while all attempts by this routine to
     * log events more properly logged by cippd_log_sys() are successful,
     * important information may be loss due to this routine's unpreparedness
     * to deal with it.
     *
     * Not all events increment the counter of errors which have occurred on
     * the specified local port( Step 2 ).  Only those events with severity
     * level equal to or greater than error( ES_E ) increment the counter.
     *
     * This routine immediately terminates on failure to allocate an event log
     * record( Step 4 ).
     *
     * The size of the application portion of each event log record( Step 3 )
     * is dependent upon the presence or absence of optional information to be
     * included within the record( Step 7 ).  The following types of mutually
     * exclusive optional information may be logged:
     *
     * 1. A CI PPD datagram/message.
     * 2. Information about known and remote systems participating in a
     *	  configuration database conflict.
     * 3. New path information.
     * 4. Local SYSAP name.
     *
     * The last three types of optional information are associated with only
     * single specific events( RE_DBCONFLICT, I_NEW_PATH, and E_SYSAP
     * respectively ).  Optional CI PPD datagrams and messages are associated
     * with many different events.  They also vary widely in size unlike other
     * types of optional information whose size is fixed.  Logged CI PPD
     * packets are truncated whenever logging their full size would exceed the