![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The mmg$gl_memsize global cell does not contain the memory hole. As a result, the system has only 7/8 GB of memory, but according to the algorithm in releases prior to OpenVMS Alpha Version 7.1, it appears that the device can use the direct DMA window. Yet there is 128 MB of memory beyond the 1 GB border, which requires that the drivers use map registers. To eliminate this problem, drivers using the algorithm in releases prior to OpenVMS Alpha Version 7.1 must substitute it with the following algorithm:
int dma_size;
int pages;
status = IOC$NODE_DATA (crb, IOC$K_DIRECT_DMA_SIZE, &dma_size);
/* dma_size contains the number of megabytes.
* convert number of megabytes to bytes.
*/
dma_size = dma_size * (1024 * 1024);
/* Convert number of bytes to number of pages by
* dividing by number of bytes per page.
*/
pages = dma_size / MMG$GL_PAGE_SIZE;
The driver for the Microsoft Windows Sound System ISA sound card (MSB), SYS$MSBDRIVER, has been removed from the OpenVMS Alpha distribution as of Version 7.0. The following files have been removed:
An enhanced version of this driver, called MMOV$MSBDRIVER, is included in Multimedia Services Version 2.0 for OpenVMS Alpha. This layered product also includes support for video capture and playback, an enhanced version of DECsound, and other audio and video applications.
MMOV$MSBDRIVER provides the same $QIO programming interface as
SYS$MSBDRIVER. Digital recommends that the WAVE Applications
Programming Interface provided by Multimedia Services for OpenVMS be
used instead because it is more flexible and is portable to other
platforms. (Multimedia Services Version 2.0 for OpenVMS is described in
SPD 64.24.00.)
6.9 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.
A future release of OpenVMS Alpha may provide a platform-independent
mechanism for drivers to determine the device IPL dynamically.
6.10 AlphaStation 255: PCI Configuration Restriction
V7.1
The OpenVMS Alpha operating system does not support PCI option cards configured in PCI slot 0 on any AlphaStation 255 series systems.
PCI slot 0 is the lowest physical PCI option slot on AlphaStation 255
series systems. The interrupt signal for this slot is shared with the
built-in Ethernet port. Because the OpenVMS Alpha operating system does
not currently permit PCI devices to share an interrupt line, a PCI
device installed in slot 0 will not function correctly or might cause
errors to occur with the built-in Ethernet port. As a result of this
restriction, AlphaStation 255 series systems support a maximum of two
PCI option cards, configured in slot 1 and slot 2.
6.11 Recommendation for RZ25M and RZ26N Disk Drives (Alpha)
V7.1
During the testing of Digital 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, these drives are not recommended for use 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, listed as supported in the OpenVMS SPD, may be used
in configurations to the full bus lengths of the SCSI-2 specification.
6.12 SCSI Controller Restriction on AlphaServer 2100 Systems
The Adaptec 1740/1742 SCSI controller (PB2HA--SA) is not supported on AlphaServer 2100 systems having more than 1 gigabyte (GB) of memory. If the controller is connected to such a system, the following message appears on the operator's console:
%PKJDRVR-E- PKX0, Port is going OFFLINE.
The following sections relate to SCSI firmware support.
6.13.1 Recommended Firmware Support for RZ26N and RZ28M Disks
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 may occur.
6.13.2 Required Firmware for Multi-Host Use of RZ26L and RZ28 Disks
V6.2
If you install RZ26L or RZ28 disks on a multi-host SCSI bus in an OpenVMS Cluster, the disk's minimum firmware revision is 442.
The following sections describe a procedure that can be used 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.
Important Note
Only certain RZ26L and RZ28 firmware revisions can be safely upgraded to firmware revision level 442. Refer to Section 6.13.2.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.13.2.2 to update the disk's firmware.
Only the combinations of disk drives and firmware revision levels listed in Table 6-1 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-1 for the file name of the disk you are upgrading.)
$ MCR SYS$ETC: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.
V6.2
The following sections describe OpenVMS Alpha SCSI class and port
device driver restrictions.
6.14.1 Add-On SCSI Adapters
V6.2
Version 6.2 and later of OpenVMS Alpha supports various add-on SCSI adapters. Digital's AlphaGeneration platforms typically support one or more integral SCSI adapters, with the option of installing additional add-on SCSI adapters. Due to differences in device-naming conventions used between the Alpha console and OpenVMS, the OpenVMS device name may not match the name displayed by the console.
For example, the console designation for a SCSI device on the integral SCSI adapter may be DKA100. However, when two additional add-on SCSI adapters are added, the "A" designation becomes "C"; and DKA100 appears as DKC100 when OpenVMS is running.
Note that although the console and OpenVMS device names may be different, the unique specification of a device name from the console to the device name under OpenVMS will stay consistent, provided add-on SCSI adapters are not added or removed.
For information about device naming on certain OpenVMS Alpha systems,
see Appendix A.
6.15 OpenVMS VAX Device Support Documentation Corrections
This section describes corrections to OpenVMS VAX device support
documentation.
6.15.1 OpenVMS VAX Device Support Manual
V6.1
The following sections describe corrections to the OpenVMS VAX Device Support Manual. (This
manual has been archived but is available in PostScript and DECW$BOOK
(Bookreader) formats on the OpenVMS Documentation CD--ROM. A printed
book can be ordered through DECdirect (800--344--4825).)
6.15.1.1 Linking a Device Driver
Chapter 12 of the OpenVMS VAX Device Support Manual, Version 6.0, describes how to assemble, link, and load a device driver. In step 3 of the procedure for preparing a driver for loading into the operating system, append the following text to the end of the procedure (following the paragraph that begins: "The resulting image must..."):
To produce an image with a symbol table compatible with the System Dump Analyzer (SDA), you must link again; this time, using the UNIVERSAL=* option statement (to include all global symbols and to ensure proper state of the REL bits in the object records). Relink as shown in the following example:
$ LINK /NOEXECUTABLE/NOTRACEBACK/NOSYSSHR - _$ /SYMBOLS=MYDRIVER.EXE,- _$ /SHARE=DUMMY_FILE_NAME,- _$ /NOMAP,MYDRIVER1.OBJ,MYDRIVER2.OBJ,- _$ SYS.STB/SELECTIVE,- _$ SYS$INPUT/OPTION _$ BASE=0 _$ UNIVERSAL=*
For more information about the Linker, see the OpenVMS Linker Utility Manual.
6.15.1.2 Device-Register I/O Space: Usage Restrictions
Chapter 5 of the OpenVMS VAX Device Support Manual, Version 6.0, describes device driver coding and the restrictions on the use of device-register I/O space. The third sentence of the fifth bulleted paragraph in Section 5.2 states that the instructions that refer to UNIBUS adapter registers must use longword context. This is the wrong bus. The sentence should read:
The following sections describe corrections to the OpenVMS VAX Device Support Reference Manual. (This
manual has been archived but is available in PostScript and DECW$BOOK
(Bookreader) formats on the OpenVMS Documentation CD--ROM. A printed
book can be ordered through DECdirect (800--344--4825).)
6.15.2.1 COM$DRVDEALMEM Routine Synchronization
Chapter 3 of the OpenVMS VAX Device Support Reference Manual, Version 6.0, contains a section describing the COM$DRVDEALMEM routine.
At the end of the paragraph under Synchronization, add the following sentence:
"If called at IPL$_SYNCH or higher, the routine executes the fork
process."
6.15.2.2 CRB Data Structure
Chapter 1, Section 1.7, of the OpenVMS VAX Device Support Reference Manual, Version 6.0, contains Table 1-8 describing the CRB data structure fields. The description in the table for the CRB$L_INTD field is confusing and needs clarification. Replace the first two sentences in the CRB$L_INTD description as follows:
| Field Name | Description |
|---|---|
| CRB$L_INTD | Portion of the interrupt transfer vector block that stores executable code, driver entry points, and I/O adapter information. This 10-longword area is overlaid with the contents of the interrupt transfer vector block that starts at VEC$L_INTD (offset 16) as described in Section 1.7.1. It contains pointers to the driver's... |
Chapter 1 of the OpenVMS VAX Device Support Reference Manual, Version 6.0, contains a section describing the SCDRP data structure SCSI flags.
In the SCDRP$L_SCSI_FLAGS field description for bit SCDRP$V_LOCK, make the following correction:
| Change: | SCDRP$VLOCK | |
| To: | SCDRP$V_LOCK |
Chapter 2 of the OpenVMS VAX Device Support Reference Manual, Version 6.0, contains a section describing the SPI$CONNECT macro.
In the table listing the required inputs, add:
| R4 | Address of the SPDT |
In the values returned in R3, the SPDT$M_CMDQ bit was added to the port capability mask (SPDT$L_PORT_FLAGS). When set, SPDT$M_CMDQ indicates that the port driver supports command queuing I/O.
In the return values table listing R3 and the mask bits (after SPDT$M_LUNS), add:
| SPDT$M_CMDQ | Supports command queuing I/O |
Chapter 2 of the OpenVMS VAX Device Support Reference Manual, Version 6.0, contains sections describing the SPI$GET_CONNECTION_CHAR and SPI$SET_CONNECTION_CHAR macros. Appended to the macro characteristics buffer is longword #12 for SCSI-2 support.
At the end of the characteristics buffer table in these macro descriptions, add the longword #12 information as follows:
Chapter 2 of the OpenVMS VAX Device Support Reference Manual, Version 6.0, contains a section describing the $EQULST macro.
In the parameter description for symbol,value insert the phrase in decimal as follows:
"...and value specifies in decimal the value of the symbol."
AlphaServer 1000A systems have seven PCI option slots and two EISA option slots, in addition to an integrated QLogic 1020A Fast Wide SCSI controller. The OpenVMS operating system and the console do not always assign the same names to devices in these option slots. In addition, the slot numbering convention used by the console and the OpenVMS operating system does not match the physical slot numbers on the backplane.
The EISA slots are connected using a PCI-to-EISA bridge on the primary PCI bus. The upper three PCI option slots (numbered 1 to 3) are also on the primary PCI bus, while the lower four PCI option slots (numbered 4 to 7) are connected using an integrated PCI-to-PCI bridge. The QLogic 1020A SCSI controller is in a fixed position relative to the option slots; this controller is always configured as the first device behind the integrated PCI-to-PCI bridge, preceding slots 4 to 7. (See Figure A-1.)
Figure A-1 AlphaServer 1000A Hardware Backplane
The OpenVMS operating system assigns device names in the following order:
Consider a system with only a KZPSA SCSI controller in slot 1, the first slot on the primary PCI bus. The KZPSA appears as PKA, and the integrated QLogic 1020A appears as PKB. If another KZPSA were added in slot 4, behind the integrated bridge, it would appear as PKC. If yet another KZPSA were added in slot 3, the third slot on the primary PCI bus, the device names would shift; the original KZPSA in slot 1 remains PKA, the new KZPSA in slot 3 becomes PKB, the QLogic becomes PKC, and the KZPSA in slot 4 becomes PKD.
In another example, consider a system with one KZPSA in slot 4. This
KZPSA is behind the integrated bridge, behind the QLogic 1020A, and
appears as PKB with the QLogic 1020A as PKA. A system with only bridge
cards in its option slots, for instance, P1SE bridges with integrated
SCSI controllers, would always see the QLogic 1020A as PKA and the SCSI
controllers on the P1SE bridges as PKB and so forth.
A.1.1 Restriction for PCI Adapters
As shown in Figure A-1, PCI slots 4-7 on AlphaServer 1000A systems
are connected by an integrated PCI-to-PCI bridge. Certain PCI adapters,
such as the KZPSM, also contain an onboard PCI-to-PCI bridge. Because
the KZPSM is not supported in PCI slots 4-7, you must place that
adapter in PCI slots 1, 2, or 3.
A.2 Device Naming on AlphaServer 4100 Systems
AlphaServer 4100 systems have eight PCI option slots, three of which are shared with EISA option slots. Because the OpenVMS operating system and the console each have their own device naming conventions, the console name of a device will not necessarily match the OpenVMS name of a device. In addition, the slot numbering convention used by the console and the OpenVMS operating system does not match the physical slot order on the backpanel.
AlphaServer 4100 systems also include an integrated NCR810 SCSI controller and an integrated PCI/EISA bridge. The integrated NCR810 SCSI controller is connected directly to the compact disc reader.
The order in which OpenVMS names devices is shown by the OpenVMS Probe Order column in Figure A-2.
Figure A-2 AlphaServer 4100 Hardware Backpanel
The integrated NCR810 controller (connected to the compact disc reader) will always be assigned the same name by both the console and by OpenVMS because it is always named first. The OpenVMS operating system assigns device names in the following order (using the OpenVMS probe numbers shown in Figure A-2):
AlphaServer 2100A systems have eight PCI option slots and three EISA option slots, in addition to an integrated NCR810A SCSI controller. The OpenVMS operating system and the console do not always assign the same names to devices in these option slots. In addition, the slot numbering convention used by the console and by the OpenVMS operating system does not match the physical slot numbers on the backplane.
The EISA slots are connected using a PCI-to-EISA bridge on the primary PCI bus. The bottom four PCI option slots (hardware numbers 4 to 7) are also on the primary PCI bus, while the remaining four PCI option slots (the top slots, hardware numbers 0 to 3) are connected using an integrated PCI-to-PCI bridge. The NCR810A SCSI controller is in a fixed position relative to the option slots; the NCR810A controller is always configured as the first device behind the integrated PCI-to-PCI bridge, preceding PCI slots 0 to 3. (See Figure A-3.)
Figure A-3 AlphaServer 2100A Hardware Backplane
The OpenVMS operating system assigns device names in the following order:
Consider a system with only a KZPSA SCSI controller in slot 4, the first slot on the primary PCI bus. The KZPSA appears as PKA, and the integrated NCR810A appears as PKB. If another KZPSA were added in slot 0, behind the integrated bridge, it would appear as PKC. If yet another KZPSA were added in slot 6, the third slot on the primary PCI bus, the device names would shift; the original KZPSA in slot 4 remains PKA, the new KZPSA in slot 6 becomes PKB, the 810A becomes PKC, and the KZPSA in slot 0 becomes PKD.
In another example, consider a system with one KZPSA in slot 0. This
KZPSA is behind the integrated bridge, behind the 810A, and appears as
PKB, with the 810A as PKA. A system with only bridge cards in its
option slots, for instance, P1SE bridges with integrated SCSI
controllers, would always see the 810A as PKA and the SCSI controllers
on the P1SEs as PKB and so forth.
A.4 Device Naming on AlphaStation 600 Systems
AlphaStation 600 Series systems have three 64-bit PCI option slots, one 32-bit PCI option slot, and one option slot that can be used either as a 32-bit PCI option slot or as an EISA slot. (See Figure A-4.)
The OpenVMS operating system and the console do not always assign the same names to devices in these option slots.
Figure A-4 AlphaStation 600 Hardware Backplane
The OpenVMS operating system assigns device names in the following order:
Consider a system with a KZPSA SCSI controller in slot 8 and a P2SE PCI-to-PCI bridge card with two SCSI controllers in slot 9. The KZPSA will appear as PKA, and the P2SE SCSI controllers will appear as PKB and PKC. Swapping the cards so that the KZPSA is in slot 9 and the P2SE is in slot 8 will not change the device names. The KZPSA will still appear as PKA, and the P2SE SCSI controllers will still appear as PKB and PKC.
This appendix lists remedial kits that are included in OpenVMS Version 7.1.
Digital updates existing kits and creates new kits as necessary. Contact your Digital support representative for the latest information about new remedial kits.
The following sections list the remedial kits included in Version 7.1 of the OpenVMS VAX and OpenVMS Alpha operating systems. If you used to install one of the kits listed here, you will not need to do so with Version 7.1.
Kit names are constructed from the following information in this order:
For example, VAXUAF01_070 is the first remedial kit created to correct
the Authorize utility that shipped in Version 7.0 of OpenVMS VAX.
B.1 Remedial Kits Included in OpenVMS Alpha Version 7.1
The following remedial kits are included in Version 7.1 of the OpenVMS Alpha operating system:
The following remedial kits are included in Version 7.1 of the OpenVMS VAX operating system:
This appendix contains notifications about OpenVMS products that are no
longer supported or that are slated for retirement. It also lists
manuals that have been archived with this release.
C.1 DEC 3000 Series Workstations: PXG Graphics Board Not Supported (Alpha Only)
6481P009.HTM OSSG Documentation 11-DEC-1996 07:52:38.47
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.