[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference npss::gigaswitch

Title:GIGAswitch
Notice:GIGAswitch/FDDI Jan 97 BL3.1 914.0 documentation 412.1ion 412.1
Moderator:NPSS::MDLYONS
Created:Wed Jul 29 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:995
Total number of notes:4519

947.0. "errorLog_xac_txTimeout in error log" by KERNEL::FREKES (Like a thief in the night) Tue Mar 11 1997 06:53

        Folks

    I have a GIGAswitch running with FGL-4 V3.1
    				     SCP   V3.1
    				     Clock V3.0

    We have had two FGL-4 cards fail. In slots 5 and 9. The cards appear to
    be ok, but as soon as you insert a cable into either, they start to
    reboot. These cards were swapped out, before we looked at the problem,
    but the problem remains.

    When we ping the GIGAswitch we get twice the number of packets back in
    a repetitive ping. This only happens intermitently. I am assured that
    this address is unique. When we looked in the error log, I saw a few
    GPI errors, I gather from previous notes that these are not serious
    enough to worry about.
    
    There are however quite a few of the following. I have removed the
    timestamp, and date etc.
    
    61 errorLog_xac_txTimeout
    
    and then every now and then I see on or two:
    
    70 XAC error: destinfo: 11
    70 XAC error: destinfo: 11
    cmgr: ICC times out slot 5
    
    Can anybody shed some light on what these mean?
    
    Regards
    	Steven Freke
    	UK CSC
    
    
    	
T.RTitleUserPersonal
Name
DateLines
947.1NPSS::MDLYONSMichael D. Lyons DTN 226-6943Tue Mar 11 1997 09:3218
        The previous notes which referred to GPI errors most likely said
    that if there were a couple of them, they were most likely associated
    with a normal event like a line card reboot, but if there were many of
    them, it was likely to be a hardware problem with the box somewhere.
    
        Please report this through the traditional channels.
    
        ...however, what needs to be done is to collect all the line card
    error logs, including those which you don't believe have anything to do
    with the problem.  Also collect the complete SCP error log summary.
    
        Occasionally, you can winnow a hint as to which card is actually
    causing the problem by analysis of all the error logs.  It is common to
    find that the one causing the problem is not logging any errors.
    
        This type of problem is addressed by board swapping.
    
    MDL 
947.2NPSS::MDLYONSMichael D. Lyons DTN 226-6943Tue Mar 11 1997 09:343
    P.S. Seeing as how there are previous notes on the same topic, I am
    strongly tempted to relocate this entire note to one of them to make it
    easier to keep common discussions in a single place.