V9.2-3 Update V2.0 ECO Kit for VSI OpenVMS x86-64

INSTALL_1: To be installed by all customers.

This installation rating serves as a guide to which customers should apply this remedial kit.

Reference the Disclaimer of Warranty and Limitation of Liability Statement.

A reboot is mandated as part of installing this kit, performed automatically following the kit installation.

VSI OpenVMS for the x86 architecture uses a memory disk image, stored on the system disk, when booting the system. The content of the memory disk must remain consistent with the system disk content.

This kit updates the memory disk image and invokes a system reboot sequence (shutdown with reboot) directly as part of the kit installation. You must be prepared to allow the system reboot when installing the kit. After all other kit actions are complete, the system will automatically shutdown and reboot.

If you allow the reboot, you will have the choice of whether to invoke the site-specific shutdown procedure, SYS$MANAGER:SYSHUTDWN.COM during the shutdown portion of the reboot.

By default, after installation completes, the minutes until shutdown is zero. If you wish to leave additional time before the shutdown begins, define the system logical name SHUTDOWN$MINIMUM_MINUTES as the integer value of the wait time in minutes. For example:

$ DEFINE/SYSTEM SHUTDOWN$MINIMUM_MINUTES 10

No other options for the shutdown may be specified.

The shutdown will commence directly after the memory disk update as the final portion of the kit installation.

VSI OpenVMS x86-64 V9.2-3

This kit will create a new memory disk image file during PRODUCT INSTALL or PRODUCT UNDO PATCH operations. This file is required for x86 systems bootstrap. If this file cannot be correctly created, the target disk will not be bootable and you will need to restore from backup.

During PRODUCT INSTALL, the kit will check for sufficient space on the target disk. The minimum free space is 600,000 blocks to ensure that the memory disk image file and kit files can safely fit on the disk.

Additionally, a check is made to determine if the disk is too fragmented to correctly create the memory disk file. If either check fails, the installation will be aborted before making any changes. After you take any necessary corrective actions to free up disk space or defragment the volume, the PRODUCT INSTALL can be re-attempted.

These same checks are not automatically handled by the kit before a PRODUCT UNDO PATCH operation. This is not a frequent operation for customer systems. Should you need to remove this kit, you should ensure sufficient disk space before you start. The same 600,000 block minimum applies. To check fragmentation requirements, you can use the following commands:

$ ANALYZE/DISK/EXTENTS/REQUIRED=200000/NOOUTPUT disk
$ SHOW SYMBOL ANALYZE$REQUIRED_EXTENTS

If the symbol value is 25 or more, the disk is too fragmented and you should defragment it before using PRODUCT UNDO PATCH. You can accomplish this using a defragmentation tool or by restoring an image backup.

Problem Description

A routine that had "callq" as the last instruction would sometimes not have its associated condition handler invoked if the routine encountered an exception condition.

The common unwind routine in LIBRTL used in condition handler searches is now corrected (see Section 5.8, ''Condition Handler Stack Unwind May Fail on Certain Exceptions'').

The OpenVMS executive exception handling now correctly locates the associated condition handler routine for this case.

Images and/or Files Affected

• [SYS$LDR]EXCEPTION.EXE
• [SYS$LDR]EXCEPTION.STB
• [SYS$LDR]EXCEPTION_MON.EXE
• [SYS$LDR]EXCEPTION_MON.STB

VSI Case Identifier

Jira BO-1973

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

The MONITOR DISK/ITEM=QUEUE_LENGTH command would sometimes display a large, non-zero queue length for members of bound volume sets, even though the disk may actually have been idle.

This issue only occurred for bound volume sets consisting of multiple disk devices using the Fast I/O mechanism. The queue length fields were being updated inconsistently between the various volume set members.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]IO_ROUTINES.EXE
• [SYS$LDR]IO_ROUTINES.STB
• [SYS$LDR]IO_ROUTINES_MON.EXE
• [SYS$LDR]IO_ROUTINES_MON.STB

VSI Case Identifiers

Jiras DRIV-553, DRIV-554

Netsuite NS8211

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

During procedure call handling, a very rare circumstance could cause the system to fail with the following crash:

KRNLSTAKNV, Kernel stack not valid

This crash is unpredictable in nature and very unlikely in production environments.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]SYSTEM_PRIMITIVES.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.STB

VSI Case Identifier

