OpenVMS VAXPHV03_062 VAX V6.2 Ethernet Drivers ECO Summary

TITLE: OpenVMS VAXPHV03_062 VAX V6.2 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) Compaq Computer Corporation 1996, 1999. All rights reserved. Modification Date: 17-FEB-99 Modification Type: Updated Kit Supersedes VAXPHV02_062 PRODUCT: OpenVMS VAX COMPONENTS: Network Drivers ECDRIVER FCDRIVER EFDRIVER FQDRIVER EPDRIVER FXDRIVER ESDRIVER NET$CSMACD ETDRIVER NET$FDDI EXDRIVER XEDRIVER EZDRIVER XQDRIVER SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: VAXPHV03_062 ECO Kits Superseded by This ECO Kit: VAXPHV02_062 ECO Kit Approximate Size: 1100 Blocks Kit Applies To: OpenVMS VAX V6.2 System/Cluster Reboot Necessary: Yes Rolling Re-boot Supported: Yes Installation Rating: INSTALL_3 - To be installed on all systems running the listed versions of OpenVMS which are experiencing the problems described. Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this kit: None In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None ECO KIT SUMMARY: An ECO kit exists for several network drivers on OpenVMS VAX V6.2. This kit addresses the following problems: Problems Addressed in the VAXPHV03_062 Kit: o For a command: NCL> SHOW FDDI STATION FDDI-0 * ALL the SMTstationID field was displayed as '0000000000000000'H, but should have been '080008002B209E45'H. o A crash occurred in module FX$SCHED_CMDUNS_FORK while doing a DEVICELOCK. The crash occured under the following conditions: 1. FDDI (DEMFA) 2. MOPRC (60-02) 3. crash address FXDRIVER+022E4 4. current process was running TSM$MAIN o During testing of failover to a second FDDI controller, after an FDDI cable was removed, a SET HOST command hung for one minute, resulting in a bugcheck at TIMER.BUG. Note that the problem did not cause a fatal error and allowed the FDDI ring to resynchronize. o DECnet hung for 1 minute when the FDDI cable was removed from the bulkhead. o Attempting to start the MOPRC protocol on a DEMFA returned an SS$_DEVREQERR error status. o If a DEMFA FDDI controller fails, then transmit requests can possibly fail to complete within a timeout period. The failure that a user sees is that the FDDI path fails and then the cluster software does not switch to another path, usually resulting in a CLUEXIT error. o When the cable is disconnected from the DEMFA FDDI controller, timing problems can occur in the driver, which could result in a crash after an extended period of cable disconnections (typically weeks). o The LAN Driver received a loopback packet with a broadcast destination address, which was an invalid use of the loopback protocol (90-00) format. However, the packet was not regarded as invalid, resulting in a crash at EZDRIVER+072E3. o A user had a problem with failover on the DEMFA on a VAX system. Although a transmit timeout had occurred, the transmit completed with an error status and continued. Since the failure happened in such a way that the link did not go down and come back up, a failover never happened. o A crash occurred during timeout processing and it can happen on a VAX 4000-90, VAX 4000-300, etc., that also has an SGEC Ethernet adapter. Problems Addressed in the VAXPHV02_062 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 A system crash may occur after DECnet Time Service is turned off. 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 the VAXPHV01_062 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 Applications do not receive packets larger than the buffer size specified by the first user to start up. For example: If the first user specifies a receive buffer size of 300 bytes, the DEMNA firmware discards all packets received that are larger. This problem is corrected in OpenVMS VAX V7.0. o A QIO with a null pointer to the P2 parameter causes an Invalid Exception (INVEXCEPTION) crash. This can occur on all Ethernet and FDDI LAN drivers. This problem is corrected in OpenVMS VAX V7.0. 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: The images in this kit will not take effect until the system is rebooted. If there are other nodes in the VMScluster, they must also be rebooted in order to make use of the new image(s). If it is not possible or convenient to reboot the entire cluster at this time, a rolling re-boot may be performed. All trademarks are the property of their respective owners.

This patch can be found at any of these sites:

Files on this server are as follows:

vaxphv03_062.README
vaxphv03_062.CHKSUM
vaxphv03_062.CVRLET_TXT
vaxphv03_062.a-dcx_vaxexe