Conference netcad::hub_mgnt

    
    After having copied and installed the newest Firmware Version found
    from reply .7 (customer took however firmware from the clearvision CD
    rom because it had the same revision level)  he was able to connect
    a fifth port. (hub firmware was 4.2.0, decbridge900 ef 1.6.1,
    portswitch 900fp 2.2.0)
    However the sixth port brought the same problem as the fifth before.
    
    Since I don't believe that the customer made a configuration error -
    what are suggested options? Should I raise an IPMT (what kind of
    information do you additionally need? ) or do you have other
    suggestions?
    
    thanks for further help
    greetings eva
     

Hello ,

I have a HUB900 at IP address 16.186.0.120(internally)
with a DECswitch900EF that shows exactly the decribed
 problem.
If someone wants to look at it feel free.
The HUB900 is at FW4.2.0
the DECswitch900EF is at V1.7.0

Thanks for any Help/hints



OTTO

    I took a look at your hub and the EF in slot 6 has 6 Ethernet
    connections to the backplane.  That's all you get!!!
    
    Bill
    

But the issue is, why are ports 4&5 in the "broken" state.
This seems odd to me. They are connected to ethernet
LANs on which there are no other ports in the hub connected.

I looked at the hub, too, and could find nothing else wrong.
All the MAM tables looked correct.

-mike

In doing some further testing, I have found a switch that
behaves in a similar fashion. In my case, the amber traffic
LED turns on solid, but the port is not trasmitting data
to the backplane. After a minute or so the port
goes into the "broken" state.

It looks to me like a hardware failure. I don't know what
else to look at. You may wish to escalate this accordingly.
I wonder how common this is?

-mike

    I ran diags on Mike's switch and found a BTL driver failure.
    
    I suspect that this is also the problem with the 2 modules discussed in
    this string.  In summary; this is a hardware failure and the modules need 
    to be swapped.
    
    Bill
    

Thanks Bill,

that was an excellent idea to run the builtin extended Diagnostics on the 
switch.  This is what it produces and I will replace it now


Thanks



OTTO
(who can't see the tree for the forrest)


Errorlog entries:



Entry #       = 1
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error
Entry Id      = 10
Firmware Rev  = 1.7
Reset Count   = 46
Timestamp     =    0    0   E6
Write Count   = 7
FRU Mask      = 0
Test ID       = DEAD
Error Data    = SR=2400 PC=030253F2 Error Code=00002380 ProcCsr=F76D
Registers     = D0=00000104 D1=00000000 D2=00000073 D3=0000000B
                D4=00000003 D5=00000B01 D6=00010380 D7=00000000
                A0=0500000A A1=06000003 A2=00001482 A3=03031498
                A4=0303117C A5=00000000 A6=0004BA54 A7=0004BA24
Dump another entry [Y]/N?
Entry #       = 0
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error
Entry Id      = 10
Firmware Rev  = 1.7
Reset Count   = 45
Timestamp     =    0    1 391E
Write Count   = 7
FRU Mask      = 0
Test ID       = DEAD
Error Data    = SR=2300 PC=03025AD4 Error Code=00002380 ProcCsr=D76D
Registers     = D0=00000A2A D1=00000000 D2=00000026 D3=0000000B
                D4=00000003 D5=00000B01 D6=00010380 D7=00000000
                A0=0500000A A1=06000003 A2=00001482 A3=03031498
                A4=0303117C A5=00000000 A6=0004BA54 A7=0004BA40
Dump another entry [Y]/N?

Hello all,


this problem is fixed. It was not the DECswitch900EF
but the HUB-Backplane.

In the proccess of isolating this, I found another
"problem"

I ran the extended  diagnostics on the switch 
(Module specific options--> 2 run extended dia..)

and got these entries in the errorlog:

ump another entry [Y]/N?
Entry #       = 0
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error
Entry Id      = 10
Firmware Rev  = 1.7
Reset Count   = 45
Timestamp     =    0    1 391E
Write Count   = 7
FRU Mask      = 0
Test ID       = DEAD
Error Data    = SR=2300 PC=03025AD4 Error Code=00002380 ProcCsr=D76D
Registers     = D0=00000A2A D1=00000000 D2=00000026 D3=0000000B
                D4=00000003 D5=00000B01 D6=00010380 D7=00000000
                A0=0500000A A1=06000003 A2=00001482 A3=03031498
                A4=0303117C A5=00000000 A6=0004BA54 A7=0004BA40


and therefore thought I have found the problem. After replacing the switch with a
new one I tested this switch as well and got the same error from this switch.
The problem of the last two ports beeing connected to IMB going into Broken state
was still there with the new switch.

This morning I replaced the HUB Backplane and now the problem is gone, but I have 
a switch with this errorlog entry. 


Thanks for all help


OTTO

    Our customer just called and told us, he checked the errorlog
    of the backlane and he found errors like:
    
    trap @ 1705 in matrix_connections.c
    
    It seems the hub logged such an error each time the customer tried
    to make the relevant connections using MCM.
    
    OTTO

    <------ RE: .15 
    Otto, the error log entries of the DECswitch900EF cannot be cleared
    by the customer. So even though the problem is fixed (IE: the HUB
    was replaced as you indicatd), the error log entry will remain in
    the DECswitch's NVRAM error log footprint. That error log entry
    was likely generated as a result of the defective backplane.
    
    
    Bob

Unfortunately, I cannot tell you what that might mean
unless I have the full errorlog and also know
what version of the MAM they are running.

For instance, there is no Trap at line 1705 in
matrixConnections.c for mam V4.2 so it must be 
a different one.

If I were to guess, it probably means they are running out
of heap, and a malloc() failed. An upgrade to mam V4.2 would fix
that.

-mike