OpenVMS VAXLAVC04_U2055 VAX V5.5-2 PEDRIVER ECO Summary
Copyright (c) Digital Equipment Corporation 1994, 1995. All rights reserved.
PRODUCT: OpenVMS VAX
COMPONENTS: PEDRIVER.EXE
SDA.EXE
XQDRIVER.EXE
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXLAVC04_U2055
ECO Kits Superseded by This ECO Kit: VAXLAVC03_U2055 (CSCPAT_1081)
VAXLAVC02_U2055
ECO Kit Approximate Size: 1550 Blocks
Kit Applies To: OpenVMS VAX V5.5-2 Only
System Reboot Necessary: Yes
ECO KIT SUMMARY:
An ECO (patch) kit exists for PEDRIVER on OpenVMS VAX V5.5-2. This
kit addresses the following problems:
Problems Addressed in the VAXLAVC04_U2055 Kit:
o The sequence message timeout value used to initiate retransmission
is based on the computed round trip time instead of a fixed value
as in previous version of PEDRIVER. This significantly reduces the
timeout delay when retransmission is necessary.
This fix also sends one message a time and waits for the ACK during
the retransmission.
This change also fixes the problem where retransmission from a
global page results in an ACCVIO.
These problems are fixed in OpenVMS VAX V6.0
o Nodes in a LAVc (Local Area VAXcluster) may CLUEXIT in mixed
ENET/FDDI environments where duplicate hello messages are being
produced (i.e. out-of-rev bridge firmware).
o The default HELLO message interval was changed from 3 seconds +/- .7
seconds to 3 seconds +0 seconds/-1.4 seconds. Earlier baselevels of
V6.0 could break the Virtual Circuit (VC) after loosing a single
HELLO message if the network delays were long and two HELLO messages
were sent with an interval of 3.7 seconds. This change restores the
behavior seen with V5.5-2 of providing for a long (up to 2 seconds)
network delay (PEDRIVER to PEDRIVER).
Problems Addressed in the VAXLAVC03_U2055 Kit:
o Network congestion problems may exist on an LAVc and will
manifest as anything from slow performance to broken Virtual
Circuits and CLUEXIT crashes. On a VAXstation 4000 Model 90,
this may cause an INVEXCEPTN bugcheck at PEDRIVER+060EC.
This problem is fixed in OpenVMS VAX V6.0.
o If PEDRIVER receives a command while it is in a DISABLED state,
it returns the command with an ABORT status. No other ports
generate this status, so it is treated as a malfunction and
System Communications Services (SCS) crashes the port when it is
received.
This problem is only likely to occur in a heavily loaded system.
It (combined with the next two problems) can cause a system to
get into a port-crash-and-reinit loop, which leads to a system
crash if there is no other path to the system disk.
This problem is fixed in OpenVMS VAX V6.0.
o Datagram responses with a "Virtual Circuit Closed" status crash
the port. It is possible for datagrams to be passed to SCS with
VC Closed status. This only happens when there is insufficient
non-paged pool to process the datagram command. Since this is an
illegal status for datagrams, SCS crashes the port.
This problem is fixed in OpenVMS VAX V6.0.
o When a port crash occurs, PEDRIVER does not purge entries on the
response queue. It is possible for these responses to be delivered
to the port after it reinitializes, which can cause it to crash
again. The system is allowed 50 Virtual Circuit loss/reconnects.
If the port continues to crash and reinitialize, the system could
potentially use its allotment of Virtual Circuit loss/reconnects and
crash with a VAXport bugcheck.
This problem is fixed in OpenVMS VAX V6.0.
o The system may crash with a VAXport bugcheck if a Virtual Circuit
is opened with no open channels. Normally, after a port's
Virtual Circuit closes, SCS submits a cache clear SNDMSG to the
port. SCS expects the message to fail with a "VC Closed" status.
However, in certain cases, the Virtual Circuit may be open when
SCS issues the cache clear, so the SNDMSG succeeds and the MSGSNT
comes back with success status. Since this possibility is not
explicitly accounted for, a VAXport bugcheck may occur when a
check of the opcode fails.
This problem is fixed in OpenVMS VAX V6.0.
o When transmit chaining is in use, it is possible for the datalink
to read the named buffer after the Virtual Circuit is closed
potentially causing data corruption or a system crash. This
problem occurs when the Virtual Circuit shutdown routine does not
wait for outstanding VCRPs to be returned before it reports that
the Virtual Circuit is closed.
This problem is fixed in OpenVMS VAX V6.0.
o XQDRIVER (for both the DELQA and the DEQTA) is not reporting the
correct number of receive buffers to PEDRIVER.
This problem is fixed in OpenVMS VAX V6.0.
NOTES: All Q-bus systems in a LAVc running the repaired PEDRIVER
must have version X-4 (or higher) of the XQDRIVER
installed.
Various internal structures changed as a result of the
fixes to PEDRIVER. System Dump Analyzer (SDA), and the
SCS and PEDRIVER symbol tables are included in this kit
to allow proper SDA operation. This also necessitated a
change in [SYSLIB]LIB.MLB.
User applications only need to be relinked if they require
assembly with the $PEMCOMPDEF and $PEMCLSTDEF macros.
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 VAXcluster, the entire
cluster should be rebooted.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxlavc04_u2055.README
vaxlavc04_u2055.CHKSUM
vaxlavc04_u2055.CVRLET_TXT
vaxlavc04_u2055.a-dcx_vaxexe
|
