Conference 7.286::fddi

    Hi Raj,
       THis may not be the same, but according to the advanced FDDI
    training I took last month, if the power fails during a downline load
    of the DEFCN, the only way for the DEFCN to have the firmware loaded is
    to have field service come out and do an internal load using NDS. I
    believe this is because during the download process, the loader
    internal volatile-memory to move the existing and new firmware before
    moving it into NVRAM. By doing the control-C, you may now have part old
    and part new firmware and no way to go back. Pam Short if the current
    engineer working on the DEFCN, so you may want to contact her for more
    details.
    
    Debbie
    

There certainly is a problem if you get a failure between the completion of
the load, i.e., the start of the EEPROM write, and the end of the EEPROM write.
But I would have expected the load to be buffered in RAM, so that an incomplete
load (whether due to ^C, powerfail in mid-load, or network problems) has
no effect.

	paul

From what I have been told is that NDC is only used by engineering and 
manufacturing. It is not avialable to the field for use. If indeed you did 
somehow mess up the eeprom, which as paul states, is buffered first to ram, the
only way to fix it is to replace the motherboard on the concentrator. 

The only time the concentrator is vulunerable to eeprom corruption is suppose 
to be the split second it takes the ram to load the eeprom, but this after 
ndu has downline loaded to ram.

    re Paul
    
    	I believe the buffers are held in RAM, but theres not enough
    RAM to hold the current working/running image **and** the newly
    downlaoded image. As such,.. the EEPROMS are being written while
    the download is in progress :-/
    
    	The DEMFA folks avoided this problem in their device by not
    allowing certain pieces of the firmware to be changed at all. One
    of the pieces is the code to do a download. So even if you screw up
    the EEPROM image somehow,. its probably still able to download 
    itself. Apparently the DEFCN folks didn't address ths problem (?).
    
    							/Bill
    

    .4 missed here

    The DEFCN will buffer the entire down line load and only after it has
    verified that the load is correct does it attempt to blast the FLASH
    (EEPROM).  If the DEFCN took a power hit just after the load was
    completed (This window is about 30 seconds) then the FLASH could become
    corrupted.  If this situation occurs it can only be rectified by
    replacing the mother board.

    A question to the original noter, did the DEFCN have it power go away
    during the loading process or did someone just control C the downline
    load host?

    If the Host were just Control C'd that should have no effect on the
    DEFCN.  If the power did go away on the DEFCN during the loading
    process then the FLASH could be corrupt.

    One other possibility could be that you got some bad FLASH and the
    loading process failed due to a bad part.

    Any which way you will most likely have to replace the unit and send
    the old unit back to manufacturing.

    Scott

    No,  the power to the concentrator was NOT switched off at all.
    There was NO power failure.
    
    Only a control-c was done.
    
    I'm calling field service to replace the board.
    
    Raj

    re .5
    
    >    The DEFCN will buffer the entire down line load and only after it has
    >    verified that the load is correct does it attempt to blast the FLASH
    >    (EEPROM).  If the DEFCN took a power hit just after the load was
    >    completed (This window is about 30 seconds) then the FLASH could 
    >    become corrupted. 
    
    So the traffic is interrupted for a total of 30 seconds?  From the
    DEFCN Tech Desc p. 4-9, "The unit then goes off line for 1 to 5 minutes 
    while the operational code is erased and rewritten with the new code..."
  
    The interruption of traffic during a firmware upgrade is critical
    in the VAXc MDF setting and RECNXINTERVAL has to be set to a number
    that allows the VAXcluster members to ride through it.
    180 seconds has been mentioned but does anyone have the numbers for
    the traffic interruption time during a firmware upgrade on the DEFEB, 
    DEFCN and DEMFA?
     
    Bill

    The Total time that the window for programming the FLASH is open is
    about thirty seconds to sixty seconds.  This can be much higher
    depending on the actual FLASH parts in question. However the DEFCN must 
    also reset and powerup through the diagnostics before it is can resume 
    its regular functions.  Therefore the time the DEFCN is out of commission
    starts at the end of the down line load.  Then you program the FLASH
    verify the flash and then reset the DEFCN after selftest has
    successfully completed the DEFCN will return.

    Note also that the algorithm for programming FLASH allows for many
    repeat attempts which can lead to the high numbers.  These could be
    possible.  Each byte write of the part has an iterative loop up to 
    10,000 writes with a wait after each write which could happen and still
    be successful.

    I doubt that anyone can give you an exact number for traffic
    interruption.  I also would not lead anyone to expect that their
    clusters would maintain connection during an upgrade to the DEFCN. 

    Scott

    
    Sorry if I caused any confusion with my .4 reply
    
    						/Bill