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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

3615.0. "DEFXU-BA == DEFXU-AA ????" by PRIVAT::OTTO (getting better all the time) Wed Jun 12 1996 12:18

Hello,

I wonder what a DEFXU-AA is/was because of the following story


scenario:

the customer has two Alphaserver 1000 4/233 running OpenVMS V6.2-1H2
equipped with a DEFEA-UA that are linked to a DECconcentrator 900MX 
via UTP-FDDI.

In January the had a problem with one of the ALPHA Systems intermittandly
loosing the link to the concentrator900. At that time the MOD-PMD was 
replaced and a new sys$fwdriver ( image file build identification X61Q-SSB-
1200, link date/time 26.7.95) was given to the customer to fix the
problem.
Now they reported the same problem on the second ALPHA as well. This System 
runs PCSA and whenever the FDDI link is gone approx 300 PC's stop working.

To narrow down the failing component the customer swapped cables,  
connected the working system to the other PMD and even changed the 
MOD PMD's  on the concentrator so that the working PMD was on the 
plug where the problem giving one was before. 
(the "defective MOD PMD was replaced against a new one already")
The Problems always stayed with this one MOD PMD.

The customer tells me that even so they have the same name, the two MOD 
PMD's look totally different, where the new one with less components than 
the older one (which even contains manually soldered wires ) is the one 
that gives the problems.
On the concentrator I can see that the LEM counter is not zero on this port 
while on the other port (old PMD) it is zero.

A few numbers:

DEFXU-AA
Modul Layout : 50-21458-01
Partnr. Modul: 54-21459-01 Rev. B01   (the working one)

Logistic tells me that the DEFXU-AA was replaced by DEFXU-BA

DEFXU-BA
Modul Layout : 50-22538-01 Rev. A02
Partnr. Modul: 54-22539-01 Rev. B01   (the problem giving one)


DECconcentrator 900MX Firmware V3.1.1

Firmware Revision  ALPHASERVER 1000

SRM Console:    V3.1-2
ARC Console:    4.44
PALcode:        VMS PALcode V5.53-5, OSF PALcode V1.46-1
Serial Rom:     V1.5

Device             Current Revision

fwa0                    2.46
pka0                    A10


We managed to get another module that looks like the old one and now all 
the problems are gone.  The affected system runs now for two days without 
problems while it took only an hour to get trouble before.
I wonder whether I am the only one with this problem.

Any hints, Idea's  ???


thanks 

Otto
T.RTitleUserPersonal
Name		DateLines
3615.1probably just a one-time type failure - get it replaced...NETCAD::BATTERSBYDon't use time/words carelesslyThu Jun 13 1996 10:2715
    Otto, it would appear that the DEFXU-BA is causing link errors.
    The -BA is a new etch and circuit design from the older -AA. 
    This one your customer has been experiencing problems with is 
    probably just an escapee with a defective component. Having 
    moved it's physical position and observed that the problem moves 
    with the mod-pmd, I'd say you have a case for returning the 
    defective mod-pmd and getting a replacement. If your customer
    hasn't experienced problems with other DEFXU-BA's, I'd just
    write it off as a one-shot problem with a single defective module,
    and get the customer a replacement DEFXU.
    Both modules presumably have the same function, the new board design
    was probably just the result of making mod-pmd's more manufacturable
    for less cost (testability, smaller component count, etc.)
    
    Bob
3615.2PRIVAT::OTTOgetting better all the timeThu Jun 13 1996 12:2817
Hello Bob,

Thanks for the quick answer.
I was not clear enough in the base note.
When the customer reported a problem with the first system
getting link errors we/he was lucky to get an -AA MOD PMD.
That fixed the problem. At that time the  other system was not 
in production. However when the customer reported the second system
with this problem we first replaced the MOD PMD against a new one.
That did not fix the problem. I hope that we did not get two 
DOA. MOD PMD's, but since we have installed the "older" module
the customer has no problem  anymore. (he has now two old modules)
Unfortunately these two ALPHA Systems are the only systems
at customer site that use this type of  MOD PMD. 


Otto
3615.3Is the customer happy now or still looking for answers?NETCAD::BATTERSBYDon't use time/words carelesslyThu Jun 13 1996 12:477
    So both systems now have -AA mod pmds (which replaced -BA's)
    and are now both working with the -AA's in place? Does this
    cure all the customer's problems related to the mod pmd's?
    Sounds like the end of the problem, or is the customer asking
    for an explanation as to why the -AA's work and the -BA's don't?
    
    Bob
3615.4customer is happy , but worriedPRIVAT::OTTOgetting better all the timeFri Jun 14 1996 06:0712
Hello Bob

The customer is happy, but worried that he might go thru all of this 
again in case one of the -AA modules dies and he has to replace it.

Since logistic tells us the -AA has been replaced by the -BA variant
it always takes special "action" to get the -AA variant.
 
I wonder whether other customers experience similar problems 


Otto
3615.5Try cross posting in the FDDI conference....NETCAD::BATTERSBYDon't use time/words carelesslyFri Jun 14 1996 10:548
    I wouldn't know, but if you really want to get to the bottom of 
    this, I'd suggest cross-posting this to the FDDI notes conference
    UPSAR::FDDI. That way the FDDI mod-pmd engineering guru's here in LKG
    may be able to ask specific questions as need be, or perhaps may 
    ask for one or both of those -BA pmd's to look at. I think you may get
    more specific results/answers over in that conference.
    
    Bob