SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
OpenVMS ALPF11X05_062 Alpha V6.2 - V6.2-1H3 F11BXQP ECO Summary

TITLE: OpenVMS ALPF11X05_062 Alpha V6.2 - V6.2-1H3 F11BXQP ECO Summary Modification Date: 20-JUN-2000 Modification Type: Documentation: Corrected reference from ALPY2K01_062 to ALPY2K02_062. NOTE: An OpenVMS saveset or PCSI installation file is stored on the Internet in a self-expanding compressed file. For OpenVMS savesets, the name of the compressed saveset file will be kit_name.a-dcx_vaxexe for OpenVMS VAX or kit_name.a-dcx_axpexe for OpenVMS Alpha. Once the OpenVMS saveset is copied to your system, expand the compressed saveset by typing RUN kitname.dcx_vaxexe or kitname.dcx_alpexe. For PCSI files, once the PCSI file is copied to your system, rename the PCSI file to kitname-dcx_axpexe.pcsi, then it can be expanded by typing RUN kitname-dcx_axpexe.pcsi. The resultant file will be the PCSI installation file which can be used to install the ECO. Copyright (c) Compaq Computer Corporation 1999. All rights reserved. PRODUCT: OpenVMS Alpha COMPONENT: F11BXQP SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: ALPF11X05_062 ECO Kits Superseded by This ECO Kit: ALPF11X04_062 (Never Released) ALPF11X03_062 ECO Kit Approximate Size: 1100 Blocks Kit Applies To: OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3 System/Cluster Reboot Necessary: Yes Rolling Re-boot Supported: Yes Installation Rating: 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: ALPCLUSIO01_062, ALPY2K02_062 In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: ALPSYSA02_062 (or its supersedent) for a $GET_SECURITY fix when reading the ORB on a file that had no synchronization with the file system. ECO KIT SUMMARY: An ECO kit exists for F11BXQP on OpenVMS Alpha V6.2 through V6.2-1H3. This kit addresses the following problems: Problems Addressed in ALPF11X05_062: o NOTFCBFCB Bugcheck on simultaneous dereference of file When two processes are accessing a file via the MOVEFILE and READATTR/FID_TO_SPEC mechanism, such as a data collector process running on the same volume as a defragger competing for the same data, both processes try to delete the 'primary_fcb' used to get the information in question. In both of these circumstances, the reference count on the FCB has not been bumped up so both accesses appear to allow the deletion. This results in a NOTFCBFCB Bugcheck. Images Affected: - [SYS$LDR]F11BXQP.EXE - [SYS$LDR]F11BXQP.STB o Lock failure on rebuild of Bound Volume Set leaves blocking lock If a process attempts to mount a bound volume set (BVS) and all the members of the BVS are not present, an attempt to lock the volume for REBUILDing the meta-data on the volume will fail. However, the blocking lock (F11B$b) is left with the process. Images Affected: - [SYS$LDR]F11BXQP.EXE - [SYS$LDR]F11BXQP.STB o XQPERR Bugcheck in LOCKERS when retry limit on F11B$x lock is reached An XQPERR Bugcheck occurs in LOCKERS when the retry limit on F11B$x lock is reached. This happens when the owner of the $x lock is running at a high process priority and there are a number of processes in a clustered system that are also trying to validate this lock but at a lower process priority. The high priority process never really gives up the locks long enough to let the low process priority processes to continue and either validate or release the $v lock. To avoid this situation, after (every) 256 attempts, the process with the most retry iterations is stalled for a short period to allow other processes to complete their accesses to the lock. Images Affected: - [SYS$LDR]F11BXQP.EXE - [SYS$LDR]F11BXQP.STB o UNXSIGNAL and/or XQPERR Bugchecks on invalid FCB In the process of finding an FCB chain, the XQP switches serialization to the primary FCB of the chain. In this process, the FCB chain an be rebuilt or destroyed while the process is stalled. If this FCB now points to another FCB chain or a deleted FCB the XQP will bugcheck with either an XQPERR bugcheck or a UNXSIGNAL (ACCVIO). Images Affected: - [SYS$LDR]F11BXQP.EXE - [SYS$LDR]F11BXQP.STB o A system could crash with an SPLACQERR bugcheck after IPL/Fork lock. A system would crash with an SPLACQERR bugcheck after the releasing of the current processes IPL/Fork lock. The SCH$QAST routine sets R4 to be the address of the target PCB when it returns. The XQP$UNLOCK_CACHE routine expects R4 to be the address of a UCB. Images Affected: - [SYS$LDR]F11BXQP.EXE - [SYS$LDR]F11BXQP.STB o NOSUCHFILE error. When a directory with multiple headers, e.g. a large ACL, is deleted on one mode in a cluster (Node A), if that directory had previously been accessed on another node in the cluster (Node B), the files created with the previously deleted headers would show up on Node B with a "NOSUCHFILE error". Images Affected: - [SYS$LDR]F11BXQP.EXE - [SYS$LDR]F11BXQP.STB Problems Addressed in ALPF11X04_062: o Disk mounted with reduced cache suppressed During the mounting of the system disk, the error message that the disk is mounted with a reduced cache is suppressed. Hence, the System Manager may be unaware that the performance of the system disk and all others attached to the same cache block is questionable. Image Affected: - [SYSEXE]FILESERV.EXE NOTE: [SYS$STARTUP]VMS$CONFIG-050_CACHE_SERVER.COM also is needed to run the FILESERV.EXE image. o UNXSIGNAL crash when deleting large file When deleting a large file (such as a system dump file), a UNXSIGNAL Bugcheck may occur. This particular bugcheck occurs because a variable in the code causes a reference to memory data that the file system does not own and an internal access violation occurs (ACCVIO). Image Affected: - [SYS$LDR]F11BXQP.EXE o PGFIPLHI crash in DEACCESS On some systems with higher rates of system paging or with WSDEC set to a non-standard value, a system can crash with a PGFLIPLHI (Page Fault IPL too High) bugcheck. This problem happened when the system returns from a SMP$ACQUIRE call. Image Affected: - [SYS$LDR]F11BXQP.EXE Page 13 o XQPERR in RDBLOK module An XQPERR can occur in the RDBLOK module during disk cleanup using DCL. Image Affected: - [SYS$LDR]F11BXQP.EXE o Crash with PGFLIPLHI/SSRVEXCPTN error When storing the value of a directory index buffer, the system may crash with a PGFLIPLHI, SSRVEXCPTN error. Image Affected: - [SYS$LDR]F11BXQP.EXE o Misplaced SYS_UNLOCK call causes crash A misplaced SYS_UNLOCK call can cause a SMPRELEASE bugcheck (crash). Image Affected: - [SYS$LDR]F11BXQP.EXE o Unnecessary copy for dismount on shadowed device A dismount on a shadowed device results in an unnecessary copy. Image Affected: - [SYS$LDR]F11BXQP.EXE o XQPERR crash in RETURN_CREDITS module during DISMOUNT An XQPERR bugcheck (crash) in the RETURN_CREDITS module can occur during DISMOUNT. Image Affected: - [SYS$LDR]F11BXQP.EXE o XQPERR crash in XQP during SET ACL A XQPERR Bugcheck (crash) in XQP can occur during an SET ACL (SET FILE/ACL) operation. Image Affected: - [SYS$LDR]F11BXQP.EXE o UNXSIGNAL/ACCVIO crash during dismount When two processes are competing to dismount a volume, one process may be just a bit faster than the other and delete the VCB and other structures before the second process has time to finish up its processing. The result is in an UNXSIGNAL/ACCVIO crash. Image Affected: - [SYS$LDR]F11BXQP.EXE o XQPERR bugcheck at module F11BXQP A device reporting a read error (SS$_PARITY) during read/write processing in the XQP will attempt to record the bad blocks and FID in the BADLOG.SYS file. When the internal close operation occurs (on BADLOG), the system XQPERR bugchecks when it finds the process's dirty buffers have not been written out. Image Affected: - [SYS$LDR]F11BXQP.EXE o UNXSIGNAL/ACCVIO crash during mount An UNXSIGNAL/ACCVIO error can occur at module F11BXQP. This problem occurs during mount, when the primary volume is not yet mounted. Image Affected: - [SYS$LDR]F11BXQP.EXE o Processes hang when dismounting a device Processes can hang (deadlock) when dismounting a device. Image Affected: - [SYS$LDR]F11BXQP.EXE o "no such file" error on directory extension FCBs A 'no such file' error can occur on directory extension FCBs. This problem can occur in at least two ways: 1. A file appears normal on one node but has an 'no such file' error from another node. 2. BACKUP or DUMP /HEADER encounters a read attributes error of NOSUCHFILE. This error occurs when an attempt is made to read a file header, for which the FCB for the old header is still in memory. Image Affected: - [SYS$LDR]F11BXQP.EXE o False EOF errors on read operation Occasional false end-of-file (EOF) errors can occur on a read operation. Image Affected: - [SYS$LDR]F11BXQP.EXE o XQP failure with SS$_BADPARAM error The XQP fails after an IO$_DEACCESS call with an SS$_BADPARAM error. One cannot determine whether a file is still open or not due to the failed IO$_DEACCESS call. Image Affected: - [SYS$LDR]F11BXQP.EXE o Non-privileged users can revise file Non-privileged users can change the revision date (and count) of a file for which they should have only READ access. For example, if a non-privileged user with READ-only file access tries to set the file protection, a failure occurs with an SS$_NOPRIV error as expected. However, the revision date (and count) are modified. Image Affected: - [SYS$LDR]F11BXQP.EXE Problems Addressed in ALPF11X03_062: o An XQPERR bugcheck error, "all the index buffers are active", occurs when running with a reduced cache or during a backup. o An XQPERR bugcheck error, "wrong lock basis with FCB present", occurs when files with ACLs are created on a full volume. o It is possible to serialize on the wrong volume in a volume set. o If more than one process queues for a volume's activity blocking lock, the XQP can deadlock. o Various XQPERR bugchecks occur in directory scanning/shuffling. o A crash may occur during creation of a file with a version limit of 1 if SYSTEM_CHECK is on or bit 5 or 6 of ACP_DATACHECK is 1. An XQPERR bugcheck occurs due to a corrupted directory. o The NOTIFY_USER for final status of an XQP request occurs too early in XQP request completion to report any errors produced in cleanup or auditing. This normally does not cause a problem since USER_STATUS is not expected to change during cleanup. However, if it does change, then the output of SET WATCH FILE is misleading. o XQP requests to create a new file with version limits set can fail with an SS$_NOSUCHFILE error. o Deleting a stale alias on a directory with extension headers can bugcheck with an XQPERR "lock index has shifted" error. This problem occurs when: 1. An alias to an existing file is created; 2. The original file is deleted; and 3. The original file's file header is reused as an extension header of the alias's parent directory (when ACEs are added to the directory). o Prevent access to file headers beyond index file highwater-marking (HWM). It is possible to ACCESS by FID a file header beyond the current end of the index file on a freshly-initialized volume. Creating a new file accessed in this way can bugcheck the system with the XQPERR error. o Fix a reserved operand fault bugcheck on $QIO exit. The $QIO failed on return because the IPL was set to zero but was entered at IPL 2. o $GET_SECURITY was reading the ORB on a file without any synchronization with the file system. In the best case, this problem can lead to bad information being returned. In the worst case, if the filesystem was rebuilding the ORB's ACL chain at the time, a kernel mode ACCVIO can occur. *** Note: In order to get this fix, ALPSYSA01_062 or its supersedent must also be installed on the system. 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.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alpf11x05_062.README
alpf11x05_062.CHKSUM
alpf11x05_062.CVRLET_TXT
alpf11x05_062.a-dcx_axpexe
alpf11x05_062.CVRLET_TXT

privacy and legal statement