Conference netcad::hub_mgnt

    The Test Id code of E01 in the error log is an FDDI Diagnostic
    test failure. It would appear that this is why the DECbridge900
    is not coming up if what you are seeing combined with the error
    log from the DECbridge900. Although, you wouldn't have been able
    to get this error log info if the DECbridge wasn't coming up,
    but maybe it's coming up but reporting a non-fatal error for the
    FDDI (IE: the bridge will come up in a limp-along mode).
    when you power up the DECbridge, are there any of the FRU LEDs lit?
    
    Bob

>>when you power up the DECbridge, are there any of the FRU LEDs lit?

  seems to be ok for me, but where is the FRU leds ,i can't see this part
in documentation.

 rgds

 Jean-Yves

    The primary FRU LED is the MODULE_OK led shown in the DECbridge
    installation guide.
    There is a table (table 3) in the DECbridge 900MX Installation Guide
    which is part of the problem solving section of the guide.
    If the MODULE_OK led is off after a minute or more after powering
    up the DECbridge 900MX, then self-test has failed. Also for field
    service folks, and repair center folks, the first three port state leds
    can further help to isolate the failure. IE: if the MODULE_OK led is
    off and any port 1 (Processor board), port 2 (I/O board), port 3 state 
    led (platform) is yellow, it indicates that the self test diagnostics 
    has isolated the problem down to the Processor board, I/O board, or a 
    problem in general with the whole unit respectively in the same order.
    These additional led indications are intended for interpretation by
    trained service personnel in service centers, thus this information is
    not included in the Installation Guide.
    
    Bob

    
    One thing you saw is expected:
    
    If you remove a module when the hub is running, any backplane
    configuration for that slot is deleted.  This means that you cannot
    reset a module using the traditional 'pop it out and back in' method
    without reconfiguring it.
    

 thanks all,

   re : -2

 >>   These additional led indications are intended for interpretation by
 >>   trained service personnel in service centers, thus this information is
 >>   not included in the Installation Guide.

 as this kind of documentation is available on net ::

 thanks

 Jean-Yves  

    During a recent DEChub900MS installation at a customer site, we had a
    DECbridge900MX failure similar to the base note. The DECbridge900MX
    passed self-test but we could not get it to configure in a backplane
    dual-ring, with a DECconcentrator900MX, using HUBwatch V3.0 for OpenVMS
    (DH900MS=V3.0.0, DB900MX=V1.2.1, DC900MX=V2.0.0).

    After configuring the DECbridge900MX's FDDI ports as internal trunk AB,
    and creating a FDDI LAN, we tried dragging the stub to the latter LAN.
    Occasionally the connection would visually "stick", although there was
    no traffic going between the DECbridge900MX and the DECconcentrator900MX,
    but most often the connection dragged down from the stub would just
    jump back. However, we could set UTP port 3 internal and connect it to
    the thinwire LAN on the DEChub and see any devices connected to the
    same thinwire LAN. Usually when we did this, though, we'd lose
    connection to the DECbridge900MX (we were using it as the agent) and
    the configuration would get hosed. After several factory resets, the
    Module_OK LED began flashing on the DECbridge900MX. The DECbridge900MX
    installation manual shows that a flashing Module_OK LED indicates a
    non-fatal error. In the "Problem Solving Using the LEDs" section, the
    table 3 entry shows:

--------------------------------------------------------------------------------
Symptom               Probable Cause         Corrective Action
--------------------------------------------------------------------------------
Module OK LED is      A non-fatal error has  Cycle power. If the problem
Flashing, but module  occurred.              persists contact your Digital
continues to operate                         Services representative to correct
normally.                                    the problem.

    The CSC said to replace the DECbridge900MX. After power-cycling the
    DECbridge900MX and reloading the firmware with no improvement, we did
    just that. With other symptoms, the manual show replacement as the
    corrective action. Anybody know what the intended corrective action was
    supposed to be?  Following is the error log, which is similar to the
    base note, Test ID of E01, which would explain the FDDI problems.

    Pete Capriccio
    VIS/Salem

DECbridge 900MX - slot 4
============================================
                                DUMP ERROR LOG
                    Current Reset Count: 2

=============
Entry #       = 0
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error]
Entry Id      = 1
Firmware Rev  = 1.8
Reset Count   = 1
Timestamp     =    0    0    0
Write Count   = 15
FRU Mask      = 1
Test ID       = E01
Error Data    = SR=0001 PC=00000000 Error Code=00800803

                0:00000001   1:00000000   2:00800803   3:00000000
                4:00000000   5:00000000   6:00000000   7:00000000

Entry #       = 3
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error]
Entry Id      = 1
Firmware Rev  = 1.8
Reset Count   = 0
Timestamp     =    0    0    0
Write Count   = 14
FRU Mask      = 1
Test ID       = E01
Error Data    = SR=0001 PC=00000000 Error Code=00800803

                0:00000001   1:00000000   2:00800803   3:00000000
                4:00000000   5:00000000   6:00000000   7:00000000

Entry #       = 2
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error]
Entry Id      = 1
Firmware Rev  = 1.8
Reset Count   = 0
Timestamp     =    0    0    0
Write Count   = 14
FRU Mask      = 1
Test ID       = E01
Error Data    = SR=0001 PC=00000000 Error Code=00800803

                0:00000001   1:00000000   2:00800803   3:00000000
                4:00000000   5:00000000   6:00000000   7:00000000

Entry #       = 1
Entry Status  = 0   [0=valid, 1=write_error, 2=invalid, 3=empty, 4=crc_error]
Entry Id      = 1
Firmware Rev  = 1.8
Reset Count   = 0
Timestamp     =    0    0    0
Write Count   = 14
FRU Mask      = 1
Test ID       = E01
Error Data    = SR=0001 PC=00000000 Error Code=00800803

                0:00000001   1:00000000   2:00800803   3:00000000
                4:00000000   5:00000000   6:00000000   7:00000000

 re:-1

  happy that i see that i am'nt alone,
  in my case multi factory reset + reload of microcode seems to be cured
  the problem

   Jean-Yves

	1122.4 says:    

>    If you remove a module when the hub is running, any backplane
>    configuration for that slot is deleted.  This means that you cannot
>    reset a module using the traditional 'pop it out and back in' method
>    without reconfiguring it.
    

Is this the way it should work or is it a problem that will be fixed?

A customer who recognized this effect called it a problem and asked for a fix.
So my question: is it a bug or a feature?

thanks, Robert