This chapter describes the interaction and functions of system controllers in the following sections:
The control system for the SGI Altix 3700 Bx2 series servers manages power control and sequencing, provides environmental control and monitoring, initiates system resets, stores identification and configuration information, and provides console/diagnostic and scan interface.
Figure 2-1 shows an example system control network using an optional SGIconsole and separate (remote) workstation to monitor a single-rack Altix 3700 Bx2 system.
The system control network configuration of your server will depend on the size of the system and control options selected. The Altix 3700 Bx2 server has optional levels of control, as follows:
L1: brick and system-level control. The L1 system controller is designed into all CR and NUMA4 R-bricks. There is no interconnected L1 function in the TP900 storage module or the D–brick2. Note that the IX-brick is compatible with the new system control functions, but is interconnected to a CR-brick via an SGI Xtown2 interface using RS-422 signals.
Optional SGIconsole. The L1 controllers in the system report and share status information via the NUMAlink-4 cables, thus maintaining controller configuration and topology information between all controllers and the system console. For additional information on the SGIconsole options, see:
SGIconsole Hardware Connectivity Guide, (P/N 007-4340-00x)
SGIconsole 2.x Start Here, (P/N 007-4356-00x)
Console Manager for SGIconsole Administrator's Guide, (P/N 007-4477-00x)
Note: The D–brick2, which is not monitored by the L1 controller network, has its own ESI/ops panel module with a microcontroller for monitoring and controlling all elements of the D–brick2.
In all Altix 3700 Bx2 servers all the L1 controllers communicate with each other in the following ways:
All CR and NUMAlink-4 R-bricks communicate with each other through the NUMAlink connections using low voltage differential signaling (LVDS).
An L1 controller of an I/O brick communicates with an L1 controller of a CR-brick via the Crosstown2 connections using serial (RS-422) signals.
If a USB-to-Ethernet adapter is connected to either the CR or NUMAlink-4 R-brick, the L1 system controller on that brick emulates an L2 controller. Access to the L2 functionality is made by way of an Ethernet connection.
Figure 2-2 diagrams the paths for an example console interaction between the system L1s and a remote Ethernet based console interface.
All bricks except TP900 storage modules and D–brick2 storage modules have L1 controllers. The following subsections describe the basic features of all L1 controllers:
-
Note: For additional information on L1 controller commands, see the SGI L1 and L2 Controller Software User's Guide (007-3938-xxx).
Table 2-1 summarizes the control and monitoring functions that the L1 controller performs. Many of the L1 controller functions are common across all brick types; however, some functions are applicable to a specific brick type.
Table 2-1. L1 Controller Functions
Function | CR–brick | R–brick | IX-brick | PX-brick |
|---|---|---|---|---|
Controls voltage regulator modules (VRMs). | X | X | X | X |
Controls voltage margining within the brick. | X | X | X | X |
Controls and monitors fan speed. | X | X | X | X |
Monitors voltage and reports failures. | X | X | X | X |
Monitors and reports operating temperature and status of 48-VDC input power. | X | X | X | X |
Monitors and controls LEDs. | X | X | X | X |
Reads system identification (ID) PROMs. | X | X | X | X |
Monitors the On/Off power switch. | X | X | X | X |
Monitors the reset switch and the nonmaskable interrupt (NMI) switch. | X |
|
|
|
Reports the population of the PCI cards and the power levels of the PCI slots. |
|
| X | X |
Powers on the PCI slots and their associated LEDs. |
|
| X | X |
Figure 2-3 shows the L1 controller front panel on the CR-brick.
The front panel display contains the following items:
2 x 12 character liquid crystal display (LCD). The display identifies the brick, shows system status, warns of required service, and identifies a failed component.
Power (On/Off) switch with LED (button with light-emitting diode [LED]).
Service required LED.
Failure LED.
Reset switch and non-maskable interrupt (NMI) switch.
Note: The reset and NMI switch functions are available on the CR-brick only.
Use of an Ethernet switch is the preferred method of connecting remote support hardware to multiple systems.
The optional Ethernet switch provides eight Ethernet connectors. Figure 2-4 shows sample connections between the Ethernet switch, an SGIconsole a CR-brick, and other local SGI systems.
The console type and how these console types are connected to the Altix 3700 Bx2 servers is determined by what console option is chosen.
If you have an Altix 3700 Bx2 server with a dumb terminal, you can connect the terminal via a serial cable to the (DB-9) console port connector on the rear of the CR-brick.
The terminal must be set to the following functional modes:
Baud rate of 38,400
8 data bits
One stop bit, no parity
Hardware flow control (RTS/CTS)
You can also connect a USB-to-Ethernet adapter to the CR-brick or R-brick and place it on a network. This starts an L2-level emulator on the brick's system controller. Use the telnet command to connect to the CR-brick or R-brick.
Table 2-2 provides information on connection points for the USB-to-Ethernet adapter depending on the system size.
Table 2-2. Location Guidelines for Connecting USB/Ethernet Adapters
System Size | Rack Number | Brick Type | Slot Number (U-Location) |
|---|---|---|---|
64 Processor or smaller | 001 | CR | Bottom CR-brick in rack |
128 Processor | 001 | R-brick | U-23 |
256 Processor | 002 003 | R-brick R-brick | U-17 U-23 |
512 Processor
| 003 003 009 009 | R-brick R-brick R-brick R-brick | U-05 U-35 U-05 U-35 |
By default the L2 emulator uses DHCP to obtain an IP address. To set a state IP, access the L1 via the serial port and use the following commands:
001c05-L1> L2 ip <ip address> <netmask> <broadcast>
001c05-L2> reboot_L1
These console connections enable you to view the status and error messages generated by the L1 controllers on your system. You can also use the console to input commands to manage and monitor your system(s). For more information on the L2 emulator, see “L2 Emulator Operation”.
When the system is connected to a network, an optional SGIconsole can also be used to access the system and manage functional processes. For additional information on the SGIconsole options, see:
SGIconsole Hardware Connectivity Guide, (P/N 007-4340-00x)
SGIconsole 2.x Start Here, (P/N 007-4356-00x)
Console Manager for SGIconsole Administrator's Guide, (P/N 007-4477-00x)
For more details on connecting a console to an Altix 3700 Bx2 series server, see “Connecting a System Console” in Chapter 1. For more information on monitoring your server, see “Monitoring Your Server” in Chapter 1.
Each CR-brick, and NUMAlink-4 R-brick in the Altix 3700 Bx2 system has an updated and enhanced system control implementation. Note that L1 mode operation is for systems without NUMAlink-4 routers (R-bricks) and when using a serial console connection to one of the CR-bricks.
An L2 emulator mode is used with the system when NUMAlink-4 routers are used and a USB-to-Ethernet adapter is connected. See “L2 Emulator Operation” for more information.
Need for a separate optional hardware L2 system controller has been eliminated from the system control network.
The L1 operates in one of these two modes, which are discussed in the sections that follow:
| L1 Mode |
|
The L1 prompt is visible and all input is directed to the L1 command processor. The enhanced L1 control system is compatible with the L1 controller in the IX-bricks. The Altix 3700 Bx2 server L1 system control can perform the following:
Managing power and sequencing control
Environmental monitoring and control functions
Initiation of system resets
Read/write storage for identification and configuration information
Provides console/diagnostic and scan interface
The L1 controller in each of the CR or NUMA-4 R-bricks is a complete and fully functional system controller. All the bricks are interconnected by NUMAlink-4 connectors and each brick shares its system control information with the others.
| Console Mode from L1 |
| |
| Output from the system is visible and all input is directed to the system console. |
| Note: The “console mode from L1” mode is supported only if the system console is connected directly to the console port of the CR-brick. |
If you see a prompt of the following form, the L1 is ready to accept commands.
001c19-L1> |
Common operations are discussed in the following sections:
An L1 has limited knowledge of the system topology, depending on the system's configuration. In configurations without an R-brick, each CR-brick has information about other CR-bricks within the system and its attached I/O brick (if any). An I/O brick only has information about its attached CR-brick.
In some configurations with R-bricks (routers) the L1 will only have knowledge of a portion of the bricks in the system. These R-brick configurations require the use of the emulated L2 (via the use of a USB to ethernet adapter), see “L2 Emulator Operation” for further details.
You can view a brick's configuration information with the config command as in the following:
001c07-L1> config :0 001c07 LOC :1 001i11 U-F :2 001p15 U-G 001c05-L1 |
This example is a system with one CR-brick and two I/O-bricks. The <number> that follows the colon (0, 1, and 2, from top to bottom in this example), refers to which local port (NUMAlink or Crosstown) the brick is connected to or accessed through. The local (LOC) brick is the brick that is processing the command.
On all bricks :0 is the local brick, with other values referring to various ports. The specific port description follows the brick's rack/type/slot field: (i.e. LOC, U-F, U-G, etc.)
All commands entered affect only the local brick. You can target a command to all bricks (including the local brick) by prefixing the command with an asterisk (*).
001c05-L1> * version 001c05: L1 0.7.37 (Image A), Built 11/24/2004 14:59:42 [2MB image] 004i01: L1 0.7.37 (Image A), Built 11/24/2004 14:59:42 [2MB image] 002c01: L1 0.7.37 (Image A), Built 11/24/2004 14:59:42 [2MB image] 001x01: L1 0.7.37 (Image A), Built 11/24/2004 14:59:42 [2MB image] 001c05-L1> |
All information, warnings, and error messages generated by any of the system controllers are in the following form:
001c05 ERROR: invalid arguments for `ver' command, try “help ver” |
The general format of the message includes a brick identification (this is not present if the command was to the local brick only), type of message, and the message. These messages can be the result of an invalid command (as shown in the example) or from tasks running on the L1, such as the environmental monitor.
Each L1 has a log of local events. Use the L1 command log to view the event on any of the L1s.
Use a serial terminal cable connected to the console port on any one of the CR bricks. From this perspective all functioning bricks with an L1 can be seen in the output of the L1 config command.
001c07-L1> config
:0 001c07 LOC :1 001c11 U-F :2 001c15 U-G :3 001c33 U-H :10 101i35 IIB |
To power up/down/reset a non-router configuration from the L1, commands must be targeted to all bricks:
001c05-L1> * power up 001c05-L1> * power down 001c05-L1> * reset |
You can power on and power off a specific brick with the power command:
001c05-L1> power up 001c05-L1> |
This will power on or power off only the locally attached brick. You can target other specific bricks for the power on or power off commands by preceding the power up/down command with a specific rack, and slot destination, such as:
001c05-L1> rack 1 slot 11 power up 001c05-L1> |
or
001c05-L1> r 1 s 11 power up 001c05-L1> |
This command requires from several seconds to several minutes to complete. Remember that TP900 and D-brick2 options will always have to be manually powered on or off.
In console mode, output from the system is visible and all input is directed to the system. To enter console mode, press Ctrl+D at the L1 prompt:
001c05-L1> Ctrl+D entering console mode 001c05 console, <CTRL-T> to escape to L1 . <system output appears here> . |
To return to L1 mode, press Ctrl+T:
Ctrl+T escaping to L1 system controller 001c05-L1> |
While in L1 mode, you can enter any L1 command. Once the command is executed, the L1 returns to console mode:
re-entering console mode 001c05 console, <CTRL-T> to escape to L1 |
To permanently engage the L1 mode, press Ctrl+T and then enter the l1 command:
Ctrl+T escaping to L1 system controller 001c05-L1> l1 L1 command processor engaged, <CTRL-D> for console mode. 001c05-L1> |
The brick with which the L1 communicates in console mode is the system console or global master, and you can view and set it with the select command. By default, the CR-brick attempts to communicate with its local CPUs when console mode is entered. If the system has been powered on and either one of the bricks received a request to be the system console, then the CR-brick attempts to communicate with that brick. The select command by itself shows the current console mode settings:
001c05-L1> select console input: 001c05 console0 console output: not filtered. |
The following are common subchannels associated with console communications:
Subchannel 0A specifies Node 0, CPU A.
Subchannel 0C specifies Node 0 CPU B.
Subchannel 1A specifies Node 1, CPU A.
Subchannel 1C specifies Node 1, CPU B.
Subchannel 2A specifies Node 2, CPU A.
Subchannel 2C specifies Node 2, CPU B.
Subchannel 3A specifies Node 3, CPU A.
Subchannel 3C specifies Node 3, CPU B.
Node 0 console subchannel.
Node 1 console subchannel.
The output console input: 001c05 console0 shows that the system interface console will send input to brick 001c05 and the subchannel to be used is the console0 subchannel.
To change system console status from one brick to the attached CR-brick, use the select <rack> <slot> command:
001c05-L1> select r 2 s 1 console input: 001c05 console console output: not filtered. 001c05-L1> To change the subchannel used on the selected brick, use the select command followed by the subchannel number or the word console: 001c05-L1> select sub 0A console input: 001c05 CPU 0A console output: not filtered. 001c05-L1> |
During the boot process on a multi-rack system, there is a window of time in which both CR-bricks are producing output. This output can produce a somewhat jumbled output at the L1. However, you can filter the console output so that the L1 shows output from only the brick chosen to receive console input. You can turn filtering on and off with the select filter command.
If you attempt to communicate with a brick that is not responding, a time-out condition results:
001c05-L1> entering console mode 001c05 console, <CTRL-T> to escape to L1 no response from 001c05 junk bus console UART:UART_TIMEOUT |
When this time-out condition occurs, either the brick is hung or the subchannel is incorrect. A brick is identified by its rack, type, and slot (001c05). The structure of the brick location is as follows:
rrrbss.p
where:
| rrr | is the rack number. | |
| b | is the brick type. | |
| ss | is the slot location of the brick. | |
| p | is the partition of the brick (not present if the system is not partitioned). R-bricks are not associated with a partition. |
In the example shown above, 001c05 is a CR-brick in rack 001 and slot position 05.
All information, warnings, and error messages generated by any of the system controllers are in the following form:
001c05 ERROR: invalid arguments for `ver' command, try “help ver” |
The general format includes a brick identification and the type of message, followed by the message. A message may be the result of an invalid command, as shown in the example, or the result of tasks running on the L1, such as the environmental monitor.
Each L1 has a log of local events. Use the L1 command log to view events on any of the L1s.
As mentioned in “System Controller Interaction” level one system controllers in an Altix 3700 Bx2 system can operate in “L2 emulator mode”. This is to say that they essentially perform the same functions as the L2 system controller on the Altix 3000.
A USB Ethernet adapter can be plugged into the type A connector on the CR-brick. Plugging this adapter causes the system controller to start running as an L2 emulator. The adapter can then be connected to a local area network (LAN) giving network access to the system controller through the emulated L2 interface.
This section refers to setting the IP address on the R-brick, but this is also the procedure to set the IP address on the CR-brick when using a USB/ethernet adapter in non-R-brick configurations.
Setting the IP address of the L2 emulator on the target bricks should be done before connecting the bricks to the network as follows:
Connect a serial cable to the console port on the target NUMAlink-4 R-brick and get the L1 prompt.
At the L1 prompt type:
L1> l2 |
To see if the l2 is running (it will be if the USB/Ethernet adapter is plugged in, even if the adapter is not connected to the network).
If the L2 emulator is not running type:
L1>! init 4 |
This switches the system controller to run level 4 and forces the L2 emulator to be started whether or not the USB/ethernet adapter is plugged in. There is a space between the “!” and "init"
Verify the L2 emulator is running again as above.
To set the IP address on the L2 emulator type:
L1> l2 ip a.b.c.d 255.255.255.0 a.b.c.255 |
Verifying that the system serial number is set on the L2:
L1> l2 serial |
To set the L2 emulator system serial number:
L1> l2 serial set <serial number> |
Verifying that msys is enabled (this allows multiple L2s in a system to exist peacefully with other L2s from another system on the same subnet)
L1> l2 msys |
If msys is off, turn it on:
L1> l2 msys on |
Reboot the system controller to make the IP address change take effect.
L1> reboot_l1 |
Once this is done for all target R-bricks, connect them to the network (using an optional Ethernet switch if necessary).
The rackid on the L2 emulator cannot be set with the L2 "rackid" command, instead it will be inherited from the local L1. As an example: the L2 emulator running on the system controller in 1r14 will have a rack id of 114 (rack * 100 + slot of the local L1).
Once the L2 emulator is running, you can telnet to the L2 emulator, or use an optional SGIConsole. Functionally it is the same as the separate hardware L2 (box) used with older Altix 3000 systems.
| Note: The L2 touch displays (used with some older Altix 3000 systems) are not used or supported with the L2 emulator. |
After the connection to the L2 emulation controller is established, the following prompt appears, indicating that the L2 emulator is ready to accept commands:
L2> |
Common operations are discussed in the subsections that follow.
You can use the L2 emulator's config command to view the current system configuration from a brick level:
L2> config L2 127.0.0.1: - 001 (LOCAL) L1 127.0.0.1:0:0 - 001c18 L1 127.0.0.1:1:0 - 001r16 L1 127.0.0.1:2:0 - 001r14 L1 127.0.0.1:3:0 - 001c11 L1 127.0.0.1:4:0 - 001c08 L1 127.0.0.1:5:0 - 001c05 L1 127.0.0.1:5:1 - 001i01 L2> |
As shown above, config produces a list of bricks and their locations in the system and the system controller address of each brick. This is similar to the output from using the config command on the L1 with the addition of the emulated L2 IP address and USB port number.
The structure of the brick's address is as follows:
a.b.c.d:x:y |
where:
| a.b.c.d | is the IP address of the emulated L2. (In the example above, the IP address is 127.0.0.1.) | |
| x | is the USB port number. (In the example above, the port number is 0.) | |
| y | is the L1 index, as follows: 0 is the local brick (the brick to which the USB cable is attached). A number greater than 0 indicates that it is attached directly to or indirectly to the local brick. A brick is identified by its rack, type, and slot (001c05). The structure of the brick location is as follows: |
rrrbss.p
where:
| rrr | is the rack number. | |
| b | is the brick type. | |
| ss | is the slot location of the brick. | |
| p | is the partition of the brick (not present if the system is not partitioned). R-bricks are not associated with a partition. |
In the example shown above, 001c05 is a CR-brick in rack 001 and slot position 05.
If a command is not understood by the L2 emulator system controller, in general it is passed to the L1 system controllers. The destination determines which L1s receive the command. A destination, specified by the following, is a range of racks and slots:
rack <rack list> slot <slot list> |
The <rack list> specifies a list of racks. This can be a list delimited by commas, such that 2,4,7 specifies racks 2, 4, and 7. You can use a dash to specify a range of racks, such that 2-4 specifies racks 2, 3, and 4. Both nomenclatures can be combined, such that 2-4,7 specifies racks 2, 3, 4, and 7.
You can specify the <slot list> using the same nomenclature. The slot number, sometimes referred to as a bay number, is the unit position number located on the rack, slightly above where the bottom of the brick sits. Each rack unit position number is located toward the top of the two lines that mark the unit position that the number represents. For example, the rack numbering for a brick located in slot 10 would appear on the left front side of the rack.
The slot <slot list> is optional; if not given, then all slots in the specified rack(s) are implied. You should avoid specifying a rack list and a slot list that includes multiple racks and slots, such as rack 2-4,7 slot 1-8,11,13. Generally, you specify a rack and slot together to specify an individual brick.
You can use the aliases r and s to specify rack and slot, respectively. You can use the alias all or * in both the <rack list> and the <slot list>, or by themselves, to specify all racks and all slots.
To send a command to all bricks in a partition, enter the following:
partition <partition> <cmd> |
Default Destination
When the L2 emulator starts, the default destination is set to all racks and all slots. You can determine the default destination by using the destination command:
L2> destination all racks, all slots L2> |
The following command sets the destinations to rack 2 and 3, all slots:
L2> r 2,3 destination 2 default destination(s) set L2> |
The following example shows what bricks are found in the default destination. If you enter a command not understood by the L2 emulator, the command is sent to these bricks.
| Note: In the current implementation, if you add a brick to either rack 2 or 3, it would not be automatically included in the default destination. You would need to reset the default destination. |
L2> destination 002c05 (127.0.0.1:0:2) 003c05 (127.0.0.1:0:0) L2> |
The following command resets the default destination to all racks and all slots:
L2> destination reset default destination reset to all racks and slots L2> |
Current Destination
The current destination is a range of racks and slots for a given command. For example, the following command sends the command <L1 command> to all bricks in racks 2, 3, 4, and 7:
L2> r 2-4,7 <L1 command> |
This is a one-time destination.
Command Interpretation
Some L2 commands are the same as the L1 commands. In many cases, this is intentional because the L2 emulator provides sequencing that is necessary for a command to function correctly.
When L1 and L2 commands are similar, you can assure that an L1 command is entered for the bricks in the current destination by preceding the command <L1 command> with the l1 command:
L2> r 2-4,7 l1 <L1 command> |
This is a one-time destination.
All information, warnings, and error messages generated by any of the system controllers are in the following form:
001c05 ERROR: invalid arguments for `ver' command, try “help ver” |
The general format includes a brick identification and the type of message, followed by the message. A message may be the result of an invalid command, as shown in the example, or the result of tasks running on the L1, such as the environmental monitor.
Each L1 has a log of local events. Use the L1 command log to view events on any of the L1s.
You can power on and power off the system with the power command. This command is interpreted by the L2 emulator, because the bricks must be powered on in a specific order.
L2> power up L2> |
The power command may require several seconds to several minutes to complete. In the example above, all racks and slots in the default destination are affected. Any errors or warnings are reported as described above in “Viewing Information, Warnings, and Error Messages”.
To power on or power off a specific brick, specify a current destination:
L2> r 2 s 5 power up L2> |
To power on or power off all bricks in a partition, enter the following:
L2> partition <partition number> <power up or power down> |
To reset the system, enter the following:
L2> reset L2> |
This command restarts the system by resetting all registers to their default settings and rebooting the system controllers. Resetting a running system will cause the operating system to reboot and all memory will be lost.
In console mode, all output from the system is visible and all input is directed to the system.
To enter console mode from L2, press Ctrl+D at the L2 prompt and observe the response:
L2> Ctrl+D entering system console mode (001c05 console0), <CTRL_T> to escape to L2 . <system output appears here> . |
To return to L2 mode from console mode, press Ctrl+T:
Ctrl+T escaping to L2 system controller L2> |
At this point, you can enter any L2 or L1 command. When the command completes, the L2 returns to console mode:
Re-entering system console mode (002c05 console0), <CTRL_T> to escape to L2 |
To permanently engage the L2 mode, press Ctrl+T and then enter the l2 command:
Ctrl+T escaping to L2 system controller L2> l2 L2 command processor engaged, <CTRL_D> for console mode. L2> |
When in console mode, the L2 emulator communicates with the CR-brick set with the select command to be the system console or global master. All input from the console is directed to the CR-brick. You can set and view the system console with the select command.
The L2 emulator chooses the CR-brick as the default console in the following order of priority:
The CR-brick in the lowest numbered rack and slot, which has produced console output, and has an attached IX-brick.
The CR-brick in the lowest numbered rack and slot, which has an attached IX-brick.
The CR-brick in the lowest numbered rack and slot.
The select command by itself shows the current console mode settings:
L2> select known system consoles (non-partitioned) 001c05-L2 detected current system console console input: 001c05 CPU 0A console output: not filtered |
The following are six common subchannels associated with console communications:
Subchannel 0A specifies Node 0, CPU A.
Subchannel 0C specifies Node 0 CPU B.
Subchannel 1A specifies Node 1, CPU A.
Subchannel 1C specifies Node 1, CPU B.
Node 0 console subchannel.
Node 1 console subchannel.
The output console input: 002c05 console0 shows that the L2 emulator will send console input to brick 001c05 and the console subchannel will be used.
To change the brick that will be the system console, use the select <rack>.<slot> command, where <rack> is the rack and <slot> is the slot where the brick is located:
L2> select 3.1 console input: 003c01 console console output: no filtered console detection: L2 detected |
To change the subchannel used on the selected brick to be the system console, use the select subchannel <0A|0C|1A|1C> command. (Use the select subchannel console to select the current console as the subchannel of the brick to be the system console.) For example, to select subchannel b as the subchannel of the brick to be the system console, enter the following:
L2> select subchannel 1A console input: 003c01 console CPU1A console output: no filtered |
During the boot process on a multibrick system, there is a window of time in which the CR-bricks are all producing output. This can result in a somewhat jumbled output from the L2 emulator. However, you can filter console output so that the L2 emulator will show output from only the brick chosen to receive console input. You can turn on filtering with the select filter on command and turn off filtering with the select filter off command.
If you attempt to communicate with a brick chosen to receive console input but that is not responding, a time-out condition results:
L2> Ctrl+D entering console mode 001c05 CPU1A, <CTRL_T> to escape to L2 no response from 001c05 Junk bus CPU1A system not responding no response from 001c05 Junk bus CPU1A system not responding |
When this time-out condition occurs, either the brick is hung or the subchannel is not correct.
In L1 mode, the prompt from a single L1 is visible, and all input is directed to that L1 command processor.
To enter L1 mode, enter the rack and a slot followed by l1:
L2> r 2 s 1 l1 enterling L1 mode 001c05, <CTRL-T> to escape to L2 001c05-L1> |
To return to L2 emulation mode, press Ctrl+T:
001c05-L1> Ctrl+T escaping to L2 system controller, <CTRL-T> to send escape to L1 L2> |
At this point, you can enter any L2 command. Once the command is executed, the L2 emulator returns to L1 mode:
re-entering L1 mode 002c01, <CTRL-T> to escape to L2 001c05-L1> |
To permanently engage the L2 emulation mode, press Ctrl+T and enter the l2 command:
002c01-L1> Ctrl+T escaping to L2 system controller, <CTRL-T> to send escape to L1 L2> l2 L2 command processor engaged, <CTRL-T> for console mode. |
L2>
The L1 firmware is currently distributed as part of the snxsc_firmware package. To determine which version of the package is installed on your system console, enter the following command:
$> rpm -q snxsc_firmware |
If the package is installed, the full package name (including the revision) is returned:
snxsc_firmware-1.18.3-1 |
The L1 firmware binary and the utilities used to update it are stored in /usr/cpu/firmware/sysco.
Note that a USB-to-Ethernet adapter connection or SGIconsole option is required to execute the commands described in this section. See “Console Hardware Requirements” and Figure 2-2 for descriptions of the hardware connections.
The L1 firmware consists of three parts:
Boot image
A image
B image
At boot time, the boot image validates the A and B image, and if it is not instructed otherwise, it executes the newer of the two images. Because the L1 is running one of the two images, the image not in use is the image that will be overwritten when the firmware is upgraded. You need to re-boot any L1 update either by power-cycling the brick or by using the L1 command reboot_l1.
Typically, you will upgrade the firmware through the network connection from the SGIconsole to the L1:
$> /usr/cpu/firmware/sysco/flashsc --12 10.1.1.1 -p /usr/cpu/firmware/sysco/l1.bin all |
This updates all the bricks in the system. The -p at the end of the first line instructs the firmware to flash the proms in parallel.
You can update individual bricks by replacing all with a rack and slot number:
$> /usr/cpu/firmware/sysco/flashsc --12 10.1.1.1 /usr/cpu/firmware/sysco/l1.bin 1.19 |
This updates only the brick in rack 1, slot 19