OpenVMS VAXPHV02_070 VAX V7.0 Ethernet Drivers ECO Summary

 
NOTE:  An OpenVMS saveset or PCSI installation file is stored
       on the Internet in a self-expanding compressed file.
       The name of the compressed file will be kit_name-dcx_vaxexe
       for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
 
       Once the file is copied to your system, it can be expanded
       by typing RUN compressed_file.  The resultant file will
       be the OpenVMS saveset or PCSI installation file which
       can be used to install the ECO.
 
Copyright (c) Digital Equipment Corporation 1996.  All rights reserved.

PRODUCT:    OpenVMS VAX

COMPONENT:  Ethernet Drivers 
              ECDRIVER
              EFDRIVER
              EPDRIVER
              ESDRIVER
              ETDRIVER
              EXDRIVER
              EZDRIVER
              FCDRIVER
              FQDRIVER
              FXDRIVER
              NET$CSMACD
              NET$FDDI
              XEDRIVER
              XQDRIVER

SOURCE:     Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXPHV02_070
     ECO Kits Superseded by This ECO Kit:  VAXPHV01_070
     ECO Kit Approximate Size:  1080 Blocks
     Kit Applies To:  OpenVMS VAX V7.0
     System/Cluster Reboot Necessary:  Yes

     Installation Rating:  3 - To be installed on all systems running
                               the listed versions of OpenVMS which
                               are experiencing the problems described.

     NOTE:  In order to receive the full fixes listed in this kit,
            the following remedial kits also need to be installed:

                 None


ECO KIT SUMMARY:

An ECO kit exists for several network drivers on OpenVMS VAX V7.0.
This kit addresses the following problems: 

Problems addressed in VAXPHV02_070 kit ECO kit:

   o  A fix to cure a minor memory leak exposed a more severe problem,  
      double deallocation of pool, resulting generally in a system crash.  
      This kit removes the memory leak fix.

   o  Crash after DECnet Time Service is shut down.

   o  There is a race condition in the DEMNA and DEBNI drivers where a  
      packet can be received before the completion of a STOP USER command.  
      Since DECnet time service apparently does a deassign of a channel  
      instead of a stop followed by a deassign, the driver has to stop  
      completing receives to the user at the instant the stop request is 
      received rather than waiting for completion of the command to the 
      device that stops it.  There was a short time where a receive packet 
      could come in for a user that the driver knew nothing about, resulting  
      in a crash.                                               


Problems addressed in VAXPHV01_070 ECO kit:

  o  A system crash may occur if a LAN user disappears during 
     DEMFA re-initialization.  This happens when the DEMFA is
     unplugged from the Gigaswitch.

  o  A system crash may occur during the deletion of a LAT link
     from LATCP when the device is shutting down to perform a 
     normal reset.  The system crash occurs in FQDRIVER or FCDRIVER.

  o  A system crash may occur in NET$FDDI during the processing
     of a set station directive as a result of a DECnet-OSI NCL
     command.

  o  A system crash may occur at NET$FDDI+50DD during shutdown
     startup when an attempt is made to access an FDDI network
     management data structure that does not exist.  It is 
     possible for a DECnet-OSI user to create an FDDI station  
     with CSMACD Network Management data structures.

  o  Allocating a local data structure and overwriting existing
     pointers causes 106 bytes of memory to be "lost" when the
     last user of the port is deleted.  

  o  A machine check may occur on a Q-BUS system with a DEFQA 
     FDDI controller installed.  The bugcheck reason is reported 
     as an ASYNCWRTER, Asynchronous write memory failure.

  o  LANCP MOP cannot be enabled at the same time as DECnet-MOP
     even when selective mode is specified.

  o  After upgrading to V6.2, MOP downline loads appear to be
     very slow.  Loading that normally took 5 minutes is now 
     taking 30 minutes.  A LAN trace shows that the remote device
     being loaded is responding to ALL the MEMLOAD packets sent to
     it.  However, the load host is delaying 3-4 seconds and
     retransmitting MEMLOAD packet even though the satellite has
     already requested the next MEMLOAD.


INSTALLATION NOTES:

In order for the corrections in this kit to take effect, the system
must be rebooted.  If the system is a member of a VMScluster, the 
entire cluster should be rebooted. 

Colorado Site
Georgia Site

vaxphv02_070.README
vaxphv02_070.CHKSUM
vaxphv02_070.CVRLET_TXT
vaxphv02_070.a-dcx_vaxexe