|
HP OpenVMS Systems Documentation |
|
OpenVMS Alpha Partitioning and Galaxy Guide
Chapter 8
|
http://h18002.www1.hp.com/alphaserver/firmware/ |
An AlphaServer ES40 has one clock. For an OpenVMS Galaxy, this means that you cannot run the two instances at different times. Also, the SET TIME command affects both instances. Note that this may not become evident until a number of hours have passed.
On a rack-mounted system:
COM1 (lower) is the console port for instance 0.
COM2 (upper) is the console port for instance 1.
On a pedestal system:
COM1 (left) is the console port for instance 0.
COM2 (right) is the console port for instance 1.
Unlike creating an OpenVMS Galaxy on an AlphaServer 8400, you do not need additional hardware for the second console. COM2 is used for this purpose.
CPU0 must be the primary for instance 0.
CPU1 must be the primary for instance 1.
CPUs 2 and 3 are optional secondary CPUs that can be migrated.
For an example of the CPU environment variable settings on an AlphaServer ES40, see Section 8.5.
On a rack-mounted system:
PCI Hose 0 (PCI0) belongs to instance 0 (upper 4 PCI slots)
PCI Hose 1 (PCI1) belongs to instance 1 (lower 6 PCI slots)
On a pedestal system:
PCI Hose 0 (PCI0) belongs to instance 0 (right-hand slots)
PCI Hose 1 (PCI1) belongs to instance 1 (left-hand slots)
Note that PCI0 contains an embedded ISA controller.
To see an I/O adapter configuration example, refer to Section 8.2.
You will need one storage controller (such as a KZPSA) per instance. For each instance, this can go to a separate StorageWorks box or to the same box for running as a SCSI cluster.
If each instance needs network access, a network card (such as a DE600) is required for each instance.
One card each goes in PCI0 and PCI1.
Memory Granularity Restrictions
Private memory must start on a 64 MB boundary.
Shared memory must start on an 8 MB boundary.
Instance 0 must have a multiple of 64 MB.
8.2 Step 1: Confirm the AlphaServer ES40 Configuration
Use the SHOW CONFIG command to make sure that the AlphaServer ES40 you are using to create an OpenVMS Galaxy environment meets the requirements described in Section 8.1.
At the console prompt, enter the following command:
P00>>>show config |
The console displays information similar to the following example:
Firmware
SRM Console: X5.6-2323
ARC Console: v5.70
PALcode: OpenVMS PALcode V1.61-2, Tru64 UNIX PALcode V1.54-2
Serial Rom: V2.2-F
RMC Rom: V1.0
RMC Flash Rom: T2.0
Processors
CPU 0 Alpha 21264-4 500 MHz 4MB Bcache
CPU 1 Alpha 21264-4 500 MHz 4MB Bcache
CPU 2 Alpha 21264-4 500 MHz 4MB Bcache
CPU 3 Alpha 21264-4 500 MHz 4MB Bcache
Core Logic
Cchip DECchip 21272-CA Rev 9(C4)
Dchip DECchip 21272-DA Rev 2
Pchip 0 DECchip 21272-EA Rev 2
Pchip 1 DECchip 21272-EA Rev 2
TIG Rev 10
Memory
Array Size Base Address Intlv Mode
--------- ---------- ---------------- ----------
0 4096Mb 0000000000000000 2-Way
1 4096Mb 0000000100000000 2-Way
2 1024Mb 0000000200000000 2-Way
3 1024Mb 0000000240000000 2-Way
10240 MB of System Memory
Slot Option Hose 0, Bus 0, PCI
1 DAPCA-FA ATM622 MMF
2 DECchip 21152-AA Bridge to Bus 2, PCI
3 DEC PCI FDDI fwb0.0.0.3.0 00-00-F8-BD-C6-5C
4 DEC PowerStorm
7 Acer Labs M1543C Bridge to Bus 1, ISA
15 Acer Labs M1543C IDE dqa.0.0.15.0
dqb.0.1.15.0
dqa0.0.0.15.0 TOSHIBA CD-ROM XM-6302B
19 Acer Labs M1543C USB
Option Hose 0, Bus 1, ISA
Floppy dva0.0.0.1000.0
Slot Option Hose 0, Bus 2, PCI
0 NCR 53C875 pkd0.7.0.2000.0 SCSI Bus ID 7
1 NCR 53C875 pke0.7.0.2001.0 SCSI Bus ID 7
dke100.1.0.2001.0 RZ1BB-CS
dke200.2.0.2001.0 RZ1BB-CS
dke300.3.0.2001.0 RZ1CB-CS
dke400.4.0.2001.0 RZ1CB-CS
2 DE500-AA Network Con ewa0.0.0.2002.0 00-06-2B-00-0A-58
Slot Option Hose 1, Bus 0, PCI
1 NCR 53C895 pka0.7.0.1.1 SCSI Bus ID 7
dka100.1.0.1.1 RZ2CA-LA
dka300.3.0.1.1 RZ2CA-LA
2 Fore ATM 155/622 Ada
3 DEC PCI FDDI fwa0.0.0.3.1 00-00-F8-45-B2-CE
4 QLogic ISP10x0 pkb0.7.0.4.1 SCSI Bus ID 7
dkb100.1.0.4.1 HSZ50-AX
dkb101.1.0.4.1 HSZ50-AX
dkb200.2.0.4.1 HSZ50-AX
dkb201.2.0.4.1 HSZ50-AX
dkb202.2.0.4.1 HSZ50-AX
5 QLogic ISP10x0 pkc0.7.0.5.1 SCSI Bus ID 7
dkc100.1.0.5.1 RZ1CB-CS
dkc200.2.0.5.1 RZ1CB-CS
dkc300.3.0.5.1 RZ1CB-CS
dkc400.4.0.5.1 RZ1CB-CS
6 DECchip 21154-AA Bridge to Bus 2, PCI
Slot Option Hose 1, Bus 2, PCI
4 DE602-AA eia0.0.0.2004.1 00-08-C7-91-0A-AA
5 DE602-AA eib0.0.0.2005.1 00-08-C7-91-0A-AB
6 DE602-TA eic0.0.0.2006.1 00-08-C7-66-80-9E
7 DE602-TA eid0.0.0.2007.1 00-08-C7-66-80-5E
|
No special installation procedures are required to run OpenVMS Galaxy software. Galaxy functionality is included in the base operating system and can be enabled or disabled using the console command and system parameter values described later in this chapter.
If your AlphaServer ES40 is not part of a SCSI cluster, you must install OpenVMS Version 7.3 on two system disks---one disk for each instance.
If your AlphaServer ES40 is part of a SCSI cluster with a cluster-common system disk, install OpenVMS Version 7.3 on one system disk.
For more information about installing the OpenVMS Alpha operating
system, see the OpenVMS Alpha Version 7.3 Upgrade and Installation
Guide.
8.4 Step 3: Upgrade the Firmware
To upgrade the firmware, use one of the following procedures:
Copy the firmware file to MOM$SYSTEM on a MOP-enabled server that is accessible to the AlphaServer ES40. Enter the following commands on the console:
P00>>> boot -fl 0,0 ewa0 -fi {firmware filename}
UPD> update srm*
<power-cycle system>
|
Or, use the following commands:
P00>>> BOOT -FLAGS 0,A0 cd_device_name
.
.
.
Bootfile: {firmware filename}
.
.
.
|
Configure the primary console for instance 0.
CPU0 is the primary for instance 0. CPU1 is the primary for instance 1.
The following example is for an AlphaServer ES40 with three CPUs and 512 MB of memory divided into 256 MB + 192 MB + 64 MB.
P00>>> set lp_count 2 P00>>> set lp_cpu_mask0 1 P00>>> set lp_cpu_mask1 6 P00>>> set lp_io_mask0 1 P00>>> set lp_io_mask1 2 P00>>> set lp_mem_size0 10000000 P00>>> set lp_mem_size1 c000000 P00>>> set lp_shared_mem_size 4000000 P00>>> set console_memory_allocation new P00>>> set auto_action halt |
If you have four CPUs and you want to assign all secondary CPUs to instance 1, the LP_CPU_MASK1 variable will be E. If you split the CPUs between both instances, CPU 0 must be the primary for instance 0, and CPU 1 must be the primary CPU for instance 1.
The following example shows LP_CPU_MASK values for secondary CPU assignments with primary CPUs.
Assign secondary CPU 2 with primary CPU 0 and secondary CPU 3 with primary CPU 1. >>>set lp_cpu_mask0 5 >>>set lp_cpu_mask1 A CPU Selection LP_CPU_MASK 0(primary partition 0) 2^0 = 1 1(primary partition 1) 2^1 = 2 2(secondary) 2^2 = 4 3(secondary) 2^3 = 8 |
The mem_size variables depend on your configuration and how you want to split it up.
lp_io_mask0 must be set to 1.
lp_io_mask1 must be set to 2.
You must set the console environment variable AUTO_ACTION to HALT. This
will ensure that the system does not boot and that you will be able to
enter the LPINIT command.
8.6 Step 5: Initialize the System and Start the Console Devices
P00>>> init ! initialize the system P00>>> lpinit ! start firmware |
Instance 0
P00>>> set boot_osflags 12,0
P00>>> set bootdef_dev dka0
P00>>> set boot_reset off !!! must be OFF !!!
P00>>> set ewa0_mode twisted
Instance 1
P01>>> set boot_osflags 11,0
P01>>> set bootdef_dev dkb200
P01>>> set boot_reset off !!! must be OFF !!!
P01>>> set ewa0_mode twisted
|
P01>>> boot |
GALAXY=1 |
$ @SYS$UPDATE:AUTOGEN GETDATA SHUTDOWN INITIAL |
P00>>> boot |
GALAXY=1 |
$ @SYS$UPDATE:AUTOGEN GETDATA SHUTDOWN INITIAL |
P00>>> set auto_action restart P01>>> set auto_action restart |
P00>>> init |
Do you REALLY want to reset all partitions? (Y/N) |
Congratulations! You have created an OpenVMS Galaxy on an AlphaServer ES40 system.
This chapter describes how to create an OpenVMS Galaxy computing
environment on AlphaServer GS80/160/320 systems.
9.1 Step 1: Choose a Configuration and Determine Hardware Requirements
OpenVMS Alpha Version 7.3 supports the following maximum configuration on AlphaServer GS160 systems:
4 instances
4 QBBs
16 CPUs
64 GB memory
Rules:
Must have standard COM1 UART console line for each partition
Must have PCI drawer for each partition
Must have an I/O module per partition
Must have at least one CPU module per partition
Must have at least one memory module per partition.
When you have acquired the necessary hardware for your configuration,
follow the procedures in the appropriate hardware manauals to assemble
it.
9.3 Step 3: Create a System Disk
Decide whether to use a system disk per instance or whether to use a cluster common-disk.
A new SECURITY.EXE file is required for all cluster members running a
version prior to OpenVMS Version 7.1-2 that share the same
VMS$OBJECTS.DAT file with Galaxy instances.
9.4 Step 4: Install OpenVMS Alpha Version 7.3
No special installation procedures are required to run OpenVMS Galaxy software. Galaxy functionality is included in the base operating system and can be enabled or disabled using the console command and system parameter values described later in this chapter.
For more information about installing the OpenVMS Alpha operating
system, see the OpenVMS Alpha Version 7.3 Upgrade and Installation Manual.
9.4.1 OpenVMS Galaxy Licensing Information
In a Galaxy environment, the OPENVMS-GALAXY license units are checked during system startup and whenever a CPU reassignment between instances occurs.
If you attempt to start a CPU and there are insufficient OPENVMS-GALAXY
license units to support it, the CPU will remain in the instance's
configured set but it will be stopped. You can subsequently load the
appropriate license units and start the stopped CPU while the system is
running. This is true of one or more CPUs.
9.5 Step 5: Set Environment Variables
When you have installed the operating system, you can set the
Galaxy-specific environment variables as shown in the examples in this
section.
9.5.1 AlphaServer GS160 Example
This example for an AlphaServer GS160 assumes you are configuring an
OpenVMS Galaxy computing environment with:
4 instances
4 QBBs
16 CPUs
32 GB of memory
P00>>>show lp* lp_count 4 lp_cpu_mask0 000F lp_cpu_mask1 00F0 lp_cpu_mask2 0F00 lp_cpu_mask3 F000 lp_cpu_mask4 0 lp_cpu_mask5 0 lp_cpu_mask6 0 lp_cpu_mask7 0 lp_error_target 0 lp_io_mask0 1 lp_io_mask1 2 lp_io_mask2 4 lp_io_mask3 8 lp_io_mask4 0 lp_io_mask5 0 lp_io_mask6 0 lp_io_mask7 0 lp_mem_size0 0=4gb lp_mem_size1 1=4gb lp_mem_size2 2=4gb lp_mem_size3 3=4gb lp_mem_size4 0 lp_mem_size5 0 lp_mem_size6 0 lp_mem_size7 0 lp_shared_mem_size 16gb P00>>>lpinit |
This example for an AlphaServer GS320 system assumes you are configuring an OpenVMS Galaxy computing environment with:
4 instances
8 QBBs
32 CPUs
32 GB memory
P00>>>show lp* lp_count 4 lp_cpu_mask0 000F000F lp_cpu_mask1 00F000F0 lp_cpu_mask2 0F000F00 lp_cpu_mask3 F000F000 lp_cpu_mask4 0 lp_cpu_mask5 0 lp_cpu_mask6 0 lp_cpu_mask7 0 lp_error_target 0 lp_io_mask0 11 lp_io_mask1 22 lp_io_mask2 44 lp_io_mask3 88 lp_io_mask4 0 lp_io_mask5 0 lp_io_mask6 0 lp_io_mask7 0 lp_mem_size0 0=2gb, 4=2gb lp_mem_size1 1=2gb, 5=2gb lp_mem_size2 2=2gb, 6=2gb lp_mem_size3 3=2gb, 7=2gb lp_mem_size4 0 lp_mem_size5 0 lp_mem_size6 0 lp_mem_size7 0 lp_shared_mem_size 16gb P00>>>lpinit |
This section describes each environment variable. For more details about using these variables, refer to the AlphaServer GS80/160/320 Firmware Reference Manual.
If set to zero, the system will boot a traditional SMP configuration only. Galaxy console mode is OFF.
If set to a nonzero value, the Galaxy features will be used, and the Galaxy variables will be interpreted. The exact value of LP_COUNT represents the number of Galaxy partitions the console creates.
Note that if you assign resources for three partitions and set LP_COUNT to two, the remaining resources will be left unassigned.
This bitmask determines which CPUs are to be initially assigned to the specified Galaxy partition number. The AlphaServer GS160 console chooses the first CPU that passes the self test in a partition as its primary CPU.
The new Alphaserver GS series introduces a new Galaxy environment variable called LP_ERROR_TARGET. The value of the variable is the number of the Galaxy instance that system errors will initially be reported to. Unlike other Galaxy platforms, all system correctable, uncorrectable and system event errors will go to a single instance. It is possible for the operating system to change this target, so the value of the variable represents the target when the system is first partitioned.
Every effort is made to isolate system errors to a single instance so that the error does not bring down the entire Galaxy. The error target instance will determine, on receipt of an error, if it is safe to remotely crash the single instance that incurred the error. A bugcheck code of GLXRMTMCHK is used in this case. Note that error log information pertaining to the error will be on the error target instance, not necessarily on the instance that incurred the error.
While every effort is made to keep the error target instance identical to the one the user designated with the environment variable, the software monitors the instances and will change the error target if necessary.
These variables assign the I/O modules by QBB number to each instance:
| Mask Value | QBB Number |
|---|---|
| 1 | QBB 0 |
| 2 | QBB 1 |
| 4 | QBB 2 |
| 8 | QBB 3 |
For the n, supply the partition number (0 - 7). The value mask gives a binary mask indicating which QBB's (containing I/O risers) are included in the partition.
These variables allocate a specific amount of private memory for the specified instance. It is imperative that you create these variables using proper values for the amount of memory in your system and the desired assignments for each instance.
You can define only the amount of shared memory to use, and leave the other LP_MEM_SIZE variables undefined. This will cause the console to allocate the shared memory from the high address space, and split the remaining memory equally among the number of partitions specified by the LP_COUNT variable. If you also explicitly assign memory to a specific partition using a LP_MEM_SIZE variable, but leave other partition memory assignments undefined, the console will again assign the memory fragments for shared memory and any partitions with explicit assignments, then split and assign the remaining memory to any remaining partitions not having explicit memory assignments.
For example:
lp_mem_size0 0=2gb, 1=2gb |
Do not assign private memory to an instance from a QBB that has no CPUs in the instance. For example, if LP_CPU_MASK0 is FF, then you should only assign private memory for instance 0 from QBBs 0 and 1. |
Refer to see AlphaServer GS80/160/320 Firmware Reference Manual for more details about using this variable.
This variable allocates memory for use as shared memory. For example:
lp_shared_mem_size 16gb |
Note that shared memory must be assigned in multiples of 8 MB.
Refer to the AlphaServer GS80/160/320 Firmware Reference Manual for more details about using this variable.
BOOTDEF_DEV and BOOT_OSFLAGS variables
You should set these variables on each of your Galaxy consoles prior to booting to ensure that AUTOGEN reboots correctly when it needs to reboot the system after an initial installation and after a system failure or operator-requested reboot.
| Previous | Next | Contents | Index |