Jira BO-2009

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

Access checks against a buffer that has access to the start address but not the end address will correctly signal an access violation. However, an immediate re-check against the same buffer start address where the buffer was now accessible would sometimes trigger a spurious access violation.

VSI has only encountered this behavior in a regression test that was specifically inducing access failures. To encounter it with production software is extremely unlikely.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]SYSTEM_PRIMITIVES.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES.STB
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
• [SYS$LDR]SYSTEM_PRIMITIVES_MIN.STB

VSI Case Identifiers

Jiras QTV-1168, BO-2071

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

If a buffer PROBE access check exceeds the end of the current user stack, the stack is automatically extended. However, an immediate re-PROBE using the same starting address would sometimes incorrectly signal an access violation.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]EXCEPTION.EXE
• [SYS$LDR]EXCEPTION.STB
• [SYS$LDR]EXCEPTION_MON.EXE
• [SYS$LDR]EXCEPTION_MON.STB

VSI Case Identifier

Jira BO-2059

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

When a process is logging out or exiting, the virtual address space for that process is torn down and resources are returned to the system. However, if a doubly-mapped page was encountered during this processing, the system would sometimes crash with a DELCONPFN bugcheck.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]SYS$VM.EXE
• [SYS$LDR]SYS$VM.STB
• [SYS$LDR]SYS$VM_MON.EXE
• [SYS$LDR]SYS$VM_MON.STB

VSI Case Identifiers

Jiras SPS-1273, BO-1971

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

The ACPI (Advanced Configuration and Power Interface) mechanism on x86-64 systems may interrupt the system to deliver information regarding device configuration or power management.

On some x86-64 hosts, an "interrupt storm" from the ACPI subsystem mechanism may occur, delivering on the order of 50,000 interrupts per second for an unknown period of time. This can consume from 30% to 60% of an entire CPU in interrupt context to field and dismiss the interrupts. As far as we can determine, there is no underlying issue of any particular significance to the operating system for these events.

The ACPI handling code for OpenVMS has been enhanced to detect this condition. If it occurs, the ACPI interrupts are disabled and the code will switch to a polling mode to learn of any events which are relevant to OpenVMS.

Images and/or Files Affected

• [SYS$LDR]SYS$ACPI.EXE
• [SYS$LDR]SYS$ACPI0006.EXE
• [SYS$LDR]SYS$SEDRIVER.EXE

VSI Case Identifier

Jira BO-1833

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

RTL Changes

Problem Description

A routine that had "callq" as the last instruction would sometimes not have its associated condition handler invoked if the routine encountered an exception condition.

The common unwind routine in LIBRTL used in condition handler searches is now corrected.

The corrected unwind mechanism is built into LIBRTL for run-time use and in the STARLET.OLB object module for programs that must link the code statically.

Images and/or Files Affected

• [SYSLIB]LIBRTL.EXE
• [SYSLIB]LIBRTL.STB
• LIB$$X86_UNWIND.OBJ, a module in [SYSLIB]STARLET.OLB

VSI Case Identifier

Jira BO-1973

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

The Debugger would sometimes return a BADSTACK error during a STEP/INSTRUCTION command. For example:

%DEBUG-I-INITIAL, Language: BASIC, Module: ALEXA

DBG> step/inst
%DEBUG-W-BADSTACK, WARNING: stack corrupted; session integrity not guaranteed
stepped to ALEXA\ALEXA+1: movq    %rsp,%rbp
DBG>

This problem occured when multiple procedure ICB (Invocation Control Block) structures were used in parallel. The Debugger uses these to provide procedure tracing or stack unwinding operations. Some of the context from one ICB was mistakenly reused in a subsequent ICB.

The problem occurs in the run-time library routine that allocates and initializes an ICB.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYSLIB]LIBRTL.EXE
• [SYSLIB]LIBRTL.STB

VSI Case Identifiers

Jira BO-2101, DEV-2860

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

DEBUG Changes

Problem Description

The following issues in the Debugger have been corrected with this update:

Images and/or Files Affected

• [SYSLIB]DEBUG.EXE
• [SYSLIB]DEBUGSHR.EXE

VSI Case Identifier

Jira DEV-2860

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

ACME Changes

Problem Description

