| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1500.1 | Ouch... | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Fri Sep 13 1991 10:49 | 26 |
| Just a quick sanity check.
Please:
1. Reply to this note with the actual FCL commands issued (they're
something like SHOW STATION <addr>, right ? ).
2. Please enter the version number of firmware running on the
DECconcentrator (use the "MAKO" CONCENTRATOR_AM or DECelms to get
this information).
3. a. $define mcc_enet_am_log 22
b. issue an offending station command
c. post resulting file mcc_enet_am.log here.
($define mcc_enet_am_log 26 will send packet dumps to screen)
Fwiw, Ethernet AM was tested with anything we could get our hands on at
the time. Most problems we're encountering involve firmware released
after we completed testing...
Chris
P.S. We're getting a DECconcentrator delivered
here this afternoon (for CONC_AM testing).
We'll be testing V1.2 Ethernet AM against it
for sure...
|
| 1500.2 | Reproduce-able in LKG | DELNI::R_PAQUET | | Fri Sep 13 1991 11:58 | 154 |
|
Chris,
Note that this only blows up on show counters and status. Show
all other partitions works fine.
LKG3> mana/enter
DECmcc (V1.1.0)
MCC> show station ray_test all char
STATION ACTMCC:.ray_test
AT 13-SEP-1991 10:19:19 Characteristics
Examination of attributes shows:
Functions Supported = DEC_IEEE802
Data Link Buffer Size = 1492
Maintenance Version = V4.0.0
Implementation = DECconcentrator-500/DEFCN wiring
concentrator FDDI comm link
LLC Class = ClassI
LLC Type = Type1
MCC> show station ray_test all status
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000001,
PC=004528CD, PSL=03C00004
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A,
PC=0000000A, PSL=0000000F
LKG3>
LKG3> mana/enter
DECmcc (V1.1.0)
MCC> show station ray_test all ident
STATION ACTMCC:.ray_test
AT 13-SEP-1991 10:19:50 Identifiers
Examination of attributes shows:
Name = ACTMCC:.ray_test
Address = 08-00-2B-13-DB-67
MCC>
MCC> show station ray_test all counters
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000001,
PC=004528CD, PSL=03C00004
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 7FEBEFF4
Name = 0000000C 00000000
00000000 7FEBFB04
00000001 00000004
004528CD 132B0008
03C00004 000067DB
00000000
00000000
00000209
00000000
Register dump
R0 = 03268009 R1 = 7FEBEE6C R2 = 00000004 R3 = 7FEBFB04
R4 = 7FEBEFF4 R5 = 00000000 R6 = 7FEBFB04 R7 = 0016791C
R8 = 03268009 R9 = 00155658 R10= 03268009 R11= 03268009
AP = 7FEBEF98 FP = 7FEBEF58 SP = 7FEBEFD4 PC = 004528CD
PSL= 03C00004
MCC> show concen lkg_act_conc2 all attr
CONCENTRATOR ACTMCC:.lkg_act_conc2
AT 13-SEP-1991 10:29:55 All Attributes
Address = 08-00-2B-13-DB-67
Name = ACTMCC:.lkg_act_conc2
Device Broken Reason = None
Device Configuration = ( ( FRU Type = Mother Board,
FRU State = Working,
FRU ID = N/A,
FRU Revision = Revision 0 ),
( FRU Type = ANSI Management
Board,
FRU State = Working,
FRU ID = Slot 1,
FRU Revision = Revision 0 ),
( FRU Type = 4 Port ANSI
Board,
FRU State = Working,
FRU ID = Slot 2,
FRU Revision = Revision 0 ),
( FRU Type = NULL,
FRU State = Empty,
FRU ID = Slot 3,
FRU Revision = Revision 0 ),
( FRU Type = Fan,
FRU State = Working,
FRU ID = N/A,
FRU Revision = Revision 0 ),
( FRU Type = Fan,
FRU State = Working,
FRU ID = N/A,
FRU Revision = Revision 0 ) )
Device State = Operating
NVRAM Failed Flag = False
Counter Creation Time = 29-AUG-1991 13:18:13.78
Invalid Passwords = 0
Management Resets = 0
Powerups = 0
Seconds Operating = 1285903 Seconds
Unsolicited Resets = 0
Firmware Version = V0.0.0
Hardware Type = DEFCN DECconcentrator 500
ID = %X08002B13DB67
Reset Defaults Switch = True
Software Version = "V3.0 B "
Update Switch = False
DECmcc Debug logging turned on here.
Trace data starting at: 13-SEP-1991 10:28:51.32
*
* Module mcc_enet_am_show entry point
* 13-SEP-1991 10:28:51.38
*
*
* mcc_enet_am__call_cea REQUEST:
* 13-SEP-1991 10:28:52.01
*
* Buffer Dump :
* Buffer Address = 7FEBEF04 (2146168580 dec)
* Buffer size = 00000003 ( 3 dec)
*
* Hex Ascii Offset
* 09 01 00 ... 00000003
*
*
* mcc_enet_am__call_cea Completed. RESPONSE:
* 13-SEP-1991 10:28:52.15
*
* Buffer Dump :
* Buffer Address = 00000000 ( 0 dec)
* Buffer size = 00000104 ( 260 dec)
*
* Incorrect Buffer for hex dump procedure
*
|
| 1500.3 | Investigation in progress. | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Fri Sep 13 1991 12:53 | 13 |
| The previous note (1500.2) was a dump of Ethernet AM V1.1 without the
required patch.
The same error (Buffer Address = 000000) results with DECbridge 500/600s of
recent revision, without the Enet AM patch applied, when non-CSMA/CD counters
are returned in response to the AM's MOP Counters Request (issued on both
SHOW COUNTERS and SHOW STATUS).
Base note stated that version was V1.1.1 (patch applied).
We'll look at this as soon as our DECconcentrator gets here.
Chris
|
| 1500.4 | ..Ethernet_AM V1.1.1 | EISNCG::MEHR | | Fri Sep 13 1991 15:00 | 33 |
|
RE .2 Thanks, Ray. For reproducing the problem.
You are always a great help....
Re .1 &.3 Thanks for quick response.
I am at customer site, connecting through a 1200bud modem.
I can not sent the log files, at least not easily!
My symptoms are very much like what Ray described,
except I get a failure with SHOW ALL ATTRIBUTES too!
Some clarification: Yes I did apply the patch. and yes the AM is
V1.1.1
The concentrators are all
Software Version 2.3 and
Software Implementation Type: DEFCN
ROM Version: .0
ROM Implementation Type: DEFCN
Based on .3, it sounds like this info should do for now!
Please also look into the second bullet in note 1501.0
to see whether that was caused by this problem!
Do you have any idea when you will get the concentrators to test
them?
Thanks
|
| 1500.5 | STATION = *any* 802.2 ? | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Fri Sep 13 1991 18:41 | 42 |
| The DECbridge 620 and DECconcentrator arrived here around 2pm.
Some preliminary testing reveals, with our local version of DECmcc V1.1 and
Ethernet AM V1.1.1, that:
SHOW ALL COUNTERS works as expected (we return an exception)
SHOW ALL STATUS accvios
(SHOW ALL ATTR would also accvio, since it results in calls to
SHOW ALL STATUS along with the other partitions).
We'll do more testing on Monday.
Not that it matters at this point, but:
--------------------------------------
"Ethernet AM", as a byproduct of "translating bridges" (e.g. DECbridge 5xx/6xx
for FDDI, IBM's for Token Ring, who else?), now allows STATION commands to
work with Token Ring and FDDI based devices (it's no longer just an
"Ethernet Station").
A case in point: DECconcentrators connect to FDDI rings, not Ethernet LANs.
Since DECbridges translate ethernet packets to FDDI packets, 802.2 XID and
802 TEST commands work to it. But MOP V4 request packets also make it
onto the FDDI ring. Since FDDI's MOP Counters response is different from
CSMA/CD's MOP Counters, confusion results (particularly if you were expecting
only the smaller CSMA/CD counters!). Request ID (mapped to SHOW ALL CHAR)
works fine, since the format is the same.
What to do? For patching of Ethernet AM V1.1, we're forcing oversized
MOP Counter responses to generate an Exception (beats ACCVIO).
For Ethernet AM V1.2, we're doing the same: function freeze has
already occurred, and adding FDDI counters involves lots of new code
and MSL (/documentation/online help) to recognize new attributes.
Hopefully for the "next" release of Ethernet AM after V1.2 (or maybe
adding it to V1.2 during EFT? :-), we'll be adding support for the new
fddi counters (they could come in handy, and "STATION" is a handy/generic
class name :-).
Of course someone (else) should lobby the FDDI AM to support FDDI
MOP counters (but I already asked: they said "no").
Chris
|
| 1500.6 | Byte ordering? | SUBWAY::REILLY | Mike Reilly - New York Bank District | Tue Sep 17 1991 17:39 | 5 |
| Chris,
Does the new STATION AM handle the byte ordering correctly for Token
Ring?
- Mike
|
| 1500.7 | You're kidding, right? | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Tue Sep 17 1991 17:54 | 13 |
| > Chris,
> Does the new STATION AM handle the byte ordering correctly for Token
> Ring?
>
> - Mike
You're kidding, right?
Actually, is there a byte ordering problem that we could/should
handle?
Chris
|
| 1500.8 | | SUBWAY::REILLY | Mike Reilly - New York Bank District | Tue Sep 17 1991 18:26 | 10 |
| I have a few token ring devices registered at this site. The devices
are connected via an IBM 8209 TR-Ethernet bridge. On the TR the
order the individual address bits are transmitted is the opposite to the
order on Ethernet. Thus to register a station with an address of
08-00-2b-xx-xx-xx, I have to register a device with an address of
01-00-4D-xx-xx-xx. Will our Token Ring cards take care of this or
will you have to add code to handle it? Will we be able to register
devices which are on the far side of a TR_Ethernet bridge?
_ Mike
|
| 1500.9 | No special code in Ethernet AM... | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Tue Sep 17 1991 19:21 | 24 |
| RE: Token Ring Stations
> Thus to register a station with an address of
> 08-00-2b-xx-xx-xx, I have to register a device with an address of
> 01-00-4D-xx-xx-xx.
If this works, then just REGISTER it with the "backwards" address.
Maybe specify the "backwards" address as ALTERNATE ADDRESS...
> Will our Token Ring cards take care of this or
> will you have to add code to handle it?
Ethernet AM, which uses an Ethernet Device to communicate with a
target Station, will NOT (at least in the short term) be adding code
to special case Token Ring. We might, long term, add support for
TR specific MOP Counters if they get defined...
> Will we be able to register
> devices which are on the far side of a TR_Ethernet bridge?
Mike, have you tried this yet? My guess is that it might actually
work...
Chris
|
| 1500.10 | | SUBWAY::REILLY | Mike Reilly - New York Bank District | Wed Sep 18 1991 11:21 | 6 |
| Chris,
I have been able to register devices connected by a TR-Ethernet
bridge with 802.2 XID and TEST directives working correctly. Using the
'bit swapped' address as an alternate address is a good idea.
- Mike
|