|
|
HP Services Software Patches - vaxphv02_070
|
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.
Files on this server are as follows:
|
»vaxphv02_070.README
»vaxphv02_070.CHKSUM
»vaxphv02_070.CVRLET_TXT
»vaxphv02_070.a-dcx_vaxexe
|