The SET PASSWORD/GENERATE command in a command procedure with the MIXED_CHARACTER generation algorithm could not generate passwords longer than 32 characters. Even if PWDMINIMUM was greater than 32, only a list of 32-character passwords was generated.

This issue has been corrected with this update. Passwords may be generated up to the supported limit of 64 characters.

Images and/or Files Affected

• [SYSEXE]SETP0_ACME.EXE

VSI Case Identifier

Jira UT-315

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

Trace content and error log entries for the OpenVMS ACME Agent have been updated for more consistent and accurate reporting.

A few minor behavioral errors have also been corrected.

Images and/or Files Affected

• [SYSLIB]VMS$VMS_ACMESHR.EXE

VSI Case Identifier

Jira BO-1710

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

Multiple command procedure files may be submitted for batch processing using a single SUBMIT command. The procedures will execute serially within the same batch job process.

If the ACME login mechanism was enabled for user authorization on the system, such a batch job would fail with %SYSTEM-F-ACCVIO status when attempting to start the second procedure.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYSEXE]LOGIN_ACME.EXE

VSI Case Identifier

Jira BO-2041

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Workaround

The suggested workaround for this issue is to create a single command procedure file that invokes each of the specific procedures in order. For example, instead of using the following command:

$ SUBMIT A,B,C

submit a single procedure consisting of the following lines:

$ @A
$ @B
$ @C

Problem Description

When configured for external authentication, attempting to login with a username string that ends in the separator character "\" would trigger errant audits and possibly an ACME Server restart.

The following is an example of a malformed username at login:

Username: SALES\

This issue has been corrected with this update.

Images and/or Files Affected

• [SYSLIB]LDAPACME$LDAP-STD_ACMESHR.EXE

VSI Case Identifiers

Jiras BO-673, BO-706

Netsuite NS2054

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Workaround

The suggested workaround for this issue is to not end a username with "\".

Problem Description

If the OpenVMS ACME login was enabled, a process created using LOGINOUT.EXE as the image parameter to $CREPRC from a program in user mode would fail to authenticate and the created process would immediately terminate.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYSLIB]VMS$VMS_ACMESHR.EXE

VSI Case Identifier

Jira BO-2038

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Security Server Changes

Problem Description

A bug in the Security Server led to an incorrectly initialized structure. This eventually caused stack corruption and a resultant access violation, which in turn caused the server to restart.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYSEXE]SECURITY_SERVER.EXE

VSI Case Identifiers

Jiras BO-2023, BO-2024

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

I/O Device Driver Changes

Problem Description

This change enables PCI passthrough support for HPE SN1100Q, SN1600Q, and SN1610Q QLogic Fibre Channel cards on ESXi, Red Hat Enterprise Linux, and Oracle QEMU/KVM Linux Hypervisors.

This provides support only for Fibre Channel data disks. Booting from a Fibre Channel disk is not supported.

Images and/or Files Affected

• [SYS$LDR]SYS$PGQDRIVER.EXE
• [SYSEXE]SYS$CONFIG.DAT

VSI Case Identifiers

Jiras DRIV-192, DRIV-503, DRIV-511, DRIV-516, DRIV-560

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

The OpenVMS SATA device driver (PKDDRIVER) has been modified to enable the following enhancements:

Images and/or Files Affected

• [SYS$LDR]SYS$PKDDRIVER.EXE

VSI Case Identifiers

Jiras BO-1763, DRIV-523

Netsuite NS7612

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Problem Description

A synchronization error in the virtio-scsi device driver would sometimes lead to virtio-scsi device stalls or system hangs.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]SYS$VSPDRIVER.EXE

VSI Case Identifier

Jira BO-1885

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

LAN Changes

Problem Description

Network connectivity would sometimes be lost due to stale MAC address use during net application initialization.

A network application (such as DECnet) may change the MAC address. Should that application be stopped when no other applications are present, the MAC address should be changed back to the default value.

A bug in the virtio-net driver (EVDRIVER) incorrectly left the device with the now-closed application MAC value.

A new application starting would assume it was using the default MAC address, but the device was still using the stale MAC address. This resulted in failure to transmit and receive packets using the default MAC address.

This issue has been corrected with this update.

Images and/or Files Affected

• [SYS$LDR]SYS$EVDRIVER.EXE

VSI Case Identifier

Jira DRIV-555

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

Workaround

The suggested workaround for this issue is to reset the device when it is found to be non-functional. For example, the following command would reset the device EIA:

