[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | FDDI - The Next Generation |
|
| Moderator: | NETCAD::STEFANI |
|
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
825.0. "Bridge 1.2 Diagnostic Block Layout??" by ZUR01::HOTZ (Gregor, CS, NaC Support, Schweiz) Thu Jan 07 1993 10:08
A Diagnostic Block (see below) from a DB620 V1.2, decoded
according to the DB500 Tech Manual gives no reasonable result. Has
the format changed?
The Bridge had unsolicited resets: 1 per week when port 2 was
connected, 5 per DAY when port 3 and 1 per week when port 4 was
connected to an error free ethernet. The not-connected ports had
the loopback on, port 1 (fddi) had a cable from A to B.
Replacing the NI3 module fixed the problem. But with this
intermittent problem rate, a clue from the Diag Block (FRU Mask)
would certainly have speeded up the troubleshooting process. (The
customer had only port 2 connected. We swapped the bridge and did
the tests inhouse.)
Is there a new Tech Manual? Whats the layout of the Diag Block for
the 5xx/6xx bridges? Will it change with 1.3?
Thanx for any info. Others in the field have a need to know too. See
entries 660.1 and 740.
greg.
From MCC 1.2, with my edits, where are mcc's? :-(
Examination of attributes shows:
Diagnostic Block = ( %X000C000D00000000101C00110000DEAD, <-��*DEAD*??
<______________________><--><-->
Header info ^ ^test ID
(no info in manual) ^FRU implication mask
(0=AP,1=NI,2=FI,3=QM,4=Fan A, 5=Fan B)
%X0000250000184C702000000200000000,
<------><------><------><------>
Error Result Result Result
Code Data 1 Data 2 Data 3
112 Bytes { %X0000000020000002000000F900000004,
unused { %X003E82EA000004010000210000000000,
data. { %X0000000016A00E00003E88FC201853B8,
{ %X003E8402003E89A2000004FC002017C4,
{ %X00201770003DBE2C81B9C0FF00000001,
{ %X00000007000000070000000000000000,
{ %X00000107003DC734001868BC00201800,
Err Log 2: %X000000640000004EFFFFFFFD793781A9,
%X100C000F0000000FEDEE00110000DEAD,<-
%X0000250000184C702000000200000000,
%X0000000020000002000000FA00000004,
%X003E82EA000004010000210000000000,
%X0000000016A00E00003E88FC201853B8,
%X003E8402003E89A2000004FC002000C4,
%X00201770003DBE2C81B9C0FF00000001,
%X00000007000000070000000000000000,
Err Log 3: %X00000107003DC734001868BC00201800,
%X000000640000003CFFFFFFFDD06EA571,
%X100C001000000000017600110000DEAD,<-
%X0000250000184C062000000200000000,
%X00000000200000020000000A00000004,
%X003E82EA000004010000210000000000,
%X0000000016A00E00003E88FC201853B8,
%X003E8402003E89A2000004FC002017C4,
%X00201770003DBE2C81B9C0FF00000001,
Err Log 4: %X00000007000000070000000000000000,
%X00000107003DC734001868BC00201800,
%X000000640000005FFFFFFFFD02D43BD8,
%X100C001100000000102600110000DEAD,<-
%X0000250000184C702000000200000000,
%X0000000020000002000000FB00000004,
%X003E82EA000004010000210000000000,
%X0000000016A00E00003E88FC201853B8,
%X003E8402003E89A2000004FC002017D4 )
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 825.1 | More on Diag Block | QUIVER::WALTER | | Sat Jan 09 1993 16:39 | 308 |
| Greg,
> A Diagnostic Block (see below) from a DB620 V1.2, decoded
> according to the DB500 Tech Manual gives no reasonable result. Has
> the format changed?
Yes, the format is not the same as for the DB500. I will attach some
documentation on the new format.
> Is there a new Tech Manual? Whats the layout of the Diag Block for
> the 5xx/6xx bridges? Will it change with 1.3?
A new tech manual is in draft form for the DECbridge 500/600 series. Larry
Holmes (TNPUBS::L_HOLMES) should know the status of the manual. I don't know
if it documents the diagnostic block (I doubt it).
The diag block format will not change for V1.3 firmware.
I ran your dump data through a formatter. The results indicate that the
forwarding processor, which resides on the NI board, detected run time errors
and crashed. The error code returned by the forwarding processor is "20000002";
I was not able to find the meaning of this code.
[BTW: The test ID refers to the results of a self test failure, which is not
applicable to a run time error. Since it has to have a value, the developers
chose to assign it "DEAD".]
The dump report is also attached below.
Regards,
Dave Walter
***************************************************
** Diagnostic Block Dump Formatter **
** Rev. 1.0 **
***************************************************
Date: Sat Jan 9 16:14:30 1993
Input file: 620_DUMP.TXT
Output file: 620_DUMP.OUT
+---------------------------------------------------------+
| B L O C K 1 |
+---------------------------------------------------------+
*** Firmware Error ***
ID = 0x00
Firmware Rev = 1.2
Reset Count = 13
Timestamp = 0x00000000101C (d:h:m:s = 0:01:08:44)
Write Count = 17
FRU Mask = 0
Test ID = DEAD (Firmware failure)
Reason Code = 0x20000002
Error Data 1 = 0x00000000
Error Data 2 = 0x00000000
PC = 00184C70
SR = 2500
D0 = 20000002 A0 = 16A00E00
D1 = 000000F9 A1 = 003E88FC
D2 = 00000004 A2 = 201853B8
D3 = 003E82EA A3 = 003E8402
D4 = 00000401 A4 = 003E89A2
D5 = 00002100 A5 = 000004FC
D6 = 00000000 A6 = 002017C4
D7 = 00000000 A7 = 00201770
VBR = 003DBE2C
CAR = 81B9C0FF
CCR = 00000001
DFC = 00000007
SFC = 00000007
CRC = 793781A9
+---------------------------------------------------------+
| B L O C K 2 |
+---------------------------------------------------------+
*** Firmware Error ***
ID = 0x10
Firmware Rev = 1.2
Reset Count = 15
Timestamp = 0x0000000FEDEE (d:h:m:s = 12:01:59:10)
Write Count = 17
FRU Mask = 0
Test ID = DEAD (Firmware failure)
Reason Code = 0x20000002
Error Data 1 = 0x00000000
Error Data 2 = 0x00000000
PC = 00184C70
SR = 2500
D0 = 20000002 A0 = 16A00E00
D1 = 000000FA A1 = 003E88FC
D2 = 00000004 A2 = 201853B8
D3 = 003E82EA A3 = 003E8402
D4 = 00000401 A4 = 003E89A2
D5 = 00002100 A5 = 000004FC
D6 = 00000000 A6 = 002000C4
D7 = 00000000 A7 = 00201770
VBR = 003DBE2C
CAR = 81B9C0FF
CCR = 00000001
DFC = 00000007
SFC = 00000007
CRC = D06EA571
+---------------------------------------------------------+
| B L O C K 3 |
+---------------------------------------------------------+
*** Firmware Error ***
ID = 0x10
Firmware Rev = 1.2
Reset Count = 16
Timestamp = 0x000000000176 (d:h:m:s = 0:00:06:14)
Write Count = 17
FRU Mask = 0
Test ID = DEAD (Firmware failure)
Reason Code = 0x20000002
Error Data 1 = 0x00000000
Error Data 2 = 0x00000000
PC = 00184C06
SR = 2500
D0 = 20000002 A0 = 16A00E00
D1 = 0000000A A1 = 003E88FC
D2 = 00000004 A2 = 201853B8
D3 = 003E82EA A3 = 003E8402
D4 = 00000401 A4 = 003E89A2
D5 = 00002100 A5 = 000004FC
D6 = 00000000 A6 = 002017C4
D7 = 00000000 A7 = 00201770
VBR = 003DBE2C
CAR = 81B9C0FF
CCR = 00000001
DFC = 00000007
SFC = 00000007
CRC = 02D43BD8
+---------------------------------------------------------+
| B L O C K 4 |
+---------------------------------------------------------+
*** Firmware Error ***
ID = 0x10
Firmware Rev = 1.2
Reset Count = 17
Timestamp = 0x000000001026 (d:h:m:s = 0:01:08:54)
Write Count = 17
FRU Mask = 0
Test ID = DEAD (Firmware failure)
Reason Code = 0x20000002
Error Data 1 = 0x00000000
Error Data 2 = 0x00000000
PC = 00184C70
SR = 2500
D0 = 20000002 A0 = 16A00E00
D1 = 000000FB A1 = 003E88FC
D2 = 00000004 A2 = 201853B8
D3 = 003E82EA A3 = 003E8402
D4 = 00000401 A4 = 003E89A2
D5 = 00002100 A5 = 000004FC
D6 = 00000000 A6 = 002017D4
D7 = 00000000
DIAGNOSTIC BLOCK DUMP FORMAT
----------------------------
**
** The following is the format of the diagnostic block dump as received
** from MCC:
**
** +--------------------------------------+
** | Block 1 Header (1 line, 4 longwords) |
** +--------------------------------------+
** | |
** | Block 1 Info (9 lines, 36 longwords) |
** | |
** +--------------------------------------+
** | Block 2 Header (1 line, 4 longwords) |
** +--------------------------------------+
** | |
** | Block 2 Info (9 lines, 36 longwords) |
** | |
** +--------------------------------------+
** | Block 3 Header (1 line, 4 longwords) |
** +--------------------------------------+
** | |
** | Block 3 Info (9 lines, 36 longwords) |
** | |
** +--------------------------------------+
** | Block 4 Header (1 line, 4 longwords) |
** +--------------------------------------+
** | |
** | Block 4 Info (5 lines, 20 longwords) | <---Note truncated block!
** | | Why does MCC do this?
** +--------------------------------------+
**
**
** The Header line is formatted in the following way:
** (Number of bytes in parentheses)
**
** +---+---+-------+-----------------------+-------+-------+-------+
** |ID |Rev| Reset | Time Stamp | Write | FRU | Test |
** | | | Count | | Count | Mask | ID |
** |(1)|(1)| (2) | (6) | (2) | (2) | (2) |
** +---+---+-------+-----------------------+-------+-------+-------+
**
** ID: $00 for Selftest entry
** $10 for Firmware entry
** (BUT... sometimes 00 is shown for FW. Don't
** know why.)
**
** Rev: $29 for Selftest (ROM rev)
** $xx for Firmware, where xx/10 is the revision
** (ex. xx=$0D for V1.3)
**
** Reset Cnt: $xxxx Number of bridge resets since last reset-
** to-defaults.
**
** Time Stamp: $xxxx xxxx xxxx Time in seconds since last reset.
**
** Write Cnt: $xxxx Number of times this block written since
** diag block last cleared.
**
** FRU Mask: $0000 -- for Firmware entry
** $0001 AP for Selftest entry
** $0002 NI for Selftest entry
** $0004 FI for Selftest entry
** $0008 QM for Selftest entry
**
** Test ID: $DEAD for Firmware
** $xxxx for Selftest (indicates test that failed)
**
**
** The info lines are formatted in the following way:
** (All are longwords)
**
** +---------------+---------------+---------------+---------------+
** | SR (low word) | PC | Reason Code | Error Data 1 |
** +---------------+---------------+---------------+---------------+
** | Error Data 2 | D0 | D1 | D2 |
** +---------------+---------------+---------------+---------------+
** | D3 | D4 | D5 | D6 |
** +---------------+---------------+---------------+---------------+
** | D7 | A0 | A1 | A2 |
** +---------------+---------------+---------------+---------------+
** | A3 | A4 | A5 | A6 |
** +---------------+---------------+---------------+---------------+
** | A7 | VBR | CAR | CCR |
** +---------------+---------------+---------------+---------------+
** | DFC | SFC | *** | *** |
** +---------------+---------------+---------------+---------------+
** | *** | *** | *** | *** |
** +---------------+---------------+---------------+---------------+
** | *** | *** | *** | CRC |
** +---------------+---------------+---------------+---------------+
**
** SR: Status Register (low word only) at time of error
** exception
**
** PC: Program Counter at time of error exception
**
** Reason Code: Failure code passed from firmware. See file
** EXCEPTIONS.H for constant definitions.
**
** Error Data 1&2: Data passed by Selftest, not used by firmware.
**
** D0 - D7: Data registers
**
** A0 - A7: Address registers
**
** VBR: Vector Base Register
** CAR: Cache Address Register
** CCR: Cache Control Register
** DFC & SFC: Alternate Function Registers
**
** ***: No useful data
**
** CRC: CRC for this block.
**
|
| 825.2 | | ZUR01::HOTZ | Gregor, CS, NaC Support, Schweiz | Mon Jan 11 1993 10:14 | 12 |
| Thanks Dave,
I don't know why mcc truncates the block. The DB500 block is 4 * 144 Bytes,
the DB5xx/6xx bloks are 4 * 160 bytes. It seems that mcc doesn't know that.
Those 4 * 16 bytes are missing.
But if the diag block is returned as a TLV (tag/length/value) block, it should
know (if the DB does it right, does it?).
Could you also supply the EXEPTIONS.H file for the reason codes after 20000002
has been added, and a pointer to the Formatter
or post it here if it's a .com file. Many of us have a need for this.
greg.
|
| 825.3 | Location of Diagnostic Block dump formatter | QUIVER::WALTER | | Mon Jan 11 1993 21:11 | 21 |
| I've posted the following files in QUIVER::PROJ$706:[NI3_FW.RELEASE]
DUMP_DIAG_BLOCK_MCC.EXE ! Diagnostic block formatter
EXCEPTIONS.H ! Contains defs for Reason Code
The standard caveats apply:
1. The formatter is an engineering hack, not intended to be
bullet proof. It only works with dumps from the 500/600 series
bridges, NOT the DECbridge 500.
2. It's very easy to draw the wrong conclusion from the diag dump
and reason codes. I've done it many times. So it's still a good
idea to contact engineering or the support organization.
Re: -.1
I've come to the conclusion that the Reason Code of 20000002 doesn't
point to any particular error other than crash of the forwarding
processor. If the forwarding processor had diagnosed a problem, it
would have left a different error code.
Dave
|
| 825.4 | | NPSS::RAUHALA | | Wed Aug 07 1996 13:32 | 2 |
| the files listed in reply .3 are still valid
the node name is now NETCAD::PROJ$706:[NI3_FW.RELEASE]
|