|
|
 |
OpenVMS VMS72_F11X-V0200 Alpha V7.2 F11BXQP ECO Summary
|
TITLE: OpenVMS VMS72_F11X-V0200 Alpha V7.2 F11BXQP ECO Summary
Modification Date: 07-OCT-1999
Modification Type: Updated Kit: Supersedes VMS72_F11X-V0100
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 1999. All rights reserved.
OP/SYS: OpenVMS Alpha
COMPONENT: F11BXQP
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VMS72_F11X-V0200
DEC-AXPVMS-VMS72_F11X-V0200--4.PCSI
ECO Kits Superseded by This ECO Kit: VMS72_F11X-V0100
DEC-AXPVMS-VMS72_F11X-V0100--4.PCSI
ECO Kit Approximate Size: 896 Blocks
Kit Applies To: OpenVMS Alpha V7.2
System/Cluster Reboot Necessary: Yes
Rolling Re-boot Supported: Yes
Installation Rating: INSTALL_1
1 - To be installed on all systems running
the listed version(s) of OpenVMS.
Kit Dependencies:
The following remedial kit(s) must be installed BEFORE
installation of this kit:
VMS72_HARDWARE-V0100 Or VMS72_UPDATE-V0100
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 the F11BXQP on OpenVMS Alpha V7.2. This kit
addresses the following problems:
Problems Addressed in VMS72_F11X-V0200:
o Since the VMS72_F11X-V0100 kit only checks to see if the
VMS72_UPDATE-V0100 kit has been installed, the installation
fails if only the VMS72_HARDWARE-V0100 kit is installed. Since
the VMS72_HARDWARE-V0100 kit includes the VMS72_UPDATE-V0100 kit,
the installation should also check to see if the
VMS72_HARDWARE-V0100 kit is installed and continue the installation
if it has been.
This kit corrects this problem by checking for both the
VMS72_UPDATE-V0100 and VMS72_HARDWARE-V0100 kits.
There are no functional changes in this kit. If you have
installed the VMS72_F11X-V0100 kit, you do not need to install
this kit.
Problems Addressed in VMS72_F11X-V0100:
o An XQPERR bugcheck in LOCKERS can occur when the retry limit
on the F11B$x lock is reached.
This problem can occur when the owner of the $x lock is
running at a high process process priority and a number of
processes that are in a clustered system are also trying to
validate this lock, but at a lower process priority.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o After releasing the current process's IPL/Fork lock, a
system can crash with an SPLACQERR bugcheck
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o A directory file becomes "corrupt" and DUMP/DIRECTORY
displays a block similar to the following:
Virtual block number 3574 (00000DF6), 512 (0200) bytes
0000 Directory Entry:
0000 Size: 508
0002 Version limit: 32767
0004 Type: 0 (FID)
0005 Name count: 24
0006 Name: COSLR1201_01_JUPICC2.LIS
001E Version: 7859 FID: (40993,5,0)
0026 Version: 7858 FID: (40990,1,0)
002E Version: 7857 FID: (40988,3,0)
...
01E6 Version: 7802 FID: (40455,1,0)
01EE Version: 7801 FID: (40454,1,0)
01F6 Version: 32767 FID: (16744447,65535,0)
01FE End of records (-1)
The directory shuffle code creates the above erroneous
directory entry for the following reasons:
1. So that a new directory buffer will have a valid
structure (this allows VALIDATE_DIRBLK to write
the block to disk); and
2. The entry will be spotted as incorrect (via VERIFY)
if the system crashes in the middle of this shuffle.
After the directory block (with the erroneous directory entry)
is written to disk, the bad entry is removed. A subsequent
call to READ_BLOCK assumes that the block comes from the
buffer cache and not from disk. Under heavy load, this
assumption may not be true as the directory block may have
been kicked out of the cache.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o XQP DELETE code accepts an FCB (File Control Block) off the
limbo queue if not IO$V_DELETE. This prevents the
invalidation of VIOC cache blocks as the result of a RENAME
operation. This causes a large amount of XQP (FCB) and VIOC
(CFCB) non-paged pool usage as well as XQPERR bugchecks.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o Under the following circumstances,
1. A directory with multiple headers (e.g., from a large ACL)
is deleted on one node (A) in a cluster; and
2. the directory had been previously accessed on another node
(B) in the cluster,
The files created with the previously deleted headers in step
1 would show up on node B with the error:
%SYSTEM-F-NOSUCHFILE, no such file.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
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:
|
»dec-axpvms-vms72_f11x-v0200--4.README
»dec-axpvms-vms72_f11x-v0200--4.CHKSUM
»dec-axpvms-vms72_f11x-v0200--4.pcsi-dcx_axpexe
»vms72_f11x-v0200.CVRLET_TXT
|