$ MCR LANCP UPDATE DEVICE/RESET EIA

This will reset the default MAC address properly.

MACRO Programming Support

Problem Description

Programs written in MACRO that use floating-point instructions for arithmetic, conversions, or comparisons may not work properly. The code that emulates VAX floating-point instructions sometimes returns incorrect operation condition codes.

For example:

These issues do not affect programs written in high-level languages.

Only programs written in MACRO that use floating-point instructions are affected. Such programs must be re-linked after installing this ECO kit in order to use the corrected floating-point emulation.

Images and/or Files Affected

• XMAC_FLOAT.OBJ, a module in [SYSLIB]STARLET.OLB

VSI Case Identifiers

Jiras BO-2085, BO-2090

Release Version of VSI OpenVMS That Will Contain This Change

The next VSI OpenVMS x86-64 release after V9.2-3.

This kit is provided for download within a ZIP archive container file.

Info-ZIP's freeware ZIP and UNZIP tools are provided for use on this VSI OpenVMS version. Your site may have already set up symbols for these tools or other equivalent ZIP tools. If not, use the following command to define a symbol to run the UNZIP image:

$ UNZIP == "$SYS$SYSDEVICE:[VMS$COMMON.SYSHLP.UNSUPPORTED.UNZIP]UNZIP"

Then invoke UNZIP to unpack the kit using the command:

$ UNZIP VMS923X_UPDATE-V0200

This will extract the installable PCSI product kit file and its associated signed manifest (_VNC file) used for kit validation during PRODUCT commands.

VSI strongly recommends always using the manifest to validate the kit content during any PRODUCT commands. This will occur automatically if the files are both contained in the same directory.

Install this kit with the POLYCENTER Software Installation Utility by logging into the SYSTEM account and typing the following command at the DCL prompt:

$ PRODUCT INSTALL VMS923X_UPDATE [/SOURCE=location_of_kit]

The kit location may be a CD/DVD or a disk directory that contains the kit. The /SOURCE qualifier is not needed if the PRODUCT INSTALL command is executed from the same directory as the kit location.

This kit requires the use of /RECOVERY_MODE and /SAVE_RECOVERY_DATA and will automatically set them; they do not need to be present on the command line.

The release notes for any kit may be extracted prior to kit installation using the PRODUCT EXTRACT RELEASE_NOTES command.

User-selectable options for installation behavior and scripting are available in this kit. Refer to Appendix A, "User-Selectable Control Options and Scripting Considerations" for further details.

Additional help on installing PCSI kits can be found by typing HELP PRODUCT INSTALL at the system prompt.

Should you need to remove this kit via PRODUCT UNDO PATCH, the same mandated reboot requirement is in effect as the memory disk image is changed back to the prior system content.

The kit will update the memory disk image automatically as the final part of installation. There is currently no mechanism within the PCSI utility to cleanly invoke a system reboot for PRODUCT UNDO PATCH.

You will be instructed as the kit exits that you must perform this function manually in this case.

%INSTALL-I-NONRESSHRADR, image installed ignoring '/RESIDENT' image_name
-INSTALL-E-NOGHREG, insufficient memory in the code or data granularity hint region

%INIT-F-GHREGIONFULL, An allocation was attempted from GH region GH_RES_CODE_S2 but
                      there is not enough space in the region for the allocation.

   There is not enough space on the memory disk.
   You must take these steps now to complete this installation:

     -  Run @SYS$UPDATE:SYS$MD
     -  Reboot the system

If you change the login mechanism from ACME to UAF (or vice versa) after installing this kit, you will need to take an additional step if you later remove the kit using the PRODUCT UNDO PATCH command.

During PRODUCT UNDO PATCH, the PCSI utility is unaware that the LOGINOUT and SETP0 images in use by the system have different content from when the kit was installed. This can result in stale content or the wrong login style images in use after PRODUCT UNDO PATCH.

To avoid a spurious change in the system login mechanism, use the SYS$MANAGER:SYS$LOGIN_SWITCH.COM procedure to reset the login style to the desired mechanism, using the following command:

$ @SYS$MANAGER:SYS$LOGIN_SWITCH

You may use SYS$LOGIN_SWITCH.COM to either:

If you have not changed the login style, the PRODUCT UNDO PATCH command will correctly restore the login state with no additional user actions required.