[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

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

1932.0. "DEFEA -Link confidence test failure !" by KERNEL::ANSONR () Wed Jan 24 1996 06:10

    Hi,
    
    We have a customer  running Digital Unix 3.2c on a DEC2000 Model 300.
    The only configured network connection, fta0:. is through the FDDI card  
    DEFEA-UA (i.e.twisted pair version). (There is also an ethernet card,        
    DE422 I think, connected to the net but not configured from unix).
    
    He finds that with the alpha at the >>> prompt the fddi board has the
    PHY LED green. When he boots the operating system, after a while the LED
    goes red and he receives the following on the console:
    
    
    
    fta0: LCT rejects
    fta0: Link confidence test failure inlocal direction
    fta0: Link unavailable
         
     
    
    After about 3 minutes the LED goes green and he receives the following on
    the console:
    
    fta0: Link available
    
    Its clear from the speed of boot compared with other alphas  that the
    red LED condition is causing the startup to hang around for some time..
    .but it does recover after a few minutes.
    
    He has also seen 2 occurances of the following message on the console:
    
    MAC CRC error.       
    
    
    The DEFEA card has been swapped out . We have changed port/cable on a known
    working DECconcentrator port ( I should have mentioned at the time the
    DEFEA is in this RED led condition..the concentrator port LED also
    shows the bad link condition).
    
    
    DEFEA - HW rev 2
            FW 2.3
    
    
    Has anybody got any suggestions pls. I think I have tried thr most
    obvious ways to cure this problem.
    
    thanks 
    
    Rich.
T.RTitleUserPersonal
Name		DateLines
1932.1NETCAD::MELARAGNIWed Jan 24 1996 07:5712
    The last option is to swap out the DEFEEA card. On more pricisely, swap
    out the UTP interface daughtercard on the module. I can't recall if the
    daughtercard is considered an FRU or not. But in any case the module
    you would want to order for the DC is the 54-22539-02.
    
    You can swap the DEFEA card into other slots in the PC or even swap
    card into another PC but the chances of that resolving the problem are
    remote. The easiest thing you can do for your customer is replace the
    bad device (either the whole DEFEA card or the UTP daughtercard).
    
    bill
    Developer of the UTP daughtercard
1932.2NETCAD::STEFANIMachines to humanizeWed Jan 24 1996 10:0511
    Re: .0
    
    This is not related to the problem you're seeing, but you should
    upgrade the DEFEA to the latest firmware image (v2.46).  The latest
    Alpha FW CD should have this image and the utility necessary to blast
    the adapter.
    
    The v2.3 FW can potentially see adapter halts on receive overrun type
    conditions.  The v2.46 FW addresses this problem.
    
    /l
1932.3Parts have been replaced..KERNEL::ANSONRFri Jan 26 1996 05:0812
    
    Thanks for your replies,
    
    Both the DEFEA and the UTP daughter board have been replaced with no
    success - they are still seeing the same symtoms.
    Do you think a FW upgrade may help??
    
    Can you think of any further action I can take??
    
    Thanks
    
    Rich
1932.4suspect the cableNETCAD::MELARAGNIFri Jan 26 1996 07:5121
    I would suggest upgrading the firmware independent of whether it will
    fix this particular problem. It only takes a few minutes to re-program
    the on-board flash of the defea, and it can all be done thru DOS. 
    
    This problem might have more to do with the cable the connects the
    DEFEA to the conc. The cable length should be no more than 100m total.
    This distance allows for 2 5m patch cords and 90m of behind-the-wall
    cable. Distances longer than 100m bring you into the "danger zone"
    in which the links might exhibit a higher error rate. When the error
    rate gets really high the link will shut down and run LCT.
    
    If you or the customer has access to a UTP cable tester you may want to
    verify that the cable meets EIA/TIA-568 for attenuation and crosstalk.
    Most of the good testers provide these tests with the limits built-in
    so there's little quess work on your part. Otherwise you may want to
    get your hands on 100m of UTP cable and connect the DEFEA to the conc
    and demonstrate that the link *can* work, but just not with the
    customer's cable. 
    
    Hope this helps,
    bill
1932.5use a loop back49393::HOTZgimme an F !!!, ...D !!!, ...D !!!, ...I !!!, what's that spell !!!?Wed Jan 31 1996 10:489
to verify that the defea is ok, plug in a loop back connector.

(pin 1 to pin 7 and pin 2 to pin 8)

It has an S port. With the loop back, it'll think it's connected to another
S-port. This is a legal configuration, so the green light should come on
(I've never verified this on a defea).

greg
1932.6thanksKERNEL::ANSONRTue Feb 13 1996 13:328
    
    Thanks Everybody,
    
     We will replace the cabling/ and upgrade the FW and see how that goes.
    
    thanks for your help
    
    Rich
1932.7VMS -->OSF ..any relevence??KERNEL::ANSONRFri Feb 16 1996 06:5115
    
    Hi,
    
    Just a quick question.
    
    The customer was running openVMS 6.2?? on this Alpha, and he says the
    DEFEA worked fine. When they migrated to OSF they saw the problem. 
    Does anybody feel that this could be of any relevence, as feel that
    this is more a physcial problem ??
    
    I just need reassurance thats all ;-)
    
    thanks
    
    Rich