| Previous | Contents |
This section contains release notes pertaining to the DECwindows X11
display server for OpenVMS Alpha systems.
6.10.1 S3 Multihead Graphics
Permanent Restriction
Alpha computers equipped with S3 Trio32 or Trio64 graphics cards
support single-screen display only. Multihead graphics are not
supported.
6.10.2 Multiple USB Keyboards and Mice Not Supported on DECwindows on OpenVMS V8.3
V8.3
DECwindows supports input from only a single mouse or keyboard. If
additional keyboards or mice are connected when the system is booted,
only the devices configured as KBD0 and MOU0 will function, the others
will be inoperable. If additional keyboards or mice are connected after
DECwindows has been started, they can cause a system crash. The system
crash will be corrected in an ECO patch subsequent to this release.
6.11 DIGITAL Modular Computing Components (DMCC)
This section contains release notes pertaining to DMCC.
6.11.1 Alpha 5/366 and 5/433 PICMG SBC Restriction
Permanent Restriction
The KZPDA SCSI Controller and the PBXGA Graphics Card cannot be placed
in a slot behind the bridge on the DIGITAL Modular Computing Components
(DMCC) Alpha 5/366 and 5/433 PICMG SBCs.
6.11.2 Updating the SRM Console
To update the SRM console on the Alpha 4/233 (21064a), 4/266 (21164a), 5/366, and 5/433 DMCC systems, you must choose either the SRM console or the AlphaBIOS setup. You can store only one console.
If you accidentally update both the SRM and the AlphaBIOS consoles, you
will enter the AlphaBIOS Setup menu, and you will not have the
option to return to the SRM console. The only way to exit the AlphaBIOS
Setup menu and return to the SRM console is to use a Firmware Update
Utility located at the following Internet site:
6.12 Digital Personal Workstation: Booting OpenVMS V7.3-1 and Higher
V7.3-1
If you are using the Digital Personal Workstation 433au, 500au, and 600au series systems, you can boot OpenVMS Version 7.3-1 or higher from an IDE CD if the controller chip is a Cypress PCI Peripheral Controller. You cannot boot OpenVMS on a Digital Personal Workstation au series system from an IDE CD with an Intel Saturn I/O (SIO) 82378 chip in your configuration. You must use a SCSI CD, if the Intel SIO chip is present.
To determine which IDE chip you have in your configuration, enter the following SRM console command:
SHOW CONFIGURATION |
If you see Cypress PCI Peripheral Controller, you can boot OpenVMS.
If you see Intel SIO 82378, you will need to use and boot from
a SCSI CD.
6.13 Dual-Controller HSGnn with Many LUNs Can Fail Under Heavy I/O Load
V7.3-2
A combination of improvements in driver performance and faster systems has uncovered a limit to the amount of I/O that a dual-controller HSGnn storage array configured with a relatively large number of LUNs can handle. When this limit is reached, it is possible for the array to be kept so busy processing I/O that it is unable to complete the normal periodic synchronization between controllers, causing a controller hang or failure and a loss of host access to some or all LUNs until a manual controller reset is performed. In the case of such a controller failure, the Last Failure Codes most likely to be reported on the HSG console are 01960186, 01942088, and 018600A0.
Most HSGnn devices will continue to run with no problems. If your site experiences an HSG controller hang or failure when a heavy load is applied and the HSG has more than approximately 24 LUNs configured, you may be able to avoid future hangs or failures by reconfiguring the controller with fewer LUNs or distributing I/O so that the HSG is not so heavily loaded.
This issue is being investigated by the appropriate HP engineering
groups.
6.14 Open3D Graphics Licensing Change
V8.2
The 3D graphics display capability has traditionally been licensed separately from the OpenVMS operating system. Since its initial offering, the Open3D layered product has required a separately orderable license. When Open3D software began shipping as part of the OpenVMS operating system, the 3D graphics display feature continued to be a separately licensed capability. An example of this licensing is Open3D licensing to support 3D graphics display with the 3X-PBXGG-AA ATI RADEON 7500 PCI 2D/3D graphics adapter.
Starting with OpenVMS Version 8.2, the 3D graphics display feature is licensed with the operating system for both AlphaServers and Integrity servers. Therefore, the Open3D license is not available for Version 8.2 of OpenVMS. Previous versions of OpenVMS still require the Open3D license to be installed on the system for 3D display operation.
HP will continue to support 3D device drivers shipped with OpenVMS Version 7.3-2 under standard contract or Mature Product Support, depending on your support agreement. Device drivers for the following adapters have shipped with Version 7.3-2 of OpenVMS:
These adapters will continue to run 3D graphics display under OpenVMS Version 8.2 but will no longer require a license. In addition, the following 2D graphics adapters continue to be supported with OpenVMS Version 8.2:
The ATI RADEON 7500 PCI graphics adapter will be supported on OpenVMS
I64 Version 8.2 in the near future. Testing is currently in progress.
An announcement will be posted on the following website when support
for this graphics card is available:
6.15 PowerStorm 300/350 PCI Graphics Support for OpenVMS
V8.2
For release notes on the PowerStorm 300/350 PCI graphics controller support for a Compaq Workstation running OpenVMS Alpha, refer to the PowerStorm 300/350 OpenVMS Graphics Release Notes Version 2.0. These documents, release notes, and installation guides are shipped with the graphics cards.
Open3D License No Longer Checked
Starting with OpenVMS Version 8.2, the license to use 3D (OpenGL) support is included as part of the OpenVMS license. See Section 6.14 for details.
Defining the DECW$OPENGL_PROTOCOL Logical
When you run a 3D graphics application and display output to a system with a PowerStorm 350/300 graphics card, you must make sure the DECW$OPENGL_PROTOCOL logical is defined as follows on the system on which you are running the application:
$ DEFINE DECW$OPENGL_PROTOCOL DECW$OPENGL_PROTOCOL_V11 |
Previously, the P350 would sometimes fail to reinitialize properly on session exit.
This problem has been fixed by two modifications:
V6.2
A problem exists with the microcode for earlier versions of RF31T, RF31T+, RF35, RF35+, RF73, and RF74 DSSI disk devices. The problem can cause data loss, and occurs when reading data from one of these devices, if the device has had a controller memory error (also known as an error detection and correction (EDC) error). The error could have been induced by a virtual circuit closure or faulty hardware.
HP advises customers with any of these devices to check their microcode revision levels. If the microcode revision levels are lower than the numbers shown in Table 6-2, HP recommends that you update the microcode.
The microcode for all models, except RF31T, RF31T+, and RF35+, is provided on the latest OpenVMS binary distribution CD.
The RF_VERS utility, a utility program that displays the microcode revision level of the DSSI disk devices, is also provided on the CD. Instructions both for using the utility program and for updating the microcode are provided in this section.
If you have an RF31T, RF31T+, or RF35+ disk drive with a version of microcode that is not supported (see Table 6-2), and if you have a support contract, contact your HP support representative. Otherwise, contact your authorized reseller. |
The earliest supportable revision levels of the DSSI disk microcode are shown in Table 6-2.
| Device Type | Minimum Level with Supported Microcode |
|---|---|
| RF31T | T387E |
| RF31T+ | T387E |
| RF35 | T392D |
| RF35+ | T392D |
| RF36 | V427P |
| RF73 | T392D |
| RF74 | V427P |
To display the microcode revision level of your DSSI disk devices, perform the following steps:
$ SET PROCESS /PRIVILEGE=(DIAGNOSE,CMKRNL,SYSPRV) $ SHOW DEVICE FYA0: |
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONN FYA0/NOADAP SYSGEN> ^Z |
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> IO CONNECT FYA0: /NOADAP SYSGEN> ^Z |
The following is an example of the display produced by the RF_VERS utility:
Program Name: RF_VERS
Revision Level: V1.2s
NOTICE: This program does not currently support the RF72 or any
HSDxx controllers. See next version for support.
DSSI disks currently on this system as seen by RF_VERS
Device Node Status Hardware Firmware
Name Name Type Version
_$22$DIA7: R4JL2I mounted RF73 T387A
_$22$DIA6: R4I0BG mounted RF73 T387A
_$22$DIA8: R4XLWE mounted RF73 T387A
_$22$DIA2: R4FCZK mounted RF73 T387A
_$22$DIA3: R4CKCG mounted RF73 T387A
_$22$DIA4: R4ZKUE mounted RF73 T387A
_$22$DIA9: R4GYYI mounted RF73 T387A
_$22$DIA1: R4XRYI mounted RF73 T387A
|
To update the microcode in your device, use the appropriate command for your device and platform from Table 6-3.
Back up the disk before updating the microcode. |
| Device Type | Platform | Command |
|---|---|---|
| RF35 | Alpha | $RUN SYS$ETC:RF35_T392F_DEC_ALPHA.EXE |
| RF35 | VAX | $RUN SYS$ETC:RF35_T392F_DEC.EXE |
| RF36 | Alpha | $RUN SYS$ETC:RF36_V427P_DEC_ALPHA.EXE |
| RF36 | VAX | $RUN SYS$ETC:RF36_V427P_DEC.EXE |
| RF73 | Alpha | $RUN SYS$ETC:RF73_T392F_DEC_ALPHA.EXE |
| RF73 | VAX | $RUN SYS$ETC:RF73_T392F_DEC.EXE |
| RF74 | Alpha | $RUN SYS$ETC:RF74_V427P_DEC_ALPHA.EXE |
| RF74 | VAX | $RUN SYS$ETC:RF74_V427P_DEC.EXE |
Do not delete SCSI_INFO.EXE, RF_VERS.EXE, or any of the files listed in Table 6-3. If these files are deleted, VMSKITBLD.COM (on VAX) will not be able to find them. Similarly, on Alpha systems, the PRODUCT INSTALL commands in AXPVMS$PCSI_INSTALL and AXPVMS$PCSI_INSTALL_MIN will fail. |
The following notes describe issues related to various RZ disk drives.
6.17.1 RZ25M and RZ26N Disk Drives: Recommendations
V7.1
During the testing of HP supported SCSI disk drives on configurations with DWZZAs and long differential SCSI buses, two drives, RZ25M and RZ26N, were found to have bus phase problems. For this reason, do not use these drives in configurations where the differential bus length connecting DWZZAs equals or exceeds 20 meters.
This recommendation applies only to the RZ25M and RZ26N drives. All
other disk drives that are listed as supported in the OpenVMS SPD can
be used in configurations to the full bus lengths of the SCSI-2
specification.
6.17.2 RZ26N and RZ28M Disks: Recommended Firmware Support
V6.2-1H3
The minimum firmware revision level recommended for RZ26N and RZ28M disks is Revision 0568.
If the latest firmware revision level is not used with these disks,
multiple problems can occur.
6.17.3 RZ26L and RZ28 Disks: Required Firmware for Multihost Use
V6.2
If you install RZ26L or RZ28 disks on a multihost SCSI bus in an OpenVMS Cluster, the disk's minimum firmware revision is 442.
The following sections describe a procedure that you can use to update the firmware on some RZ26L and RZ28 drives. This procedure can only be used with drives that are directly connected to a SCSI adapter on a host system. Drives that are attached through an intelligent controller (such as an HSZ40 or KZPSC) cannot be updated using this procedure. Refer to the intelligent controller's documentation to determine whether an alternative firmware update procedure exists.
Only certain RZ26L and RZ28 firmware revisions can be safely upgraded to firmware revision level 442. Refer to Section 6.17.3.1 to determine if your disks are capable of being upgraded to firmware revision level 442. If your disk is capable of supporting firmware revision level 442, use the RZTOOLS utility that is described in Section 6.17.3.2 to update the disk's firmware. |
Only the combinations of disk drives and firmware revision levels listed in Table 6-4 are capable of being upgraded safely to firmware revision level 442. Performing the update procedure on any other combination can permanently damage the disk.
| Disk Drive | Firmware Revision | Disk File Name |
|---|---|---|
| RZ26L | 440C | RZ26L_442D_DEC.FUP |
| RZ28 |
441C or D41C
435 or 436 |
RZ28_442D_DEC2104.FUP
RZ28P4_442C_DEC.FUP |
If you determine that your disk requires revision level 442 firmware and it is capable of being upgraded safely, use the following procedure to update the firmware. (See Table 6-4 for the file name of the disk you are upgrading.)
$ RZTOOLS_ALPHA :== $SYS$ETC:RZTOOLS_ALPHA $ RZTOOLS_ALPHA DKB500 /LOAD=SYS$ETC:filename.FUP Read in 262144 bytes. Current FW version - X440C Upgrading to - DEC0 Loading code ...... New code has been sent to the drive. |
V8.3
The HP Integrity Superdome cannot boot as a satellite over the Core I/O
LAN card. When you specify the LAN card as a boot option to
BOOT_OPTION.COM and you then shut down the operating system, the LAN
card does not appear in EFI. The problem will be fixed in a future
release of the firmware.
6.19 ZLX Graphics Boards Support
V8.2
The following families of graphics controller boards are not supported on OpenVMS Version 8.2:
As of OpenVMS Version 8.2, only 2D support, using the base 2D capabilities shipped with OpenVMS, is provided for the following families of graphics controller boards. Please do not install Open3D to obtain 2D support for the following:
See Section A.1 for a related note.
6.20 Recompiling and Relinking OpenVMS Device Drivers
The following sections contain release notes pertaining to recompiling and relinking OpenVMS device drivers.
For related release notes, see Section 5.4.
6.20.1 Alpha and VAX SCSI Device Drivers
V7.3-1
All OpenVMS Alpha SCSI device drivers from previous versions of OpenVMS must be recompiled and relinked to run correctly on OpenVMS Version 7.3-1 or higher.
If you have an OpenVMS Alpha SCSI driver that you are upgrading from a version prior to OpenVMS Alpha 7.0, see Section 6.20.2.
Note that for OpenVMS Version 7.1 all OpenVMS VAX SCSI device drivers
required recompiling and relinking. OpenVMS VAX device drivers that
were recompiled and relinked to run on OpenVMS Version 7.1 will run
correctly on OpenVMS Version 7.3 or higher.
6.20.2 OpenVMS Alpha Device Drivers
V7.1
Device drivers that were recompiled and relinked to run on OpenVMS Alpha Version 7.0 do not require source-code changes and do not have to be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and higher. (Note that Alpha SCSI drivers, however, must be recompiled and relinked as described in Section 6.20.1.)
Device drivers from releases prior to OpenVMS Alpha Version 7.0 that were not recompiled and relinked for OpenVMS Alpha Version 7.0 must be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and higher.
OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha
privileged interfaces and data structures. As a result of these
changes, device drivers from releases prior to OpenVMS Alpha Version
7.0 may also require source-code changes to run correctly on OpenVMS
Alpha Version 7.0 and higher. For more details about OpenVMS Alpha
Version 7.0 changes that may require source changes to customer-written
drivers, refer to the HP OpenVMS Guide to Upgrading Privileged-Code Applications.
6.21 Device Driver MON Version Handling
V7.3
As of OpenVMS Version 7.3, when SYSTEM_CHECK is enabled, device driver
images with names of the form SYS$nnDRIVER_MON.EXE will be
automatically loaded by the system loader. If a corresponding _MON
version does not exist, the system will use the default image name:
SYS$nnDRIVER.EXE.
6.22 Possible Per-Threads Security Impact on Alpha Device Drivers
V7.2
See Section 5.4.7 for information about how possible per-thread
security impacts OpenVMS Alpha device drivers.
6.23 Device IPL Setup for OpenVMS Alpha Drivers
V6.2
Alpha hardware platforms that support PCI, EISA, and ISA buses deliver I/O device interrupts at different IPLs, either 20 or 21. The IPL at which device interrupts are delivered can change if you move the device from one platform to another. This is a problem if the driver declares its device IPL to be 20, and then that driver is executed on a machine that delivers I/O device interrupts at IPL 21.
The simplest solution to this problem is for PCI, EISA, and ISA device drivers to use IPL 21. This works correctly on platforms that deliver I/O device interrupts at IPL 20 and on platforms that deliver I/O device interrupts at IPL 21.
| Previous | Next | Contents |