How do I perform troubleshooting and dump analysis?

The GPA 2G makes a great deal of line tracing information available to customers and their developers. If you are troubleshooting a connection, it is very useful to be able to quickly determine if the problem lies within the GPA 2G or not. This can be done with traces, which are a standard part of our dump file.

Creating Dump files Dumps can be created in one of two ways: 

  1. From the GMC, click “Troubleshoot” button, then click “Run the Command” linktext. [Note: Make sure that the Checkbox next to “Select to exclude...” is not selected.] Or you can:
  2. Using SSH, log into the GPA 2G, type “Gcom_dump>name_of_dumpfile”

Analyzing the “trace” portion-- No Data

From within the dump file, you can see the output from various commands*. Find the section of the dump file corresponding to “Gcom_cdi -t{#}” command. Ignoring the initialization time entries at the very beginning, the following output would show no traffic is coming in:

68190150 Rcv Tkn 01->05 Timer Prod extra=0000 bfrp=0 othr=0
68200150 Rcv Tkn 01->05 Timer Prod extra=0000 bfrp=0 othr=0
68210150 Rcv Tkn 01->05 Timer Prod extra=0000 bfrp=0 othr=0
68220150 Rcv Tkn 01->05 Timer Prod extra=0000 bfrp=0 othr=0

These entries are from the end of the output. Notice that every 10 seconds (the numbers are in milliseconds) there is a “Timer Prod”. These serial chip receiver resets occur if ten seconds goes by without receiving any input. If you see a string of these, then no input is occurring.

Analyzing the “trace” portion-- Successfully Receiving Data

Pairs of lines in the Gcom_cdi -t output that look like the following are indicative of receiving data:

597736200 Rcv Bfr (6) 10 20 28 29 2a 1d 00 00 06 0e 00 00 00 00 00 00
597736200 Snd Tkn 05->06 Frm Rcvd extra=fff7 bfrp=d16a5124 othr=0

The "Rcv Bfr" entry shows the first few bytes of the incoming data with the byte count in parentheses. The following "Snd Tkn...Frm Rcvd" entry shows that the buffer is being forwarded to the protocol layers for further processing.

Analyzing the “trace” portion-- Successfully Transmitting Data

Sequences that look like the following are indicative of the successful transmitting of data:

597725000 Snd Bfr (2) 0f 37 00 00 04 00 00 00 02 0e 00 00 00 00 00 00
597725000 Rcv Tkn 03->03 Frm Xmitted extra=0000 bfrp=db4b4d24 othr=0
597725000 Snd Tkn 03->04 Frm Xmitted extra=0000 bfrp=db4b4d24 othr=0

The "Snd Bfr" shows the first few bytes being sent with the byte count in parentheses. The "Rcv Tkn...From Xmitted" indicates that the data was successfully transmitted. The "Snd Tkn...Frm Xmitted" indicates that the protocol layers are being informed of the successful transmission.

A functioning interface will have a “Gcom_cdi -t{#}” output that looks more like this:

68455000 Snd Bfr ( 2) 0f 37 00 00 04 00 00 00 02 0e 00 00 00 00 00 00
68455000 Rcv Tkn 03->03 Frm Xmitted extra=0000 bfrp=d821a124 othr=0
68455000 Snd Tkn 03->04 Frm Xmitted extra=0000 bfrp=d821a124 othr=0

Alternative way to verify 'No Traffic'

If you want to confirm this at a lower level, find the section for "ivp sca-intr-trace". If nothing is happening down in the Digi driver other than timer interrupts, the output will resemble this:

68221350 compute-IMVR: isr0=0 isr1=0 isr2=40 vector=3C
68221350 Vector: Vect=0x3C timer 0/2
68221350 compute-IMVR: isr0=0 isr1=0 isr2=40 vector=3C
68221350 Vector: Vect=0x3C timer 0/2
68221350 compute-IMVR: isr0=0 isr1=0 isr2=40 vector=3C
68221350 Vector: Vect=0x3C timer 0/2

* These commands can also be executed from the command line after you have entered the box via SSH.