|
HP OpenVMS Systems Documentation |
|
OpenVMS Alpha Partitioning and Galaxy Guide
5.8 Step 8: Boot the OpenVMS GalaxyWhen you have correctly installed the Galaxy firmware and configured the consoles, you can boot the initial Galaxy environment as follows: For each Galaxy instance:
Congratulations! You have created an OpenVMS Galaxy.
Chapter 6
|
P08>>> SET ARC_ENABLE ON P08>>> INITIALIZE P08>>> RUNECU |
There are two versions of the ECU, one that runs on a graphics terminal and another that runs on character-cell terminals. Both versions are on the diskette, and the console determines which one to run. For OpenVMS Galaxy systems, the primary console will always be a serial device with a character cell terminal.
If the ECU is not run, OpenVMS will display the following message:
%SYSTEM-I-NOCONFIGDATA, IRQ Configuration data for EISA
slot xxx was not found, please run the ECU and reboot.
|
If you ignore this message, the system will boot, but the plug-in EISA devices will be ignored.
Once you have configured and set up the OpenVMS Galaxy hardware as
described in the previous sections, perform the following steps to
install and boot OpenVMS Galaxy instances.
6.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 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.
6.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.2 Upgrade and Installation Manual.
6.4.1 OpenVMS Galaxy Licensing Information
See the OpenVMS License Management Utility Manual.
6.5 Step 5: Upgrade the Firmware
Creating an OpenVMS Galaxy environment on an AlphaServer 8200 requires a firmware upgrade to each processor module. If you use these modules again in a non-Galaxy configuration, you will need to reinstall the previous firmware. It is a good practice to have a current firmware CD on hand.
It saves some time if you install all processor modules you intend to use and update them at the same time. The AlphaServer 8200 requires that you use the same firmware on all processor boards. If you need to upgrade a board at a later time, you must:
To upgrade your firmware, the system must be powered on, running in non-Galaxy mode (that is, the LP_COUNT console environment variable---if you have established it---must be set to zero).
To set the console environment variable, use the following commands:
P08>>> SET LP_COUNT 0 P08>>> INIT |
To upgrade the firmware, use the standard console firmware update
available from AlphaServers Engineering.
6.6 Step 6: Set Environment Variables
When you have upgraded the firmware on all of your processor modules, you can create the Galaxy-specific environment variables as shown in the following example. This example assumes you are configuring a 2-instance, 4 CPU, 1 GB OpenVMS Galaxy computing environment.
P08>>> create -nv lp_count 2 P08>>> create -nv lp_cpu_mask0 100 P08>>> create -nv lp_cpu_mask1 e00 P08>>> create -nv lp_io_mask0 100 P08>>> create -nv lp_io_mask1 80 P08>>> create -nv lp_mem_size0 10000000 P08>>> create -nv lp_mem_size1 10000000 P08>>> create -nv lp_shared_mem_size 20000000 P08>>> init |
Once these variables have been created, you can use console SET commands to manipulate them. These variables need only be created on processor 0.
The following descriptions give detailed information about each environment variable.
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 should expect.
This bit-mask determines which CPUs are to be initially assigned to the specified Galaxy partition number. The AlphaServer 8200 console chooses the first even-numbered CPU as its primary CPU, beginning with CPU 08 for the initial instance. Keep this in mind when assigning the resources. (In other words, do not assign only an odd-numbered CPU to a partition.)
These variables assign IO processors by slot number to each instance:
These are the only valid assignments for the AlphaServer 8200.
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. Refer to Table B-1 for common values.
See also the shared memory variable on the following line.
This variable allocates memory for use as shared memory. Refer to Appendix B for common values.
Shared memory must be assigned in multiples of 8 MB and all values are expressed in hexadecimal bytes. 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 to 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 the 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. |
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 crash or operator requested reboot.
Galaxy Environment Variables Example
P08>>> SHOW LP* lp_count 2 lp_shared_mem_size 20000000 (512 MB) lp_mem_size0 10000000 (256 MB) lp_mem_size1 10000000 (256 MB) lp_cpu_mask0 100 (CPU 0) lp_cpu_mask1 e00 (CPUs 1-3) lp_io_mask0 100 (I/O module in slot 8) lp_io_mask1 80 (I/O module in slot 7) P08>>> |
If the KFE72-DA was ever configured for Windows NT, it probably expects to find the video board and will hang if one is not present. This is a common occurrence when configuring an OpenVMS Galaxy. A console command can be used to set the mode of operation as follows:
P08>>> SET CONSOLE SERIAL |
When you issue this command to the primary console prior to initializing the secondary console, the setting will be propagated to the secondary console hardware.
If you decide to use the Ethernet port, you may need to inform the console of which media type and connection you intend to use: AUI, UDP, or Twisted-Pair. The console and operating system will determine which to use, but you can assign a specific media type using the following commands:
P08>>> SHOW NETWORK P08>>> SET EWA0_MODE TWISTED |
The first command displays a list of available network devices. The second command establishes the default media type for the specified device (EWA0 in this example). This should be done for all Ethernet devices prior to initializing the secondary console.
Once you have set your console mode and network media types (if used) you should reinitialize the system to ensure that the current settings are saved. If you have already defined your Galaxy partitions, you can initialize now. If you have not defined your Galaxy partitions, you should defer initialization until later.
If you are ready to initialize the system, enter:
P08>>> INIT |
You should see the primary console respond with its usual power-up self-test (POST) report. This could take up to 2 minutes. If you have properly defined the Galaxy partitions, only the I/O devices associated with the primary partition will be visible.
To verify that partitioning has occurred, enter:
P08>>> SHOW DEVICE or P08>>> SHOW NETWORK |
To initialize the secondary console, enter:
P08>>> LPINIT |
The console displays the following:
Partition 0: Primary CPU = 0 Partition 1: Primary CPU = 2 Partition 0: Memory Base = 000000000 Size = 010000000 Partition 1: Memory Base = 010000000 Size = 010000000 Shared Memory Base = 020000000 Size = 010000000 LP Configuration Tree = 12c000 starting cpu 1 in Partition 1 at address 01000c001 starting cpu 2 in Partition 1 at address 01000c001 starting cpu 3 in Partition 1 at address 01000c001 P08>>> |
This command must be entered from the primary Galaxy console. If the Galaxy partitions have been properly defined, and hardware resources have been properly configured, you should see the primary console start the processors assigned to the secondary partition. The secondary console should initialize within about 2 minutes.
If one or more consoles fails to initialize, you should double-check your hardware installation, Galaxy partition definitions, and hardware assignments.
For more information about OpenVMS console restrictions and hints, see
Chapter 11.
6.8 Step 8: Boot the OpenVMS Galaxy
When you have correctly installed the Galaxy firmware and configured the consoles, you can boot the initial Galaxy environment as follows:
For each Galaxy instance:
P08>>> B -FL 0,1 DKA100 // or whatever your boot device is. SYSBOOT> SET GALAXY 1 SYSBOOT> CONTINUE |
Congratulations! You have created an OpenVMS Galaxy.
This chapter describes the requirements and procedures for creating an
OpenVMS Galaxy computing environment on an AlphaServer 4100.
7.1 Before You Start
To create an OpenVMS Galaxy on an AlphaServer 4100, you must also be familiar with the following configuration and hardware requirements:
You can run a maximum of two instances of OpenVMS on an AlphaServer 4100.
You must have AlphaServer 4100 console firmware that is available in the OpenVMS Version 7.3 CD-ROM.
In addition to the console hints in Chapter 5, you should be aware of the following:
An AlphaServer 4100 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.
COM1 (upper) is the console port for instance 0.
COM2 (lower) 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.
The four lower PCI slots belong to IOD0, which is the I/O adapter for
instance 0.
The four upper PCI slots belong to IOD1, which is the I/O adapter for
instance 1.
You will need two storage controllers, such as KZPSAs. These can go to separate Storageworks boxes or to the same box for running as a SCSI cluster. One controller each goes in IOD0 and IOD1.
If each instance needs network access, a network card (such as a DE500) is required for each instance.
One card each goes in IOD0 and IOD1.
Because OpenVMS Galaxy on an AlphaServer 4100 does not support memory holes, physical memory for an OpenVMS Galaxy environment must be contiguous. To achieve this on an AlphaServer 4100, one of the following must be true:
To create an OpenVMS Galaxy on an AlphaServer 4100 system, perform the
steps in the following sections.
7.2 Step 1: Confirm the AlphaServer 4100 Configuration
Use the SHOW CONFIG command to make sure that the AlphaServer 4100 you are using to create an OpenVMS Galaxy environment meets the requirements described in Section 7.1.
At the console prompt, enter the following command:
P00>>>show config |
The console displays the following information:
Console G53_75 OpenVMS PALcode V1.19-16, Compaq UNIX PALcode V1.21-24 Module Type Rev Name System Motherboard 0 0000 mthrbrd0 Memory 512 MB EDO 0 0000 mem0 Memory 256 MB EDO 0 0000 mem1 CPU (Uncached) 0 0000 cpu0 CPU (Uncached) 0 0000 cpu1 Bridge (IOD0/IOD1) 600 0021 iod0/iod1 PCI Motherboard 8 0000 saddle0 CPU (Uncached) 0 0000 cpu2 CPU (Uncached) 0 0001 cpu3 Bus 0 iod0 (PCI0) Slot Option Name Type Rev Name 1 PCEB 4828086 0005 pceb0 4 DEC KZPSA 81011 0000 pks1 5 DECchip 21040-AA 21011 0023 tulip1 Bus 1 pceb0 (EISA Bridge connected to iod0, slot 1) Slot Option Name Type Rev Name Bus 0 iod1 (PCI1) Slot Option Name Type Rev Name 1 NCR 53C810 11000 0002 ncr0 2 DECchip 21040-AA 21011 0024 tulip0 3 DEC KZPSA 81011 0000 pks0 |
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 4100 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 4100 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.
7.4 Step 3: Upgrade the Firmware
To upgrade the firmware, use the Alpha Systems Firmware Update Version
5.4 CD-ROM that is included in the OpenVMS Version 7.3
CD-ROM package. Be sure to read the release notes that
are included in the package before installing the firmware.
7.5 Step 4: Set Environment Variables
Configure the primary console for instance 0.
CPU0 is the primary for instance 0.
Create the Galaxy environment variables. For descriptions of the Galaxy environment variables and common values for them, refer to Chapter 5.
The following example is for an AlphaServer 4100 with three CPUs and 512 MB of memory divided into 256 MB + 192 MB + 64 MB.
P00>>> create -nv lp_count 2 P00>>> create -nv lp_cpu_mask0 1 P00>>> create -nv lp_cpu_mask1 6 P00>>> create -nv lp_io_mask0 10 P00>>> create -nv lp_io_mask1 20 P00>>> create -nv lp_mem_size0 10000000 P00>>> create -nv lp_mem_size1 c000000 P00>>> create -nv lp_shared_mem_size 4000000 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 MEM_SIZE variables depend on your configuration and how you want to split it up.
galaxy_io_mask0 must be set to 10.
galaxy_io_mask1 must be set to 20.
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 Galaxy command.
7.6 Step 5: Initialize the System and Start the Console Devices
P00>>> init P00>>> galaxy |
CPU0 would not join |
IOD0 and IOD1 did not pass the power-up self-test |
P01>>> create -nv lp_cpu_mask0 1 P01>>> create -nv lp_cpu_mask1 6 P01>>> create -nv lp_io_mask0 10 P01>>> create -nv lp_io_mask1 20 P01>>> create -nv lp_mem_size0 10000000 P01>>> create -nv lp_mem_size1 c000000 P01>>> create -nv lp_count 2 P01>>> create -nv lp_shared_mem_size 4000000 P01>>> set auto_action halt |
P00>>> init |
Do you REALLY want to reset the Galaxy (Y/N) |
P00>>> set boot_osflags 12,0 P00>>> set bootdef_dev dka0 P00>>> set boot_reset off !!! must be OFF !!! P00>>> set ewa0_mode twisted 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 |
Add the line 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 the Galaxy (Y/N) |
Congratulations! You have created an OpenVMS Galaxy.
| Previous | Next | Contents | Index |