|
|
 |
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.
|
Files on this server are as follows:
|
»vaxphv03_062.README
»vaxphv03_062.CHKSUM
»vaxphv03_062.CVRLET_TXT
»vaxphv03_062.a-dcx_vaxexe
|
