Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
ALPF11X03_061 for OpenVMS Alpha V6.1 F11BXQP ECO Summary
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
OP/SYS: OpenVMS Alpha
COMPONENT: File System - F11BXQP.EXE (XQP)
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: ALPF11X03_061
ECO Kits Superseded by This ECO Kit: ALPF11X01_071 (for V6.1 only)
ALPF11X03_070
ALPF11X01_070
ALPF11X01_062
AXPF11X02_061
AXPF11X01_061
ECO Kit Approximate Size: 890 Blocks
Saveset A - 864 Blocks
Kit Applies To: OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2
System/Cluster Reboot Necessary: Yes
Installation Rating: 1 - To be installed on all systems running
the listed versions of OpenVMS.
NOTE: In order to receive the full fixes listed in this kit,
the following remedial kits also need to be installed:
ALPSYS08_070
ECO KIT SUMMARY:
An ECO kit exists for F11BXQP on OpenVMS Alpha V6.1 through V6.1-1H2.
This kit addresses the following problems:
PROBLEMS ADDRESSED IN ALPF11X03_061 for OpenVMS Alpha V6.1:
o An XQPERR bugcheck occurs when trying to create a file.
o A bad FID (File ID) bugcheck occurs when trying to mark a file
header free in the index file bitmap.
o There are multiply allocated blocks and file headers on the
disk.
o Processes hang in an RWAST state while trying to deaccess a
file during channel deassignment.
o The system hangs during cluster wide cache flushes.
o The contents of a header or bitmap block could be corrupted
within the block buffer cache.
o Failure to take an allocation lock could be ignored.
o If a DEACCESS request failed with a SS$_DEADLOCK error, a
process could be left in RWAST state indefinitely.
o If a large file is created on a fragmented disk that has quotas
enabled and the user needs to use EXQUOTA privilege to allocate
the necessary disk space, an internal XQP table can become
corrupted. This leads to the following bugcheck:
SECAUDERR, Fatal error attempting to perform a security audit
o Attempting to queue a maximal length (39.39;5) filename to the
XQP for spooling to a symbiont would cause either an infinite
CPU loop or a FILCNTNONZ, Open file count nonzero after process
rundown bugcheck.
PROBLEMS ADDRESSED IN ALPF11X01_071 KIT FOR OpenVMS Alpha V6.1:
o The problem occurs when a file is deleted while still being
accessed by someone. This produces an XQPERR bugcheck when an
attempt is made to access the deleted file.
o The problem may result in an XQPERR bugcheck which claims that:
"all the index buffers are active" during the processing of a
directory file.
The problem occurs when no free directory index BFRD's are
found on the first pass through MAKE_DIRINDX. The thread then
stalls to allow some of the BFRD's to be freed, but doesn't
release the cache lock which would allow others to do this.
This means that if no free BFRD was found on the first try then
none will be found on subsequent tries either, and the bugcheck
will occur.
PROBLEMS ADDRESSED IN ALPF11X03_070 KIT FOR OpenVMS Alpha V6.1:
o BACKUP and SLS can cause WCBFCBMNG bugchecks when operating on
some files. These files are legal, uncorrupted files so they
should not repeatedly cause a crash whenever BACKUP or SLS
tries to back them up.
o A system could crash with a SECAUD bugcheck whenever
ANAL/DISK/etc is run on a corrupted disk with auditing turned
on.
o The XQP bugchecks when a file is accessed for the first time,
with cathedral windows, and the accessing process runs out of
BYTLM quota.
o Window mapping code could incorrectly concatenate extents which
ran from one volume to another in a volume set.
o XQPERR bugcheck in [F11X]DIRSCNuPDATE_INDEX() when trying to
insert index entry into directory index block with
DIR$W_TOTALCELLS equal to zero.
o Directory FCBs can become stale but invisible to the XQP. The
File IDs can then be reused, and if the FCB in question was an
extension FCB, the next time the new file is accessed on that
node, the XQP bugchecks with the fatal XQPERR 'wrong lockbasis
with FCB present'.
o If a file is opened for exclusive access on one node in a
cluster and a BACKUP/IGNORE=INTERLOCK command is issued to
backup the file on that node, after the BACKUP completes the
file can be successfully accessed from the other node(s) of the
cluster. The BACKUP destroys the exclusive access.
PROBLEMS ADDRESSED IN ALPF11X01_070 KIT FOR OpenVMS Alpha V6.1:
o The OpenVMS Alpha V6.1 images in the ALPF11X01_062 kit did not
contain the complete fixes listed.
PROBLEMS ADDRESSED IN ALPF11X01_062 KIT FOR OpenVMS Alpha V6.1:
o The system crashes with a BADFID bugcheck.
o File name appears twice in a directory block.
o System crashes with a BADDALRQSZ bugcheck
o Multiple allocated blocks being reported after the defragger
o UNXSIGNAL crash due to a corrupt Window Control Block
o File Access Control Lists are corrupted after a failure to
allocated an extension File Control Block due to disk quota
being exceeded.
o The system crashes with 'BADFID, ACP file number out of range
for this volume"
The system crashes with 'Failed to allocate FID when expected'
This problem is fixed in OpenVMS Alpha V7.0
o On a disk with highwater marking enabled, a file is created
with several extents, of which any extent, except the last one,
exceeds 2 Gb in size. When a write operation is performed on a
block in the last extent of the file, the user may see blocks
of a different file erased incorrectly.
This problem is fixed in OpenVMS Alpha V7.0
o Lock Ranking Violation when using EDIT/EDT. The problem is
caused under the following circumstances:
- User B does not have an entry in the quota file.
- User A has CONTROL access to user B's files. CONTROL
access grants the accessor all the privileges of the
objects actual owner. User A can have this access by
either:
- being a member of the SYSTEM group
- having the necessary entry in an ACL.
- User A edits one of user B's files using edit/EDT.
This problem is fixed in OpenVMS Alpha V7.0
o On a large, very fragmented disk with little free space and
heavy usage, an XQP lock ranking violation can occur on a
regular basis
This problem is fixed in OpenVMS Alpha V7.0
PROBLEMS ADDRESSED IN ALPF11X01_062 KIT FOR OpenVMS ALPHA V6.1:
o When issuing a set security/volume command from the command
line, it is possible to make the XQP crash.
This problem is fixed in OpenVMS Alpha V6.2
o The user sees an XQPERR bugcheck, with a message in the code
'FCBs must be in ascending order', although with XQP+ there can
be an unexpected lock manager error on a DEQ (where the
DIRLCKID and PRIMFCB fields of an FCB overlap and we try to DEQ
an FCB address. The broken FCB chain in question is invariably
for a multi-header directory (produced by PATHWORKS V5 putting
lots of ACLs on the directory).
This problem is corrected in OpenVMS Alpha V6.2
PROBLEMS ADDRESSED IN AXPF11X02_061 KIT for OpenVMS Alpha V6.1:
o After deletion of a large file, the free disk space value
reported by SHOW DEVICE can indicate that disks have more or
less free space than they actually have.
o Fix an XQPERR bugcheck which can occur during an IO$_CREATE
function (usually RENAME).
Fix an XQPERR bugcheck which occurs when attempting to create a
file on a volume set when a previous version of the file
exists.
This problem is fixed in OpenVMS Alpha V6.2
o Massive POSIX forking will result in a K-stack invalid crash.
This problem is fixed in OpenVMS Alpha V6.2
o Restore ability to use wildcard values for valid UIC owner and
group value ranges.
This problem is fixed in OpenVMS Alpha V6.2
o Process hangs in LEF or RWAST (if you try to delete it) when
the VMS File System (XQP+) has not finished initialization
before it is being called to deassign/deaccess a global section
file.
This problem is fixed in OpenVMS Alpha V6.2
PROBLEMS ADDRESSED IN AXPF11X01_061 KIT for OpenVMS Alpha:
o As of VAX V6.0 and Alpha V6.1 the XQP MOVEFILE primitive allows
movement of directory files, so long as no node in the cluster
has data from these files cached.
The cluster-wide check for this condition did not work
properly. This results in cache incoherency, and as a result,
directory file corruption.
Common symptoms are:
o out of order directory listings
o duplicate directory entries for the same file
o "lost" files
o inconsistent directory listings on different nodes
o files appearing in directory listings which are
not"accessible" from the RMS level (e.g. you can't type
them)
This problem is fixed in OpenVMS Alpha V6.2
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS database. To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'ALPF11X03_061' or 'ALPF11X', or 'XQP'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
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.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| F11BXQP.EXE | 18F8BFC6 | XQP A6.1R-0010 | 4-SEP-1997 |
| | | 18:06:00.84 |
+----------------------------+----------+-----------------+--------------+
|
