Intel® NetStructure™ MPCMM0001 Chassis Management Module Software Technical Product Specification April 2005 Order Number: 273888-007
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.
Contents Contents 1 Introduction.................................................................................................................................... 16 1.1 1.2 2 Software Specifications ................................................................................................................. 18 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 Red Hat* Embedded Debug and Bootstrap (Redboot) ....................................................... 18 Operating System .........................
Contents 4.5 4.6 4.7 4.8 4.9 5 Re-enumeration............................................................................................................................. 39 5.1 5.2 5.3 5.4 5.5 6 Overview............................................................................................................................. 39 Re-enumeration on Failover ............................................................................................... 39 Re-enumeration of M5 FRU.......................
Contents 6.8 6.9 6.10 6.11 7 Power and Hot Swap Management............................................................................................... 68 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 8 Process Integrity Executable (PIE) ..................................................................................... 54 Configuring pms.ini ............................................................................................................. 55 6.9.1 Global Data ........................................
Contents 9 Resetting the Password................................................................................................................. 99 9.1 9.2 10 Sensor Types .............................................................................................................................. 101 10.1 10.2 10.3 10.4 11 11.2 11.3 11.4 11.5 12.2 12.3 12.4 12.5 12.6 LED Types and States......................................................................................................
Contents 13.3.3 Resetting a Board ................................................................................................128 14 Electronic Keying Manager..........................................................................................................129 14.1 14.2 14.3 15 CDMs and FRU Information ........................................................................................................130 15.1 15.2 15.3 15.4 16 16.6 16.7 16.8 16.9 16.10 16.11 16.12 16.13 16.
Contents 17.4 17.5 17.6 17.7 17.8 18 CMM Scripting ............................................................................................................................. 164 18.1 18.2 18.3 18.4 18.5 19 19.3 19.4 Setting Up the RPC Interface ........................................................................................... 174 Using the RPC Interface ................................................................................................... 174 19.2.1 GetAuthCapability() ..
Contents 20.5 20.6 20.7 20.8 20.9 20.10 RMCP Session Activation .................................................................................................191 RMCP Port Numbers ........................................................................................................192 IPMB Slave Addresses .....................................................................................................193 CMM RMCP Configuration ......................................................................
Contents 23.17.1 Required Setup.................................................................................................... 215 23.17.2 Update Procedure................................................................................................ 215 24 Updating Shelf Components........................................................................................................ 217 25 IPMI Pass-Through..........................................................................................
Contents 27.8.1 FRUNAME ...........................................................................................................233 27.8.2 FRUADDRESS ....................................................................................................234 27.8.3 FRUAREA............................................................................................................234 27.8.4 MULTIREC ..........................................................................................................
Contents 32.4 32.5 32.6 32.7 33 Taiwan Class A Warning Statement ................................................................................. 266 Japan VCCI Class A ......................................................................................................... 266 Korean Class A................................................................................................................. 266 Australia, New Zealand............................................................................
Contents 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 Dataitem Keywords for All Locations Except System .................................................................80 Dataitem Keywords for All Locations Except Chassis and System ............................................ 81 Dataitem Keywords for Chassis Location ...................................................................................
Contents 74 [FanTray/pem]FruTable/[fanTray/pem]FruEntry (1.3.6.1.4.1.343.2.14.2.10.[5/6].53.1) ........... 157 75 [FanTray/pem]FruTargetTable/[fanTray/pem]FruTargetEntry (1.3.6.1.4.1.343.2.14.2.10.[5/6].54.1) ....................................................................................... 158 76 SNMP v3 Security Fields For Traps ......................................................................................... 162 77 SNMP v3 Security Fields For Queries ........................................
Contents Revision History Date Revision April 2005 007 August 2004 006 Description Firmware version 5.2 Firmware version 5.1.0.757 Version 5.1 TPS April 2004 005 Added Re-Enumeration Section Added Process Monitoring Section January 2004 004.1 Version 4.
Introduction 1 Introduction 1.1 Overview The Intel® NetStructureTM MPCMM0001 Chassis Management Module is a 4U, single-slot CMM intended for use with AdvancedTCA* PICMG* 3.0 platforms. This document details the software features and specifications of the CMM. For information on hardware features for the CMM refer to the Intel® NetStructure™ MPCMM0001 Hardware Technical Product Specification. Links to specifications and other material can be found in Appendix B, “Data Sheet Reference.
Introduction Table 1.
Software Specifications Software Specifications 2.1 2 Red Hat* Embedded Debug and Bootstrap (Redboot) Upon initial power on, the CMM enters into the Redboot firmware to bootstrap the embedded environment. Upon execution, Redboot acts as a TFTP server and checks for a TFTP connection to a client. If a TFTP connection exists, Redboot will accept a firmware update that is pushed down from the client, check the firmware update for data integrity, and then write the update to the flash.
Software Specifications 2.5 Remote Procedural Call (RPC) Interface In addition to the console command-line interface, the CMM can be administered by custom remote applications via remote procedure calls (RPC). RPC is covered in Section 19, “Remote Procedure Calls (RPC)” on page 174. 2.6 RMCP RMCP (Remote Management Control Protocol) is a protocol that defines a method to send IPMI packets over LAN.
Software Specifications Where location is one of {cmm, blade[1-14], fantray1, PEM[1-2]}. Even though the CMM uses a single flat SEL for system events, the ‘cmmget’ command will filter the SEL and only return events associated with the provided location. Also, some individual FRUs may keep their own local SELs (i.e., blades). 2.8.3 Clearing the SEL The following command will clear the SEL on both the active and the standby: cmmset -d clearsel -v clear Note: 2.8.
Redundancy, Synchronization, and Failover Redundancy, Synchronization, and Failover 3.1 3 Overview The CMM supports redundant operation with automatic failover in a chassis using redundant CMM slots. In systems where two CMMs are present, one acts as the active shelf manager and the other as standby. Both CMMs monitor each other, and either can trigger a failover if necessary. Data from the active CMM is synchronized to the standby CMM whenever any changes occur. Data on the standby CMM is overwritten.
Redundancy, Synchronization, and Failover failover is forced before all priority 1 data items are synchronized to the standby CMM, the standby CMM can still become the active CMM but may not be able to properly manage the FRUs in the chassis. Table 2. CMM Synchronization (Sheet 1 of 2) File(s) or Data 22 Description Path Priority date and time Date and time IPMB 1 IP Address Settings CMM eth1, eth1:1, and eth0 IP address settings to allow CMMs to discover the other’s IP information.
Redundancy, Synchronization, and Failover Table 2. CMM Synchronization (Sheet 2 of 2) File(s) or Data Note: 3.3 Description Path Priority Issues files Issues files Ethernet 2 /usr/local/cmm/temp/pmssync.ini Recovery Action and escalation action for all the monitored processes except monitor process Ethernet 2 /usr/local/cmm/temp/pmsshadowsync.ini Recovery action and escalation action for monitor process Ethernet 2 The /.
Redundancy, Synchronization, and Failover upgrade: Synchronizes user scripts only when the other CMM has a newer firmware version. downgrade: Synchronizes user scripts only when the other CMM has an older firmware version. always: Synchronizes user scripts irrespective of version differences. 3.3.2.
Redundancy, Synchronization, and Failover 3.5 Datasync Status Sensor A sensor named “Datasync Status” exists in order to make the Datasync state information available to the user. This sensor tracks the status of the Datasync module and will make its status available through the various CMM interfaces. This sensor is used to query the data synchronization states, and log SEL events for initial synchronization complete event.
Redundancy, Synchronization, and Failover There is Priority 2 data to sync. No Data Synchronization problems known. Initial Data Synch Incomplete, Pri 1 Data Synced, Pri 2 Data Not Synched The current value is 0x0003 Initial Data Synchronization is not complete. Priority 1 data is synced. There is Priority 2 data to sync. No Data Synchronization problems known. Initial Data Sync is complete, Priority 1 and Priority 2 are also synced The current value is 0x000f Initial Data Synchronization is complete.
Redundancy, Synchronization, and Failover Priority 2 data is synced. Data Synchronization has encountered a problem in synchronizing data. Data Sync becomes normal after Data Sync failure The current value is 0x000f Initial Data Synchronization is complete. Priority 1 data is synced. Priority 2 data is synced. No Data Synchronization problems known Single CMM The current value is 0x0000 Datasync disabled - there is no partner CMM present. 3.5.
Redundancy, Synchronization, and Failover • When initial data synchronization is complete, the following SNMP trap is generated: [Month] [Date] [Time] [hostname] snmptrapd[xxxxx]: [IP Address]: Enterprise Specific Trap (25) Uptime: [Time], SNMPv2SMI::enterprises.343.2.14.1.5 = STRING: "Time : [Day] [Month] [Date] [Time] [Year], Location : [location] , Chassis Serial # : [xxxxxxxx], Board : CMM[x] , Sensor : CMM[x]:Datasync Status , Event : Initial Data Synchronization is complete. Asserted " 3.5.
Redundancy, Synchronization, and Failover The active CMM will failover to the standby CMM if the active CMM cannot ping its first SNMP trap address (SNMPTrapAddress1) over any of the available Ethernet ports, but the standby CMM can. The trap address is set using the command: cmmset –l cmm –d snmptrapaddress1 –v [ip address] Only a ping failure of the first SNMP trap address (SNMPTrapAddress1) can cause a failover. SNMPtrapaddress2 through SNMPtrapaddress5 do not perform this ping test.
Redundancy, Synchronization, and Failover 3.7 CMM Ready Event The CMM Ready Event is a notification mechanism that informs the user when all CMM modules are fully up and running. The CMM is ready to process any request after receiving this event. The CMM uses the "CMM Status" sensor when generating the CMM Not Ready event. Please refer to Table 46, “CMM Status Event Strings (CMM Status)” on page 118 for CMM status event strings. Table 3.
Built-In Self Test (BIST) Built-In Self Test (BIST) 4 The CMM provides for a Built-In Self Test (BIST). The test is run automatically after power up. This test detects flash corruption as well as other critical hardware failures. Results of the BIST are displayed on the console through the serial port during boot time. Results of BIST are also available through the CLI if the OS successfully boots. If the BIST detects a fatal error, the CMM is not allowed to function as an active CMM. 4.
Built-In Self Test (BIST) Figure 1.
Built-In Self Test (BIST) 4.2 Boot-BIST The codes in Boot-BIST are executed at the very early stage of the RedBoot bootstrap, which is just before the FPGA programming and memory module initialization. Boot-BIST performs checksum checking over the RedBoot image and the FPGA image. A checksum error will be detected if there is a mismatch between the calculated checksum and the stored checksum in FIS directory. Boot-BIST also performs a Base Memory Test for the first 1 MByte of memory.
Built-In Self Test (BIST) Figure 2. Timing of BIST Stages HAL initialization (processor, cache, serial port) Boot-BIST FPGA programming Memory parameters initialization Early-BIST Module initialization (flash, zlib, ide) Mid-BIST Module initialization (ethernet interface) Late-BIST Display copyright banner, and execute boot script Done 4.6 QuickBoot Feature This feature will skip all the diagnostics tests in the mid-BIST and late-BIST, once it has been enabled.
Built-In Self Test (BIST) Execute extended memory test: true OS image checksum at boot: true ... Update RedBoot non-volatile configuration - are you sure (y/n)? y The default 'Enable QuickBoot during BIST' is true. When 'Enable QuickBoot during BIST' set to false, there will be two additional options displayed in the configuration menu. They are 'Execute extended memory test' and 'OS image checksum at boot' options. User can selectively enable one or both tests during the QuickBoot disabled mode.
Built-In Self Test (BIST) 4.8.2 Monitoring the Dynamic Images For monitoring the dynamic images, the CMM leverages the corruption detection ability from the JFFS(2) flash file system. At OS start-up, the CMM executes an initialization script to mount the JFFS(2) flash partitions (/etc and /home). If a flash corruption is detected, an event is logged to the CMM SEL. During normal OS operation, flash corruption during file access can also be detected by the JFFS(2) and/or the flash driver.
Built-In Self Test (BIST) value to the first test offset. It is then verified that the initial data value is still stored at every other power-of-two offset. If a location is found, other than the one just written, that contains the new data value, there is a problem with the current address bit. If no overlapping is found, the procedure is repeated for each of the remaining offsets.
Built-In Self Test (BIST) 4.9.9 IPMB Bus Busy/Not Ready Test • The objective of the test is to identify any potential FPGA lockup before loading the BlueCat. When the FPGA is detected to be locked up, an event indicating which bus actually failed is logged into the Event log.
Re-enumeration Re-enumeration 5.1 5 Overview The Chassis Management Module has the ability to re-enumerate devices in the chassis in the event that the chassis loses and then regains CMM management. This allows the CMM to query information on all devices in the chassis on startup if there are no active CMMs in that chassis already containing that information from which it can receive via a regular synchronization.
Re-enumeration 5.3 Re-enumeration of M5 FRU If, during re-enumeration, the CMM discovers that a FRU is requesting for deactivation (State M5), it denies the request and informs the FRU to go back to Active (M4) state if there is no frucontrol script present (refer to Section 18.5, “FRU Control Script” on page 169). Otherwise, the CMM executes the frucontrol script and lets it handle the deactivation of the FRU. 5.
Process Monitoring and Integrity Process Monitoring and Integrity 6.1 6 Overview The Chassis Management Module monitors the general health of processes running on the CMM and can take recovery actions upon detection of failed processes. This is handled by the Process Monitoring Service (PMS). Upon detecting unhealthy processes, the PMS will take a configurable recovery action. Examples of recovery actions include restarting the process, failing over to the standby CMM, etc.
Process Monitoring and Integrity watchdog monitoring is relatively lightweight and can be done every second, although, the process being monitored may dictate a (much) lower frequency depending on how often it is capable of feeding the watchdog. 6.1.3 Process Integrity Monitoring The Process Integrity Executable (PIE) will be responsible for determining the health of process or processes.
Process Monitoring and Integrity • PmsGlobal Target for PMS global data • PmsProc[#] Target for each process monitored • PmsPie[#] Target for each PMS PIE Use the following CLI command to view the targets for the processes being monitored. cmmget -l cmm -d listtargets The particular processes being monitored will be listed (e.g., PmsProc23, PmsProc100).
Process Monitoring and Integrity 6.5 SNMP MIB Commands SNMP commands are implemented in the CMM mib for Process Monitoring. The list of new commands can be found in the CMMs MIB file or in Section 17, “SNMP” on page 140. 6.6 Process Monitoring CMM Events The “Process Monitoring Service” sensor types are used to assert and de-assert process status information such as process presence not detected, process recovery failure, or recovery action taken. See Section 11.
Process Monitoring and Integrity ProcessSeverity=3 Note: The recovery action and escalation action should not be set to "no action" for the xinetd process. This process is involved in data synchronization between the CMMs. Note: When a user tries to change the recovery action for cmd_hand or BPM to values other than allowed via the CLI API, the error string displayed is: "Recovery action not allowed for this target." 6.
Process Monitoring and Integrity Table 6. No Action Recovery Description PMS detects a faulty process. The mechanism (existence, thread watchdog, or integrity) used to detect the fault will determine which of the event type strings will be used.
Process Monitoring and Integrity 6.7.3 Successful Failover/Restart Recovery In this scenario PMS detects a process fault. The configured recovery action is: failover to the standby CMM and then restart the failed process. The PMS is able to successfully recover the process by restarting it. Table 8. Successful Failover/Restart Recovery Description PMS detects a faulty process.
Process Monitoring and Integrity 6.7.4 Successful Failover/Reboot Recovery In this scenario, PMS detects a process fault. The configured recovery action is: failover to the standby CMM and upon successfully executing the failover, reboot the now standby CMM. The recovery actions are successful. Table 9. Successful Failover/Reboot Recovery Description PMS detects a faulty process.
Process Monitoring and Integrity Table 10. Failed Failover/Reboot Recovery, Non-Critical Description PMS detects a faulty process. The mechanism (existence, thread watchdog, or integrity) used to detect the fault will determine which of the event type strings will be used.
Process Monitoring and Integrity Table 11. Failed Failover/Reboot Recovery, Critical Description PMS detects a faulty process. The mechanism (existence, thread watchdog, or integrity) used to detect the fault will determine which of the event type strings will be used.
Process Monitoring and Integrity Table 12. Existence Fault, Excessive Restarts, Escalate No Action (Sheet 2 of 2) Description UID Assert Severity PMS detects that the process has been restarted excessively. Recovery failure due to excessive restarts # N/A Configure PMS attempts to execute the escalated recovery action. Since the recovery action is "no action", PMS disables monitoring of the process.
Process Monitoring and Integrity 6.7.9 Excessive Restarts, Failed Escalate Failover/Reboot, NonCritical In this scenario PMS detects a process fault. The severity of the process is configured to a value that is not critical. The configured recovery action is: restart the process. However, the PMS also detects that the process has exceeded the threshold for excessive process restarts. Therefore, the PMS will execute the escalation action.
Process Monitoring and Integrity recovery action is unsuccessful (standby is not available, etc.). The process being monitored is of critical severity and therefore the reboot of the CMM will still be executed even though the CMM is still active. Table 15. Excessive Restarts, Failed Escalate Failover/Reboot, Critical Description PMS detects a faulty process. The mechanism (existence, thread watchdog, or integrity) used to detect the fault will determine which of the event type strings will be used.
Process Monitoring and Integrity 6.7.12 Excessive Failover/Reboots, Administrative Action Prior to executing any failover/reboot the PMS will determine if the failover/reboot threshold has been exceeded. If it has, the PMS will be operationally disabled. When PMS is disabled, all process monitoring is halted. To re-enable the PMS, the operator must lock the global administrative state. The operator can then fix the problem and administratively unlock the global administrative state.
Process Monitoring and Integrity 6.9 Configuring pms.ini The pms.ini file is the Process Monitoring Service (PMS) and Process Integrity Exectuable (PIE) configuration file. It contains all of the non-volatile configuration data for the service. This file can be found in the /etc/cmm directory on the CMM. It is an ASCII based text file that can be edited with vi or any other text editor. Note: Any changes made to the pms.ini file will be overwritten during a firmware update.
Process Monitoring and Integrity ExcessiveRebootOrFailoverInterval = 21600 6.9.2 Process Specific Data This data applies to a specific process running on the CMM. There will be one set of this data for each process. The following information describes each of the fields in the process specific section. 6.9.2.1 Process Section Name The section name MUST follow the pattern "PmsProcessXXX" where XXX is a number from 010 to 175 inclusive.
Process Monitoring and Integrity space separated with the program name being the first entry in the string. If an individual argument contains spaces, the argument must be encapsulated in quotation marks. The program name and arguments will uniquely identify the entry. This means if the same program is started multiple times with different arguments, each of them will require a separate entry. Values: N/A. Default: None. CommandLine = MyProcess -x -y 6.9.2.
Process Monitoring and Integrity 6.9.2.10 Process Severity An indicator for the importance of a given process. This severity will determine at what level SEL entries are generated and when reboots should occur on an active CMM. Values: 1 = minor, 2 = major, 3 = critical. Default: 1. ProcessSeverity = 1 6.9.2.11 Recovery Action This is the recovery action to take upon detection of a failed process. Values: 1 = no Action, 2 = process restart, 3 = failover and process restart, 4 = failover and reboot.
Process Monitoring and Integrity [PmsProcess002] UniqueID = 2 CommandLine = ./PmsMonitor shadow StartCommandLine = ./PmsMonitor shadow AdminState = 1 ProcessExistenceInterval = 2 ThreadWatchdogRetries = 5 ProcessRampUpTime = 5 ProcessSeverity = 2 RecoveryAction = 2 ProcessRestartEscalationAction = 1 ProcessRestartEscalationNumber = 10 ProcessRestartEscalationInterval = 4800 6.9.3.2 Monitor Process This process must exist to monitor all other processes.
Process Monitoring and Integrity 6.9.3.3 Chassis Wrapper Process [PmsProcess023] UniqueID = 23 CommandLine = ./WrapperProcess 23 StartCommandLine = ./WrapperProcess 23 AdminState = 1 ProcessExistenceInterval = 2 ProcessRampUpTime = 10 ProcessSeverity = 2 RecoveryAction = 2 ProcessRestartEscalationAction = 2 ProcessRestartEscalationNumber = 4 ProcessRestartEscalationInterval = 5400 6.9.3.4 CMM Wrapper Process This process must exist to execute interface commands (CLI, SNMP, etc.) for the CMM.
Process Monitoring and Integrity 6.9.3.5 SNMP [PmsProcess051] UniqueID = 51 CommandLine = /usr/sbin/snmpd -c /etc/snmpd.conf StartCommandLine = /usr/sbin/snmpd -c /etc/snmpd.conf AdminState = 1 ProcessExistenceInterval = 2 ProcessRampUpTime = 30 ProcessSeverity = 2 RecoveryAction = 2 ProcessRestartEscalationAction = 2 ProcessRestartEscalationNumber = 4 ProcessRestartEscalationInterval = 5400 6.9.3.6 CLI Server [PmsProcess052] UniqueID = 52 CommandLine = ./cli_svr StartCommandLine = .
Process Monitoring and Integrity as valid recovery actions for cmd_hand. The default recovery action for cmd_hand process is 4 (failover and reboot) and that cannot be changed to anything else. A recovery action of 1 (No Action) is also not allowed because of the severity of the process. In the event that cmd_hand process terminates unexpectedly, and the default recovery action kicks in, there is 2-3 minute delay before the CMM actually reboots.
Process Monitoring and Integrity ProcessRestartEscalationAction = 2 ProcessRestartEscalationNumber = 5 ProcessRestartEscalationInterval = 300 6.9.3.
Process Monitoring and Integrity ProcessSeverity = 2 RecoveryAction = 2 ProcessRestartEscalationAction = 2 ProcessRestartEscalationNumber = 5 ProcessRestartEscalationInterval = 300 6.9.3.
Process Monitoring and Integrity 6.10.2 Process Integrity Executable The name, including its path and command line arguments, of the PIE to be executed periodically. This is used to start the program and may, in the future, be used to monitor the program and therefore must be an exact match to how the program is represented in the OS. The program name and command line arguments will all be space separated with the program name being the first entry in the string.
Process Monitoring and Integrity 6.10.5 Process Integrity Interval This is the interval in seconds between executions of the PIE. Values: 0 - 65535, where 0 indicates that the PIE only gets executed once. Default: 3600. ProcessIntegrityInterval = 3600 6.10.6 Chassis Applicability This is a list of chassis types on which this particular Pie should be run. The list is comma delimited. Spaces are ignored. If this key is not present, then the Pie will run on all chassis.
Process Monitoring and Integrity 6.11 WP/BPM PIE The command line usage of PmsPieWp is: PmsPieWp [-s] [-d[NumberOfDynamicWrappersPerRun]] [-f SuccessiveFailureNumber] where: -s: check static wrappers (optional) -d: check dynamic wrappers and bpm threads (optional) Number of dynamic wrappers and bpm threads to check on each run (optional) Values: 0 - 100. Default : 0 = process all dynamic wrappers and bpm threads on each execution.
Power and Hot Swap Management Power and Hot Swap Management 7 The CMM is responsible for the management of FRU hot-swap activities. The CMM listens to FRU hot-swap SEL messages from IPMI devices and distributes power to each FRU after negotiating with the respective IPMI device fronting the FRU. The CMM also manages the shelfwide power budget. The CMM also polls IPMI devices to get the status of each FRU fronted by the IPMI device.
Power and Hot Swap Management 7.4 Surprise FRU Extraction/IPMI Failure The CMM detects a surprise FRU extraction or a failure of the IPMI device fronting the FRU if a device previously in one of the M2-7 states reports a transition to the M2 state. If this scenario is detected, the CMM assumes one of three things has happened: • Surprise extraction and reinsertion of the same (or another) FRU. • IPMI Device fronting the FRU failed, FRU was extracted, then the same (or another) FRU is reinserted.
Power and Hot Swap Management 7.8 Pinging IPMI Controllers The following lists the values of time to delay and number of pings that the CMM uses to determine the state of a FRU. Table 18. Time to Delay and Number of Attempts Variable 70 Description Value DelayBetweenPingLoops The number of microseconds to delay between each ping loop. This is essentially the amount of time from the ping of the last IPMI Controller in the list to the ping of the first controller in the list.
The Command Line Interface (CLI) The Command Line Interface (CLI) 8.1 8 CLI Overview The Command Line Interface (CLI) connects to and communicates with the intelligent management devices of the chassis, boards, and the CMM itself. The CLI is an IPMI-based library of commands that can be accessed directly or through a higher-level management application. Administrators can access the CLI through a Telnet session, SSH, or through the CMM's front panel serial port.
The Command Line Interface (CLI) 8.3 Initial Setup— Logging in for the First Time Logging in for the first time must be done through the serial port console to properly configure the Ethernet settings and IP addresses for the network. The username for the CMM is root. The default password is cmmrootpass. At the login prompt, enter the username: root When prompted for the password, enter: cmmrootpass The root password can be changed using the passwd command.
The Command Line Interface (CLI) gateway, and thereby eth1:1, uncomment the two lines under the eth0 section of /etc/pump.conf and comment the two lines under the eth1 section of that file. Save the file and run the /etc/rc.d/ network reload script. Note: It is recommended that both CMMs use static IP addresses for all interfaces. DHCP addresses may be unexpectedly lost or changed in some network configurations. Note: eth0 should always be set to a different subnet than eth1/eth1:1.
The Command Line Interface (CLI) Table 19. SETIP Interface Assignments when BOOTPROTO=”static” Interface SETIP=1 SETIP=2 SETIP=Both Other eth1 STATICIP1 STATICIP2 STATICIP1 Previous Value eth1:1 disabled disabled STATICIP2 disabled 5. Add the NETMASK1 variable and set it to the appropriate netmask for STATICIP1 for your network. 6. Add the NETMASK2 variable and set it to the appropriate netmask for STATICIP2 for your network.
The Command Line Interface (CLI) 4. Add the NETMASK2 variable and set it to the appropriate netmask for STATICIP2 for your network. The NETMASK2 variable needs to be correct to allow for true redundant operation. 5. Add the GATEWAY1 variable and set it to the appropriate value for the gateway for STATICIP1. 6. Add the GATEWAY2 variable and set it to the appropriate value for the gateway for STATICIP2 7. Set the SETIP variable to assign IP addresses eth1 and eth1:1 based on the following table: Table 20.
The Command Line Interface (CLI) 8.3.4 Setting the Date and Time On the active CMM, use the date command in the CLI to view the current date and time for the CMM. To set the date and time on the CMM use the setdate command. The setdate command should use the following syntax: setdate “mm/dd/yyyy [timezone] hh:mm:ss” The date is stored on the CMM in Coordinated Universal Time (UTC).
The Command Line Interface (CLI) 8.4 CLI Command Line Syntax and Arguments The command line interface on the CMM supports two types of commands: cmmget and cmmset. cmmget is used to query for information, whereas cmmset is used to write information. There are man pages available on the CMM for these two commands. To access the man page for cmmget use the command man cmmget. To access the man page for cmmset, use the command man cmmset. 8.4.
The Command Line Interface (CLI) Table 21. Location (-l) Keywords Keyword chassis Chassis specific information. fantrayN The system fantray where N is the number of the fantray. For example, fantray1 refers to the single fantray in the MPCHC0001 shelf. NOTE: fantray1 may also be referred to as blade15 in a 14 slot chassis or blade17 in a 16 slot chassis. PEM1 PEM2 8.4.4 Function The system Power Entry Modules.
The Command Line Interface (CLI) The following table shows the values target can be for the CMM location. Table 22. CMM Targets Keyword Description Brd Temp Board Temperature CPU Temp CPU Temperature FilterTrayTemp[1,2] Filter Tray Temperature Sensors CPU Core V CPU Core Voltage VBAT Battery Voltage VTT DDR CMM Memory voltage +2.5V +2.5V voltage sensor +3.3V +3.
The Command Line Interface (CLI) 8.4.5 Dataitem Parameter: -d The dataitem is the parameter, identified by target and/or location, that the user is getting or setting. The dataitem must be given for every CLI command. 8.4.5.1 Location Dataitem lists Table 23 through Table 29 list the valid dataitems for each location when no target is specified. Table 23.
The Command Line Interface (CLI) Table 25. Dataitem Keywords for All Locations Except Chassis and System (Sheet 1 of 4) Dataitem Description Get/Set CLI Get Output Valid Set Values "GetDeviceID: < interpreted string without label> Device ID = SDR Support = Device Revision = Device Available = Firmware Revision =
The Command Line Interface (CLI) Table 25. Dataitem Keywords for All Locations Except Chassis and System (Sheet 2 of 4) Dataitem Description Get/Set CLI Get Output Valid Set Values Set the FRU payload to do things like Cold Reset, Warm Reset, etc. The CMM location only supports 2 (graceful reboot) and will only work on standby CMM. Using frucontrol on an active or single CMM will attempt a failover before executing the command.
The Command Line Interface (CLI) Table 25. Dataitem Keywords for All Locations Except Chassis and System (Sheet 3 of 4) Dataitem Description Get/Set CLI Get Output Valid Set Values Retrieves and sets power state of a blade. Get: This is used to find out the powered on/off or offline state of a blade Set: To reboot, shutdown and turn on a blade powerstate If “reset” is used on CMM location, the software will check for redundancy and a reset will only occur if a redundant partner is identified.
The Command Line Interface (CLI) Table 25. Dataitem Keywords for All Locations Except Chassis and System (Sheet 4 of 4) Dataitem Description Get/Set CLI Get Output Valid Set Values Metallic Test Bus Pair #1: Token Owned: Yes/No Owner's IPMBAddress: IPMBAddress Metallic Test Bus Pair #2: Token Owned: Yes/No Owner's IPMBAddress: IPMBAddress Sync Clock Group #1: Token Owned: Yes/No Get a list of Bused EKeys and who owns them.
The Command Line Interface (CLI) Table 26. Dataitem Keywords for Chassis Location dataitem fanspeed location Description Used to get or set the fan speed of all fans in the chassis. Value is percent of the maximum fan speed. See Section 16, “Fan Control and Monitoring” on page 132 for more information. This is used to get or set the Location field in the chassis FRU and is sent out as a part of SNMP and UDP alarts. This is only used with the chassis location.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 1 of 7) dataitem Description Get/ Set CLI Get Output Valid Set Values All possible locations in the shelf e.g. “cmm blade1 blade2 blade3 blade4 blade5 blade6 listlocations Used to find out all the locations that can be queried. This list can contain both present and non-present locations.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 2 of 7) dataitem Description Get/ Set alarmcutoff Retrieve or set the state of the Telco Alarm cutoff. When enabled, it silences the Telco alarm for active events and blinks the event LEDs on the CMM. This dataitem is only valid when used with the cmm as the location and is used to set the alarm cutoff or get its value. alarmtimeout Retrieve or set the timeout value in minutes for the Telco Alarm cutoff.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 3 of 7) dataitem Description Get/ Set CLI Get Output Valid Set Values "Front" or "Rear" or "Backplane". For example, bash-2.04# cmmget -d cmm1ethernetA cmm1ethernetA: front cmm1EthernetA cmm1EthernetB cmm2EthernetA cmm2EthernetB Used only with the CMM location to change the eth0/ eth1 direction to either the front panel, the rear panel IO card, or backplane on CMM1 and/or CMM2. bash-2.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 4 of 7) dataitem Description Get/ Set CLI Get Output Valid Set Values 1=Enable snmpenable Used to set or query SNMP trap enabled status. Both SNMP traps are . 0=Disable enable disable snmptrapaddress[1-5] Get or Set the machine’s IP address that will receive SNMP traps from a location. Up to five addresses can be set. Default is 0.0.0.0 for all 5.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 5 of 7) dataitem syncuserledstate Description Gets/Sets whether the LED state is synced between the active and standby CMM. Get/ Set Both CLI Get Output "Yes" or "No" Valid Set Values “Yes” or “No” It will be in INI format displayed on the console as follows: [Settings] powersequence Used to get/set the power sequence order, Power Sequencing Delay, ShelfManagerControlledActiva tion in the CDM.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 6 of 7) dataitem AdminState Description Used to set or query the adminstrative state of the PMS as a whole or an individual monitored process. A target of “PmsGlobal” will get/set the state of the PMS as a whole. A target of “PmsProc[#]” will get/ set the unique state of an individual process, where # is the unique process number for the process.
The Command Line Interface (CLI) Table 27. Dataitem Keywords for Cmm Location (Sheet 7 of 7) dataitem Description Get/ Set CLI Get Output Valid Set Values standbycmmreboot Used to request to reboot the standby CMM from the active CMM. Set N/A 1 - Request to reboot the standby CMM feedcount Get the power feed count for that location. Determines number of feed targets (i.e., feed1) for that location. See Section 7.7, “Power Feed Targets” on page 69.
The Command Line Interface (CLI) Table 29. Dataitem Keywords for FantrayN Location dataitem Description minorlevel Used to set or query the minorlevel for the fantray. normallevel Used to set or query the normallevel for the fantray. control Used to set or query the control mode of the fantray. Get/ Set CLI Get Output Valid Set Values Both Any value between the normallevel and the majorlevel of the fantray. Both Any value between the minimumsetting and the minorlevel of the fantray.
The Command Line Interface (CLI) Table 30. Dataitem Keywords Used with the Target Parameter (Sheet 1 of 4) dataitem Description Get/ Set CLI Get Output Valid Set Values listdataitems Lists the available dataitems for that target. Get Listing of all valid data items that can be issued for the specified location or target N/A health Returns the health of the target and if any events exist. The returned values will be one of OK, minor, major, or critical.
The Command Line Interface (CLI) Table 30. Dataitem Keywords Used with the Target Parameter (Sheet 2 of 4) dataitem criticalaction majoraction minoraction normalaction Description Used to configure user-defined actions when events occur. This dataitem is used with a target (–t) parameter specified sensor and a value (-v) parameter. When an event happens for that particular sensor, then the script defined in the –v parameter will be executed.
The Command Line Interface (CLI) Table 30. Dataitem Keywords Used with the Target Parameter (Sheet 3 of 4) dataitem Description Get/ Set CLI Get Output Valid Set Values " is in mode " where is one of localcontrol/ override/ lamptest Gets or Sets a FRU LED’s state. The Get returns the LED’s mode, one of {localcontrol, override, or lamptest}, and a function message. Implements the Get/ Set FRU LED State commands. See PICMG 3.
The Command Line Interface (CLI) Table 30. Dataitem Keywords Used with the Target Parameter (Sheet 4 of 4) dataitem Description Get/ Set CLI Get Output Valid Set Values Both current in Amps with 1 decimal point current in Amps with 1 decimal point. Get current in Amps with 1 decimal point N/A Both voltage value in string between -36 to -72v voltage value in string between -36 to -72v Get/Set the field in the CDM regarding the max external available current. Only used with the feedN target.
The Command Line Interface (CLI) The filename should refer to a file that is in a valid directory (i.e. /home/cmmdump.txt).The file can then be retrieved off the CMM using FTP (see Section 8.3.7, “FTP into the CMM” on page 76).
Resetting the Password Resetting the Password 9 It may become necessary at some point to reset the CMM password to its default of cmmrootpass. The CMM has one on board dip switch labeled S2-1 to perform this action. Refer to the Intel® NetStructure™ MPCMM0001 Hardware Technical Product Specification for the location of the switch. Setting the switch and powering up the CMM will cause the password to reset to its default. The CMM then needs to be removed and the switch then needs to be turned off again.
Resetting the Password 9.2 Resetting the Password in a Single CMM System For nonredundant systems that contain only a single CMM, resetting the password will require removing the CMM. This will cause any boards that are power controlled by the CMM become unmanaged. Care should be taken to safely shut down boards in the system prior to removing the CMM. 1. Safely shut down and power off boards being power controlled by the CMM. 2. Remove the CMM from the system. 3. Set dip switch S2-1 to “on”.
Sensor Types Sensor Types 10.1 10 CMM Sensor Types The CMM provides access to and can log events from different IPMI sensor types. These sensors can be both threshold-based sensors or discrete sensors, depending on the type of reading and events they generate. For more information on sensors and sensor types, refer to the “Intelligent Platform Management Interface Specification v1.5”, available on http://www.intel.com. 10.
Sensor Types 10.3 CMM Voltage/Temp Sensor Thresholds Table 31 shows the threshold sensors present on the CMM with the Upper Non-Recoverable, Upper Critical, Upper Non-Critical, Lower Non-Critical, Lower Critical, and Lower NonRecoverable thresholds for each sensor. UseTable 34 on page 109 to determine the severity for an event that crosses a specific threshold on a sensor. Table 31. CMM Voltage and Temp Sensor Thresholds Sensor Name Note: 10.4 UNR UC UNC LNC LC LNR VBAT N/A 3.494 (3.463) 3.
Sensor Types 10.4.1 Discrete Sensor Events Discrete sensors can generate events on state changes for various sensors in the system. The severity of the event is determined by the CMM.
Health Events 11 Health Events This section describes the health events that are associated with CMM events and includes the syntax and severity of these strings. Refer to Section 10, “Sensor Types” on page 101 for more information on the different type of sensors. Note: 11.1 For this section, “health event” (two words) refers to any event that is generated that reports the health of a sensor.
Health Events \t[SDR Sensor Name]\t[Health Event String]: [Event Type]\n\n • Timestamp is in the format: [Day] [Month] [Date] [HH:MM:SS] [Year]. For example, Thu Dec 11 22:20:03 2003 • SDR Sensor Name is the name given to the sensor in the Sensor Data Record (SDR). • Health Event Strings are listed in Section 11.4. • Event Type is either “Assertion Event” or “Deassertion Event” stating whether it is an event that is being asserted or one that is being deasserted.
Health Events • Timestamp is in the format: [Day] [Month] [Date] [HH:MM:SS] [Year]. For example, Thu Dec 11 22:20:03 2003 • • • • • ChassisLocation is the chassis location information recorded in the chassis FRU. ChassisSN is the chassis serial number records in the chassis FRU. Location is the location where the sensor generating the event is located (i.e., CMM) SDR Sensor Name is the name given to the sensor in the Sensor Data Record (SDR). Health Event Strings are listed in Section 11.
Health Events Table 33. Sensor Targets (Sheet 2 of 2) 11.
Health Events 11.3.2 HealthEvents Queries for All Sensors on a Location Executing a healthevents query on the “cmm” location in the CLI without a target specified (cmmget -l cmm -d healthevents) returns all the healthevents for all CMM sensors in a concatenated string. This includes all BIST, LAN, Telco Alarm, Voltage, and Temp sensors on the CMM. This ability to retrieve all healthevents on a location also applies to the chassis, bladeN, FantrayN and PemN* locations. 11.3.
Health Events The table for threshold-based sensors is common to other threshold-based sensors on other components, e.g., voltage, temp, current). 11.4.1 All Locations Table 34.
Health Events Table 35.
Health Events Table 37.
Health Events Table 37.
Health Events Table 37.
Health Events Table 38.
Health Events 11.4.2 CMM Location Table 39.
Health Events Table 41. CMM Failover (Sheet 2 of 2) Event Code Event String Event Severity Hex Decimal “Failover cannot occur because the other CMM is not responding over its management bus.” 0x0E3 227 OK “Failover cannot occur because the critical items have not been synced.” 0x0E4 228 OK “Failover cannot occur because the other CMM has a bad hardware signal.” 0x0E5 229 OK “Failover occurred because the active CMM had older firmware than the newly active CMM.
Health Events Table 42. CMM Synchronization (Sheet 2 of 2) Event Code Event String Event Severity Hex Decimal “Could not copy the FRU manager information to the standby CMM.” 0x0FB 251 OK “Could not copy the IPMB state information to the standby CMM.” 0x0FC 252 OK “Could not copy the user LED information to the standby CMM.” 0x0FD 253 OK “Could not copy the cooling state information to the standby CMM.” 0x0FE 254 OK “Could not copy the sensors state information to the standby CMM.
Health Events Table 43. BIST Event Strings (Sheet 2 of 2) Event Code Event String Event Severity Hex Decimal “Update of /etc failed.” 0x0A4 164 Critical “Restore of /etc files failed.” 0x0A5 165 Critical “Software update failed.” 0x0A6 166 Critical “FPGA re-programmed 2 times and no further lockup detected.” 0x0B4 180 Minor “FPGA re-programmed 3 times and no further lockup detected.” 0x0B5 181 Minor “FPGA re-programming has failed.
Health Events Table 46. CMM Status Event Strings (CMM Status) Event Code Event String Event Severity Hex Decimal “CMM is Active” 0x402 1026 OK “CMM is Standby” 0x403 1027 OK “CMM ready timed out” 0x404 1028 Minor Table 47.
Health Events Table 48. Process Monitoring Service Info Event Strings (PMS Info) Event Code Event String Event Severity Hex Note: 11.4.
Health Events Table 50. IPMI Error Completion Codes and Enumerations Code 11.5.
Health Events "IMB ERROR Completion Code Error" When “IMBErrorCodeReporting” is set to 1 in /etc/cmm.cfg, then the following message will be displayed: IMB ERROR Completion Code Error: [IPMI Error Code] : [Error String] Where: IPMI Error Code: Ascii String of the IPMI error code returned in the IPMI response. The IPMI codes are listed in Table 50, “IPMI Error Completion Codes and Enumerations” on page 121.
Front Panel LEDs 12 Front Panel LEDs The CMM has nine LEDs on the front panel of each unit for displaying system health, hot swap state, and other information. They include: • • • • Three system health LEDs One CMM Health LED One CMM HotSwap State LED Four User-Definable LEDs (A-D) For more information on CMM LEDs refer to the Intel® NetStructure™ MPCMM0001 Hardware Technical Product Specification. 12.
Front Panel LEDs 12.1.2 Health LED Each CMM maintains a single health LED (®) to provide the status of the CMM. . Table 52. CMM Health LED States Color 12.1.3 Description Off No power to CMM Solid Green Normal operation, power okay Blinking Green CMM in standby mode Solid Red Attention status (CMM is unhealthy due to critical power error) Hot Swap LED Each CMM maintains a single blue hot swap LED (ÝÜ) to provide the status of the CMM itself.
Front Panel LEDs 12.4 Retrieving the State of LEDs The state of an LED on a location can be retrieved using the command: cmmget -l [location] -t [LED] -d ledstate 12.5 Setting the State of the User LEDs The state of the User LEDs on the CMM or other FRUs can be changed using the ledstate set command.
Front Panel LEDs 12.6 LED Boot Sequence During the boot process, the user LEDs will change in a pattern, as described in Table 55, “LED Event Sequence”, to indicate boot progress. The user LEDs will be off by the time the CMM software is fully loaded. Once the CMM is up, the administrator can control the LED through standard interfaces or via programmatic control. The following table describes the sequence of events following the insertion of the CMM and the corresponding LED state for each event.
Node Power Control Node Power Control 13 The CMM controls power to the nodes of a chassis. The CMM can power up, power down, and reset a board in a particular slot and can be used to query the operational state of a board at any time. The CMM also manages the overall power budget of the shelf as well as power budget of each power feed. The active CMM is responsible for power management when there are two CMMs operating in a redundant mode.
Node Power Control 13.3.3 Resetting a Board The following command will reset a board: cmmset -l bladeN -d powerstate -v reset N is the number of the physical slot where the blade to be reset resides. Once issued, the command will ask for confirmation by entering “y” before continuing.
Electronic Keying Manager Electronic Keying Manager 14 Electronic Keying (EKeying) is used in the AdvancedTCA* architecture to dynamically implement a specific fabric interconnect in a fabric agnostic backplane. The PICMG* 3.0 specification calls out two types of EKeying: point-to-point and bused. 14.1 Point-to-Point EKeying Point-to-point EKeying is used to set up a specific fabric interconnect and protocol between two end points when a board is inserted into the chassis.
CDMs and FRU Information CDMs and FRU Information 15.1 15 Chassis Data Module There are two chassis data modules (CDMs) in a chassis for redundancy.Each CDM has 2 EEPROMs containing the FRU information for the chassis. The CDM FRU data is also cached on the CMMs at boot time. The CDM stores serial number and asset information about chassis and provides PICMG 3.0 shelf FRU information, such as number of slots, slot connection/routing information (for electronic keying), and max power per feeds. 15.
CDMs and FRU Information 15.4 FRU Query Syntax The format for querying the FRU of a particular location is: cmmget -l [location] -t fru -d [dataitem] Where location is the component for which the FRU information is to be retrieved from, and dataitem is the field(s) of the FRU which will be retrieved. Table 56 lists the various FRU data items and the information they retrieve. Note: The chassis* data items in Table 56 are only available with the location “chassis”.
Fan Control and Monitoring Fan Control and Monitoring 16 The CMM controls the fan speeds and the fan tray LEDs. In a healthy state (no events), the LED is driven to green color. If any of the fan tray sensors (temperature, voltages, fan tachs) are in an unhealthy state, the LED is driven to red or amber (red by default). 16.
Fan Control and Monitoring statuses. At any moment the Cooling Manager can only operate at one temperature status, it is called the current temperature status. The four temperature statuses are normal, minor, major and critical. The Cooling Manager changes its current temperature status depending on what, if any, temperature events it has received. Here is how the Cooling Manager determines its current temperature status. • Normal– There is currently no asserted temperature event.
Fan Control and Monitoring N: The number of the fan tray being addressed. These values will take effect immediately after they are entered. That means that if fantrayN’s current temperature status is normal and the user sets the normallevel the current cooling level will change immediately. There are the limits on the possible cooling level values for the temperature statuses. The major status and the critical status are both always set to the maximum cooling level and are not configurable.
Fan Control and Monitoring modes. The user may change to this mode with the following command: cmmset –l fantrayN -d control –v emergencyshutdown Where: N: 16.6.4 The number of the fan tray being addressed. User Initiated Mode Change To change the control mode of a fantray, the user may use the command: cmmset –l fantrayN -d control –v [ CMM | fantray | EmergencyShutdown | defaultcontrol] N: The number of the fan tray being addressed. CMM: Sets the fan tray to CMM fan tray control mode.
Fan Control and Monitoring 16.8 Fantray Properties There are also commands to retrieve the fantray’s settings. These properties are maximum cooling level, minimum cooling level and recommended cooling level. The cooling manager gets the fan speed properties by performing an IPMI get fantray properties call on the fantray. This method is defined by the PICMG 3.0 specification. The user can use these values to determine how he configures the temperature statuses.
Fan Control and Monitoring 16.11 Default Cooling Values The CMM determines the fan tray cooling values from the /etc/cmm/fantray.cfg file. The CMM uses the defaults from the file in the following order of precedence: 1. User Defaults 2. Vendor Defaults 3. Code Defaults 16.11.0.1 Setting User Defaults and Defaultcontrol through the CLI During normal operation the user may use these commands to set the default values.
Fan Control and Monitoring 16.11.2 Structure of /etc/cmm/fantray.cfg All default values will persist in the /etc/cmm/fantray.cfg file. These will be stored in key=value pairings. These are the formats of those entries in the /etc/cmm/fantray.cfg file. Example 2. Sample /etc/cmm/fantray.cfg file 0157.870.minorlevel=76 0157.870.normallevel=72 0157.870.control=fantray 16.11.
Fan Control and Monitoring it can determine when a firmware upgrade/downgrade would affect the user defaults. When a fan tray is inserted into the chassis the Cooling Manager checks the /etc/cmm/fantray.cfg to see if there are recorded minimum and maximum values for that fan tray at that location. It will compare the recorded minimum and maximum to the minimum and maximum values that the inserted fan tray returns.
SNMP 17 SNMP The CMM supports v1 and v3 of the Simple Network Management Protocol (SNMP). The CMM can support SNMP queries and send SNMP traps in either v1 or v3. The SNMP interface on the CMM very closely mirrors that of the CLI in both syntax and function. Note: Like the CLI, SNMP commands should be issued to the active CMM. The standby CMM will only respond to commands for using the CMM location parameter.
SNMP 17.1 CMM MIB The CMM comes with a text file (mpcmm0001.mib) that describes the CMM and platform objects to be managed. A remote application such as an SNMP/MIB manager can compile and read this file and utilize this information to manage the sensor devices on CMM, chassis, and server blades currently present. The mpcmm0001.mib is located in the /usr/local/cmm directory in the CMM. Users can utilize FTP or RCP to get this file from the CMM. 17.
SNMP Figure 4. CMM Custom MIB Tree CMM Custom MIB Tree iso(1) ... org(3) dod(6) ... internet(1) ... directory(1) mgmt(2) experimental(3) private(4) security(5) snmpV2(6) enterprises(1) Intel (343) ... ... products(2) ... chassisManagement(14) ... mpcmm0001(2) sensorLocation(10) system(1) pems(6) shelf(2) cmm(3) blades(4) fanTrays(5) blade1(1) blade2(2) 17.2.2 ..... blade16(16) CMM MIB Objects All the objects below can be found in the mpcmm0001.mib file.
SNMP Table 60. System Location (1.3.6.1.4.1.343.2.14.2.10.1) OID Object Syntax Access Value 1 systemHealth INTEGER read-only Health information about a particular location. This will be one of the following: (0-OK, 1-Minor, 2-Major, 3-Critical) 2 systemUnhealthyLocation DisplayString read-only Used with the System location to find out what blades are having problems. 3 systemListDataItems DisplayString read-only Used to find out what data items are available on a Location.
SNMP Table 61. Shelf Location (Equivalent to Chassis) (1.3.6.1.4.1.343.2.14.2.10.2) OID Object Syntax Access Value 1 shelfListTargets DisplayString read-only Used to find out what targets are available on a location. (e.g., Getting the list of sensors in the chassis). 2 shelfListDataItems DisplayString read-only Used to find out what data items are available on a target or location. 3 shelfFanSpeed DisplayString read-write Used to get or set the fan speed in the chassis.
SNMP Table 62. ShelfTable/shelfEntry (1.3.6.1.4.1.343.2.14.2.10.2.50.1) (Sheet 2 of 2) OID Object Syntax Access Value 31 shelffruBoardManufactureDate DisplayString read-only Used to read the Board Manufacture Date from the FRU. 32 shelffruProductDescription DisplayString read-only Used to read the Product Description from the FRU. 33 shelffruProductManufacturer DisplayString read-only Used to read the Product Manufacturer from the FRU.
SNMP Table 63. Cmm Location (1.3.6.1.4.1.343.2.14.2.10.3) (Sheet 1 of 3) OID Syntax Access Value 1 softwareVersion DisplayString read-only The version of the CMM software. 2 cmmRedundancy DisplayString read-only cmm redundancy information. 3 rmcpEnabled INTEGER read-write Enable or disable the RMCP Service: disable(0), enable(1) 4 cmmGrantedBoardEkeys DisplayString read-only Get the Ekeys that have been granted to the location.
SNMP Table 63. Cmm Location (1.3.6.1.4.1.343.2.14.2.10.3) (Sheet 2 of 3) OID Object Syntax Access Value 24 cmmAlarmTimeOut INTEGER read-write The timeout value in minutes for the Telco Alarm cutoff. This is the amount of time before the alarm cutoff will automatically become unset if the user doesn't unset it themselves. A value of 0 will disable the timeout. This dataitem is only valid when used with the cmm as the location and is used to set the alarm timeout or get its value.
SNMP Table 63. Cmm Location (1.3.6.1.4.1.343.2.14.2.10.3) (Sheet 3 of 3) OID Syntax Access Value Perform the CMM firmware update. The set value is in the following format: 44 cmmUpdate DisplayString write 45 cmmResetAirFilterRuntime INTEGER write This allow the user to set the runtime to zero when the filter is replaced. 1 reset, other value no change. 46 cmmAirFilterRunTimeLimit DisplayString read-write Returns the upper critical limit. Refer to CLI section for more info.
SNMP Table 64. CmmTable/cmmEntry (1.3.6.1.4.1.343.2.14.2.10.3.51.1) (Sheet 1 of 2) OID Object Syntax Access Value 1 cmmTarget DisplayString none index 2 cmmCurrent DisplayString read-only The current value of a sensor. 3 cmmThresholdsAll DisplayString read-only All thresholds of a sensor.
SNMP Table 64. CmmTable/cmmEntry (1.3.6.1.4.1.343.2.14.2.10.3.51.1) (Sheet 2 of 2) OID 150 Object Syntax Access Value 43 cmmfruProductSerialNumber DisplayString read-only Used to read the Product Serial Number from the FRU. 44 cmmfruProductManufactureD ate DisplayString read-only Used to read the Product Manufacture Date from the FRU. 45 cmmfruProductModel DisplayString read-only Used to read the Product Model from the FRU.
SNMP Table 65. CmmFruTable/cmmFruEntry (1.3.6.1.4.1.343.2.14.2.10.3.52.1) OID Object Syntax Access Value 1 cmmFruNumber INTEGER none index 3 cmmFruHotSwapState DisplayString read-only Retrieve the hot swap state of the FRU from the CMM’s internally known hot swap states. Returns M state number (0-7) 4 cmmFruLedProperties DisplayString read-only Find out what LEDs the FRU supports.
SNMP Table 67. CmmPmsTable/cmmPmsEntry (1.3.6.1.4.1.343.2.14.2.10.3.54.1) (Sheet 2 of 2) OID Object Syntax Access Value 4 cmmPmsEscalationActio n DisplayString read-write The process escalation action defines how a faulty process that fails to restart will be recovered. Possible values: 1-No Action, 2Failover and Reboot. 5 cmmPmsProcessName DisplayString read-only Display the monitored process' name and its associated command line arguments.
SNMP Table 68. Blade# Location (1.3.6.1.4.1.343.2.14.2.10.4.[1-16]) OID 12 Object b#TotalFrus Syntax Access Value DisplayString read-only Displays the total number of FRUs 13 b#IPMICommandRequest DisplayString read-write Used to send any IPMI command to this location. 14 b#IPMICommandResponse DisplayString read-write Used to read the response to the above IPMI command. Table 69. Blade#TargetTable/blade#TargetEntry (1.3.6.1.4.1.343.2.14.2.10.4.[1-16].51.
SNMP Table 69. Blade#TargetTable/blade#TargetEntry (1.3.6.1.4.1.343.2.14.2.10.4.[1-16].51.1) (Sheet 2 of 2) OID Object Syntax Access Value 25 b#fruProductDescription DisplayString read-only Used to read the Product Description from the FRU. 26 b#fruProductManufacturer DisplayString read-only Used to read the Product Manufacturer from the FRU. 27 b#fruProductPartNumber DisplayString read-only Used to read the Product Part Number from the FRU.
SNMP Table 71. Blade#FruTargetTable/blade#FruTargetEntry (1.3.6.1.4.1.343.2.14.2.10.4.[1-16].53.1) OID Object Syntax Access Value 1 b#FruNumber INTEGER none Index 1 2 b#Target DisplayString none Index 2 3 b#FruLedColorProps DisplayString read-only Finds out what colors are supported by the LED. 4 b#FruLedState DisplayString read-write Get/Set the FRU LED state. Table 72. [FanTray/pem]Table/[fanTray/pem]Entry (1.3.6.1.4.1.343.2.14.2.10.[5/6].51.
SNMP Table 72. [FanTray/pem]Table/[fanTray/pem]Entry (1.3.6.1.4.1.343.2.14.2.10.[5/6].51.1) OID Object Syntax Access Value 19 fanTrayMaximumSetting DisplayString read-only The fantray's maximum setting. 20 fanTrayRecommendedSetting DisplayString read-only The fantray's recommended setting. 21 fanTrayCurrentFanLevel DisplayString read-only The fantray's current fan level. Table 73. [FanTray/pem]TargetTable/[fanTray/pem]TargetEntry (1.3.6.1.4.1.343.2.14.2.10.[5/ 6].52.
SNMP Table 73. [FanTray/pem]TargetTable/[fanTray/pem]TargetEntry (1.3.6.1.4.1.343.2.14.2.10.[5/ 6].52.1) (Sheet 2 of 2) OID Object Syntax Access Value 25 [fanTray/ pem]fruProductDescription DisplayString read-only Used to read the Product Description from the FRU. 26 [fanTray/ pem]fruProductManufacturer DisplayString read-only Used to read the Product Manufacturer from the FRU.
SNMP Table 75. [FanTray/pem]FruTargetTable/[fanTray/pem]FruTargetEntry (1.3.6.1.4.1.343.2.14.2.10.[5/6].54.1) OID 17.3 Object Syntax INTEGER Access none Value 1 [fanTray/pem]Number index 1 2 [fanTray/pem]FruNumber INTEGER none index 2 2 [fanTray/pem]Target DisplayString none index 3 4 [fanTray/pem]FruLedColorProps DisplayString read-only Finds out what colors are supported by the LED. 5 [fanTray/pem]FruLedState DisplayString read-write Get/Set the FRU LED state.
SNMP 3. Look for the snmpd process. There may be more than one, so use the lowest process ID, which is the first instance of the process. The listing will look similar to this: 121 ? SN 0:00 /usr/sbin/snmpd -c /etc/snmpd.conf 4. Restart the snmpd agent by issuing the following command: kill -s SIGHUP [snmpd_process_id] Where snmpd_process_id is the process ID of the snmpd process found in the step above. 17.3.
SNMP 3. Restart SNMP agent Method 2: Use the 'snmpusm' utility from a Redhat* Linux* host which has net-snmp packet install. You can find the usage under http://www.net-snmp.org. 17.4 SNMP Trap Utility The SNMP trap utility is utilized by the CMM Management software to send SNMP trap messages to a remote application regarding any abnormal system events. When enabled, the CMM will issue SNMP v1 traps on port 162. The CMM can also be configured to issue SNMP v3 traps.
SNMP 17.5.1 Configuring an SNMP Trap Address To configure an SNMP trap address, issue the command: cmmset -l cmm -d SNMPTrapAddressN -v [IP address] where N is the number of the trap address from 1 to 5 that is being set, and IP address is the IP address of the trap receiver. 17.5.2 Enabling and Disabling SNMP Traps SNMP Trap addresses are enabled by default.
SNMP 17.6 SNMP Security 17.6.1 SNMP v1 Security SNMP version 1 utilizes the community name for authentication. If the SNMP manager/client sends a request message containing the community name that doesn’t match the community name set in the SNMP Agent, the SNMP agent will respond with the authentication failure message. This community name is not encrypted during transmission. 17.6.
SNMP 17.8 Snmpd.conf File For more information regarding SNMP configuration and the snmpd.conf file, please visit: http://www.net-snmp.org/man/snmpd.conf.
CMM Scripting CMM Scripting 18.1 18 CLI Scripting In addition to calling the CLI directly, commands can easily be called through scripts using “bash” shell scripting. These scripts could be tailored to create a single command from several CLI commands or to give more detailed information. For example, you may want to display all of the fans and their speeds on the server. A script could be written that would first call the CLI to find out what fan trays are present.
CMM Scripting Script is the script file or executable in the /home/scripts directory to be run including parameters to be sent to the script. The script and parameters should be enclosed in quotes. The script parameter should not include the /home/scripts path. Note: If applicable, remember to set a script for when a sensor returns to normal (NormalAction). A script will not automatically stop running when a sensor returns to a normal setting (no alarms or events).
CMM Scripting 18.3.2 Setting Event Action Scripts Setting event action scripts can be done using any of the standard CMM interfaces (CLI, SNMP, RPC). The format for the CLI command is as follows: cmmset -l [location] -t [Sensor Name] -d EventAction -v [Event Code]:[script to be run] This setting gets written to the actionscripts.cfg file and is synced to the standby CMM. It is persistent across boots. 18.
CMM Scripting Table 79. CMM Status Sensor Data Bits Bit Bit Name Explanation Set when the Active/Standby election has taken place, and reset at a restart of the CMM.
CMM Scripting 18.4.3 CMMReadyTimeout Value The CMMReadyTimeout value is a 16 bit unsigned value signifying the number of seconds in which the CMM should become Ready after becoming Active. If the CMM takes longer than this amount of time, a CMM Ready timed out event will be asserted. This is a health related event. The CMMReadyTimeout value will be set and queryable from the CLI using the “CMM Status” target and CMMReadyTimeout data item.
CMM Scripting Figure 5. CMM Status State Diagram 18.5 FRU Control Script The CMM will check for a file in /home/scripts called frucontrol before it activates or deactivates any FRU. If that file does not exist, the CMM automatically activates or deactivates all FRUs. If it does exist, the CMM attempts to execute the program, and that is all.
CMM Scripting scripts/frucontrol file to do the proper activation or deactivation at some later point. The option for this script is useful for having a separate entity or system manager to be in charge of activating and deactivating FRUs instead of the CMM. Note: 18.5.1 The activation and deactivation of the CMM itself is not controlled by the frucontrol script.
CMM Scripting nor # its suppliers assumes any responsibility or liability for any errors or # inaccuracies that may appear herein. Except as expressly permitted by the # Software license, no part of the Software may be reproduced, stored in a # retrieval system, transmitted in any form, or distributed by any means without # the express written consent of Intel Corporation. # Command line arguments passed to this script # # $1 = IPMB address # $2 = FRU ID # $3 = Previous state (1 - M1, 2 - M2, ...
CMM Scripting *) echo Invalid device IPMB address >> /var/log/debug.log ;; esac # # ACTIVATION # date >> /var/log/frucontrol.log if [ "$4" = "2" ] ; then echo activating device $DEVICE >> /var/log/frucontrol.log while true do cmmset -l $DEVICE -d fruactivation -v 1 if [ $? -eq 0 ] ; then break fi done echo done activating device $DEVICE >> /var/log/frucontrol.log cmmget -l $DEVICE -d hotswapstate fi # # DEACTIVATION # if [ "$4" = "5" ] ; then echo deactivating device $DEVICE >> /var/log/frucontrol.
CMM Scripting break fi done echo done deactivating device $DEVICE >> /var/log/frucontrol.log fi date >> /var/log/frucontrol.
Remote Procedure Calls (RPC) Remote Procedure Calls (RPC) 19 The CMM can be administered by custom remote applications via remote procedure calls (RPC). RPCs provide all of the functionality of the CLI. RPC calls are useful for managing the CMM from: • An administrator’s machine via the house network • Another blade in the same chassis as the CMM, via the chassis backplane network • An application running on the CMM itself Note: 19.
Remote Procedure Calls (RPC) 19.2.1 GetAuthCapability() The following is the calling syntax for GetAuthCapability(): int GetAuthCapability( char* pszCMMHost, char* pszUserName, char* pszPassword ); Parameters pszCMMHost:[in] IP Address or hostname of CMM pszUserName:[in] A valid CMM user name pszPassword:[in] Password corresponding to pszUserName Return Value >0 Authentication successful. The return value is the authentication code. -1 Invalid username / password combination.
Remote Procedure Calls (RPC) Parameters pszCMMHost [in] IP Address or DNS hostname of CMM. nAuthCode[in] Authentication code returned by GetAuthCapability(). uCmdCode[in] The command to be executed (CMD_GET or CMD _SET as defined in cli_client.h). pszLocation[in] The location that contains the data item that uCmdCode acts upon, such as system, CMM, or blade1. pszTarget[in] The target that contains the attribute that uCmdCode acts upon, such as the sensor name as listed in the Sensor Data Record (SDR).
Remote Procedure Calls (RPC) Table 80. Error and Return Codes for the RPC Interface (Sheet 1 of 4) Code #: Error Code String Error Code Description 0 E_SUCCESS Success 1 E_BPM_BLADE_NOT_PRESENT Blade isn't in the chassis. E_ECMM_SVR_COMMAND_UNSUPPORTED ECMM_SVR: Unsupported Command Error. 3 E_CLI_MSG_SND CLI Send Message Error. 4 E_CLI_INVALID_TARGET Not a valid -t parameter. 5 E_CLI_INVALID_LOCATION Not a valid -l location. 6 E_CLI_INVALID_DATA_ITEM Not a valid -d parameter.
Remote Procedure Calls (RPC) Table 80. Error and Return Codes for the RPC Interface (Sheet 2 of 4) Code #: Error Code String Error Code Description E_IMB_COMPCODE_ERROR An IPMI request returned with a non successful completion code. User should try the command again. E_IMB_INVALID_PACKET Invalid IPMI response. Blade may be returning invalid data. E_IMB_INVALID_REQUEST Invalid IPMI response. Blade may be returning invalid data. E_IMB_RESPONSE_DATA_OVERFLOW Invalid IPMI response.
Remote Procedure Calls (RPC) Table 80. Error and Return Codes for the RPC Interface (Sheet 3 of 4) Code #: Error Code String Error Code Description 64 E_SFS_NO_MEMORY Internal CMM Error. 65 E_SFS_UNSUPPORTED_DEVICE Internal CMM Error. 66 E_SFS_RESPONSE_LENGTH Internal CMM Error. 67 E_SFS_RESPONSE_DATA Internal CMM Error. 68 E_SFS_POWER_SUPPLY_FRU Internal CMM Error. 69 E_SFS_PATTERN_FOUND Internal CMM Error. 70 E_SFS_SEMAPHORE_FAILED Internal CMM Error.
Remote Procedure Calls (RPC) Table 80. Error and Return Codes for the RPC Interface (Sheet 4 of 4) Code #: Error Code String 100 E_SNMP_CMD_UNSUPPORTED Internal CMM Error. 101 E_SNMP_ERROR Internal CMM Error. 102 E_SNSR_VALUE_OUT_OF_RANGE Internal CMM Error. 103 E_SNSR_AUTH_ERROR Internal CMM Error. 104 E_WP_INITIALIZE_LIBS Internal CMM Error. 105 E_WP_CFG_READ_ERROR CMM config file may be corrupted. 106 E_WP_CFG_WRITE_ERROR CMM config file may be corrupted.
Remote Procedure Calls (RPC) 19.2.3 ChassisManagementApi() Threshold Response Format The following table documents the format of ChassisManagementApi() queries that return data of type DATA_TYPE_ALL_THRESHOLDS. Table 81. Threshold Response Formats Dataitem Return format Data is returned in the THRESHOLDS_ALL structure as defined in cli_client.h. All structure fields are valid. thresholdsall If a particular threshold is not supported, the structure field will contain an empty string.
Remote Procedure Calls (RPC) Table 82. String Response Formats (Sheet 2 of 5) Dataitem Return Format Example List of human-readable health events. Lines are separated by linefeeds with a null-terminator at the end. "(null)” or "" if there are no healthevents healthevents Refer to Section 10, “Sensor Types” on page 101 Minor Event: +3.
Remote Procedure Calls (RPC) Table 82. String Response Formats (Sheet 3 of 5) Dataitem powerstate Return Format Example Human readable powerstate information containing the target blade powerstate information. Lines are separated by linefeeds with a null-terminator at the end. Board is present Syntax: Board has been powered up by the CMM Board is [present or not present] /n Board is in active mode. Board has [not] been powered up by the CMM /n Board is in [active or offline] mode.
Remote Procedure Calls (RPC) Table 82. String Response Formats (Sheet 4 of 5) Dataitem snmptrapversion Return Format Null-terminated string showing the version of SNMP traps the CMM is currently set for. Example v3 Syntax: [v1 or v3] /0 Human-readable unhealthy blade, cmm and/or chassis information, containing a list of blades, cmms and/or chassis with a health status of Critical, Major, and Minor. If there are no items in a particular category, "None” is reported.
Remote Procedure Calls (RPC) Table 82. String Response Formats (Sheet 5 of 5) Dataitem EscalationAction ProcessName OpState 19.2.5 Return Format Example "1:No Action", "2:Failover and Reboot" Used to set or query the process restart escalation action. This is only valid for a target of "PmsProc[#]. Where "#" is the unique number for the process. " " Used to query the process name and associated command line arguments for a monitored process.
Remote Procedure Calls (RPC) 19.2.6 FRU String Response Format Querying an individual FRU field returns a null terminated string with a single linefeed. Table 84. FRU Data Items String Response Format 186 Data Item Description all Null-terminated string containing all FRU information for the location. boardall Null-terminated string containing all board area FRU information for the location.
Remote Procedure Calls (RPC) 19.3 RPC Sample Code Sample code for interfacing with the CMM through RPC is available in the file cli_client.c. The sample code compiles into a command-line executable for use with Linux or a .o file for use with VxWorks. To select the appropriate target, remove the comment from the appropriate #define in the source code. The sample code first authenticates to the CMM through GetAuthCapability().
Remote Procedure Calls (RPC) Table 85. RPC Usage Examples (Sheet 2 of 3) Example ChassisManagementApi() [in] Parameters ChassisManagementApi() [out] Parameters uReturnType: DATA_TYPE_INT Get the overall system health. pszCMMHost: localhost ppvbuffer: Integer value denoting health state uCmdCode: CMD_GET 0 = OK pszLocation: system 1 = Minor pszDataItem: health 2 = Major 3 = Critical pszCMMHost: localhost Get a list of blades with problems.
Remote Procedure Calls (RPC) Table 85. RPC Usage Examples (Sheet 3 of 3) Example ChassisManagementApi() [in] Parameters ChassisManagementApi() [out] Parameters pszCMMHost: localhost uCmdCode: CMD_SET Reset a blade. pszLocation: blade[1-19] pszDataItem: powerstate uReturnType: not used ppvbuffer: not used The return code from ChassisManagementApi() indicates success or failure. pszSetData: reset Determine what sensors are on blade 3. Determine what may be queried or set on a blade.
RMCP 20 RMCP The RMCP (Remote Management Control Protocol) section of the Alert Standard Format Specification version 2.0 section 3.2.1 allocates two UDP ports for the RMCP server, ports 623 (the Primary RMCP port) and 664 (the Secondary RMCP or Secure port). This implementation of the RMCP server listens for the RMCP packet from the Ethernet interface on only on port 623. When the RMCP packet arrives, the RMCP server decodes the RMCP message.
RMCP 20.3 RMCP User Privilege Levels There are five privilege levels defined in the IPMI1.5 spec. 1. Callback level 2. User level 3. Operator level 4. Administrator level 5. OEM Proprietary level Callback Level has the most restricted privileges, and OEM Proprietary Level has the least restricted privilege. The RMCP server provides the user and password support associated with these five privilege levels. A user level requestor is not allowed to issue a request with a higher privilege level IPMI command.
RMCP returned by the Get Channel Authentication Capabilities command. The response packet will contain a challenge string and a Session ID. 3. The RMCP client activates the session by issuing an Activate Session request. The Activate Session packet is typically authenticated.
RMCP 20.7 IPMB Slave Addresses In the current RMCP server implementation in the BMC, embedded ‘IPMI message’ within a RMCP message is bundled with IPMB protocol. The ‘slave address’ required by this protocol should be set to 20h to address the BMC. The RMCP client may use any of the address shown in the range specified below as its slave Address. Only EVEN values are allowed. i.e., the least significant bit of the slave address is always ‘0’. Table 88. RMCP Slave Addresses 20.
RMCP 20.9 IPMI Commands Supported by CMM RMCP The following IPMI commands are supported via RMCP by the CMM. To configure privileges for the commands see Section 20.10, “Configuring IPMI Command Privileges” on page 196 below. Table 89. IPMI Commands Supported by CMM RMCP (Sheet 1 of 3) Command Type Defined In Command Get Device ID IPMI Device Global IPMI 1.
RMCP Table 89. IPMI Commands Supported by CMM RMCP (Sheet 2 of 3) Command Type Defined In Command Get Device SDR Info Get Device SDR Reserve Device SDR Repository Get Sensor Hysteresis Sensor Device Commands IPMI 1.5 Spec Get Sensor Threshold Get Sensor Event Enable Re-arm Sensor Events Get Sensor Event Status Get Sensor Reading Get FRU Inventory Area Info FRU Device Commands IPMI 1.
RMCP Table 89. IPMI Commands Supported by CMM RMCP (Sheet 3 of 3) Command Type Defined In Command Get PICMG Properties Get Address Info Get Shelf Address Info Set Shelf Address Info FRU Control Get FRU LED Properties Get LED Color Capabilities Set FRU LED State AdvancedTCA™ PICMG 3.0 Spec Get FRU LED State Set IPMB State Set FRU Activation Policy Get FRU Activation Policy Set FRU Activation Get Device Locator Record ID Get Port State Set Power Level Get Power Level 20.
RMCP [Net Function1..n]: TheIPMI Net Function in hex of the corresponding command. [Net Function Name 1..n]: The name used to identify its corresponding subsection. Y: The max number of commands defined in the subsection plus 1. [Command Bye 1..(Y-1)]: The command byte of the Net Function defined in this section.
RMCP Table 90. RMCP Message Completion Codes Code 198 Description 00 Success C0 Busy C1 Invalid Command C2 Command invalid for a given LUN C7 Request data length invalid C8 Requested data field length limit exceeded.
Command and Error Logging Command and Error Logging 21.1 21 Command Logging All CMMSET commands from all of the CMM interfaces (CLI, RPC, and SNMP) are logged by the CMM in the file /var/log/user.log. The size of the user.log file is 500 KBytes. When the command log becomes full, the log file is compressed and archived using gzip, then stored in / home/log. The filename format for the log files is user.log.N.gz, where N is the number of the log file from 1 to 4.
Command and Error Logging 21.3 Cmmdump Utility The cmmdump utility is a script that dumps the current system state of the CMM, the value of several configuration and log files, and the output of several cmmget commands. This utility is currently designed to be executed from a command prompt on the CMM. The output is sent to stdout and can be re-directed to a file to log the data. The purpose of cmmdump is to capture the debug information from the CMM system.
Application Hosting Application Hosting 22 The CMM allows applications to be hosted and run locally. This is useful as a method for adding small custom management utilities to the CMM. 22.1 System Details The CMM runs a customized version of embedded BlueCat* Linux* 4.0 on an Intel® 80321 with Intel® XScale® microarchitecture. Development support for BlueCat Linux is available on the web at: http://www.lynuxworks.com. 22.
Application Hosting 22.3.1.2 Flash Memory Map Below is the list of images on CMM flash with flash address ranges and the size of the images. Table 91. Flash #1 Image Name Flash Address Range Image Size Backup RedBoot image 0xF0000000 - 0xF003FFFF 256KB RedBoot image 0xF0040000 - 0xF007FFFF 256KB FPGA image 0xF0080000 - 0xF00BFFFF 256KB Backup FPGA image 0xF00C0000 - 0xF00FFFFF 256 KB OS image 0xF0100000 - 0xF0FFFFFF 153060KB Table 92.
Application Hosting 22.3.3 Interrupt Constraints User applications should not use interrupts. All interrupts are reserved for use by the CMM firmware. 22.4 RAM Disk Directory Structure The following directories are stored on a RAM-disk. These directories store information critical to the CMM and are size constrained. These directories should not be modified in any way. /usr – Executables including the CMM executables (/usr/local/cmm/bin). Also contains some libraries and temp files.
Updating CMM Software Updating CMM Software 23 When new CMM updates are available, they are packaged in a zip file and posted to the Intel developer web site located at: http://www.intel.com/design/network/products/cbp/atca/mpcmm0001.htm Please follow the instructions provided with the software update package to perform the update. The CMM is capable of having its firmware and critical system files updated when new update packages become available.
Updating CMM Software 23.3 Critical Software Update Files and Directories The following table is a list of files and directories important to the software update process. Table 95. List of Critical Software Update Files and Directories File or Directory Name: 23.4 Description: /usr/local/cmm/temp Mount point for ramdisk /usr/local/cmm/temp/update/package Directory into which the update package is copied and unzipped. The update process will delete and recreate this directory.
Updating CMM Software Table 96. Contents of the Update Package File Name Description CMM_RB.bin Redboot image to be stored in flash CMM_FPGA.bin FPGA image CMM_FFS.bin /etc image CMM_OS.bin OS image README Text file containing release notes for the update package Update_Metadata File containing info on the update package and how it should be installed on the CMM Utilities Sub-directory containing any utilities that might be required for the install.
Updating CMM Software 23.4.2 Update Firmware Package Version The firmware update package has a firmware version associated with the entire package. This firmware version is the same version that can be retrieved using the CLI command: cmmget -l cmm -d version To determine if the update is a new, old or same version, the update package will contain a version_history file which contains a list of all software builds that have occurred, listed in sequential order. Newer builds are at the bottom of the list.
Updating CMM Software Table 97. SaveList Items and Their Priorities File Note: 23.6 Priority /etc/passwd 1 /etc/shadow 1 /etc/cmm/sel_* 1 /etc/cmm/cmm_sel 1 /etc/snmp*.conf 1 /etc/ifcfg-eth* 1 /etc/HOSTNAME 1 /etc/ftp* 1 /etc/group 1 /etc/profile 1 /etc/versions* 1 /etc/issue 1 /etc/issue.net 1 /etc/pump.conf 1 /etc/*.cfg 2 /etc/cmm/sensors.ini 2 /etc/cmm/fantray.
Updating CMM Software 23.7 Update_Metadata File The Update_Metadata file included in the update package is used by the update process to determine the platform, firmware package version, files, sequence, update method, location, and any other data required to update the individual components in the update package. 23.8 Firmware Update Synchronization/Failover Support The following CMM versions and corresponding update directions will include support for heterogeneous synchronization.
Updating CMM Software even if the failover configuration flag is marked "manual", if any of the above condition is met, automatic failover may occur. 23.9.1 Setting Failover Configuration Flag To set the value of the failover configuration flag, the following CLI command can be used: cmmset -l cmm -d failoveronredundancy -v [manual/automatic] Where: Manual: Upon establishing redundancy between the two CMM’s, failover does NOT occur automatically to the CMM with the newer firmware version.
Updating CMM Software [overwrite] [ftp:server:user:password]” Where: Update Package path and filename - The path and file name of the update package file without the .zip or .md5 extension. For example: “usr/local/cmm/temp/CMM_P00.09f” force - Optional argument that causes all components to update regardless of version. This option cause the environment variable FORCE_UPDATE to be set to TRUE. overwrite - Optional argument that prevents data in the saveList from being preserved.
Updating CMM Software 23.13.2 Data Restore User Scripts The update process will also execute user scripts following the update of the new /etc file system to flash. The update process will execute any user scripts that match the following pattern: /home/ update/scripts/S*. Arguments will be passed that the scripts can use. These arguments are: arg1 = Update Component Name: ["BlueCat", "etc_jffs", "RedBoot", "fpga"] Note: For the user scripts, this argument will always be "etc_jffs".
Updating CMM Software direction=$2 if [ "$direction" = "forward" ] ; then cp /home/stagingarea/myScript.new /home/scripts/myScript elif [ "$direction" = "backward" ] ; then cp /home/stagingarea/myScript.old /home/scripts/myScript fi exit $? When the update process executes, and the Data Restore User Scripts are executed (during the update of the /etc partition), then the script S10updateMyScript will be executed and /home/script/ myScript will be updated accordingly.
Updating CMM Software — Exit if error occurs 7. Validate that .zip file matches checksum in .md5 file — Exit if no match 8. Unzip the .zip file in the package directory on ramdisk 9. Validate that all files in the unzipped package match the md5 checksum in the validationFile. — Exit if any files fail 10. Validate that the package matches the CMM platform ("cpci" or "atca") — Exit if mismatch 11. Transition to Update Mode — Call any user supplied scripts in /home/update/scripts/K* — A call to /etc/rc.
Updating CMM Software 23.15 Update Process Status and Logging During the update process, status is sent to stdout as it executes. Output will also be appended to the file /usr/local/cmm/temp/update/update.log. This file will be copied to /etc/cmm/update.log at the completion of the update process. Status output will be of the format: MM/DD/YY HH:MM:SS [process[pid]]: [Message String] 23.
Updating CMM Software 1. Extract the contents of the .zip file into a folder (e.g. "C:\CMM\") on the host PC. 2. Open a DOS Command Line Prompt on the Windows* PC and change directory to the above folder (e.g., C:\CMM). 3. To execute the update, execute the update_cmm.bat on the host with the following options: a. The MAC address of the connected interface on the CMM is the first command line parameter. To find this out, use the command ifconfig eth0 on the CMM CLI to find out the MAC address of eth0.
Updating Shelf Components Updating Shelf Components 24 Certain elements of the shelf that are managed with an IPM device can have their FRU information and firmware updated either locally or remotely through the CMM. Components on the shelf that can be updated include the CDMs, the fan trays, and the PEMs. The CMM can also be used to update firmware on blades in the chassis.
IPMI Pass-Through IPMI Pass-Through 25.1 25 Overview The IPMI Pass-through feature allows IPMI commands to be sent directly to any device in the chassis through the CMM without being processed by lower layers of the CMM software stack. This allows local or remote devices such as other SBCs in the platform to send unfiltered IPMI commands directly to other devices in the platform through the CMM. The command is available through any of the CMM interfaces (i.e.
IPMI Pass-Through The request string will only be validated for the format and ranges specified above. Any further validation of the command or data is left up to the receiver. If the range or format validation fails the error code of E_CLI_INVALID_SET_DATA will be returned. Note: 25.2.2 Please refer to the IPMI Specification for further details on IPMI commands and the values described above.
IPMI Pass-Through # snmpget […] […].cmmIPMICommandRequest […].cmmIPMICommandRequest=”” # snmpget […] […].cmmIPMICommandResponse […].cmmIPMICommandResponse=”” # snmpset […] […].cmmIPMICommandRequest s “6 1” OK # snmpget […] […].cmmIPMICommandRequest […].cmmIPMICommandRequest=”6 1” # snmpget […] […].cmmIPMICommandResponse […].
FRU Update Utility 26 FRU Update Utility 26.1 Overview This utility is intended to be used to update any FRU information in an AdvancedTCA* or CompactPCI chassis. It will be able to update functional system FRU information with a FRU provided in the update package; or it can be used to repair damaged FRU information. It can also view all FRU information in the chassis.
FRU Update Utility 26.3 FRU Update Process The FRU update process is controlled by the configuration file (not including forced FRU recovery). The configuration file is capable of querying the system and user for information. The configuration file can be modified to adjust how the FRU update proceeds. Because the update process is controlled by a user modifiable file, the utility will perform a three part update process to ensure a proper update is performed.
FRU Update Utility 26.5 FRU Verification FRUs will be verified twice during the update process, once before any action is taken on the FRU, and once more after all bytes have been written to the FRU. If the verification fails when first reading the FRU from the system, the FRU will not be modified, and the update process will exit. This first verification will not take place on a force FRU recovery.
FRU Update Utility Table 100. FruUpdate Utility Command Line Options Argument (Short Name) Parameter (Required/Optional) Description Update (u) Name of the configuration file to use for the update process. (Required) Specifies the update configuration file to use. ForceRecovery (fr) Name of the .FRU or .BIN file to use for the forced recovery process. (Required) Specifies the name of the FRU file to use for a forced recovery. This requires the ‘location’ switch to be supplied as well.
FRU Update Utility 26.10 Updating the FRU The “update” (u) switch is used to update a FRU. This argument requires a configuration file to be specified. The update will then be performed according to the contents of the configuration file. Example: LD_LIBRARY_PATH=. ./fruUpdate /u ChassisFruUpdate.cfg “FRU Update Configuration File” on page 227 describes the format of the configuration file and how to update FRU information using the configuration file. 26.
FRU Update Utility the maximum size of the FRU device and write the entire contents. The user must also specify a location to get using the ‘location’ switch. The contents of the FRU are not validated as they are read. Example: LD_LIBRARY_PATH=. ./fruUpdate /d output.
FRU Update Configuration File FRU Update Configuration File 27.1 27 Configuration File Format This section specifies the format for the configuration file used to assist in determining the configuration of the product. The configuration for a product consists of information about the product that can be used to select appropriate Field Replaceable Unit (FRU) information to be loaded into non-volatile storage areas.
FRU Update Configuration File • As the configuration file is parsed, on each line the correct number of quotes is checked and when incorrect, flagged as an error prior to checking for the correct number of arguments. • White space is defined as space, tab, and Carriage Return-Line Feed characters (CR-LF). 27.4 Numeric Constraints • All numbers are considered decimal unless denoted by the hexidecimal prefix string. • If as number starts with “0x”, then number is interpreted as hexidecimal. 27.
FRU Update Configuration File Additionally there is wild card support for numbers in a tag string. When the ‘#’ character is used in the tag string following an IFSET statement, it will match any number found in that position of any of the tags previously saved in the tag string link list. For example, when screening for various versions of a platform, you can use the following IFSET statement: IFSET 27.6.2 “MPCHC000#” ELSE The ELSE command has no parameters.
FRU Update Configuration File 27.6.5 CLEAR The CLEAR command removes a tag to the master list to be checked by IFSET commands. If the tag does not exist in the list, nothing happens. If multiple tags exist, all are deleted. Example: CLEAR 27.6.6 “tag” CFGNAME The CFGNAME command identifies a configuration file to insert at this point in the current file. The referenced configuration file is treated as an extension of the current configuration file at the location of command.
FRU Update Configuration File Table 101. Probe Command Parameters Probe Type 27.7.
FRU Update Configuration File 27.7.4 BMCVER Probing the BMC version is used to determine if a compatible version of firmware exist on the system. The version that is queried is the controller at IPMB address 0x20. The probe will get the BMC operational code version from the system and compare it to the list of versions that follow in the parameters. The BMC version is retrieved by an IPMI call, so the version is limited to the value that can be returned in the IPMI response message.
FRU Update Configuration File 27.8 Update Commands The configuration file allows the user to update the FRUs by specifying a target source file. And allow more customization of how the update should proceed with more commands. If the load utility fails at any of the updates, it should exit immediately and report the error. The update commands do not support path names; no error will be generated if a pathname exist. 27.8.
FRU Update Configuration File FRUFIELD “S#” “@STDIN:ASCII” 27.8.2 FRUADDRESS The FRUADDRESS command specifies an alternate address to program the FRU file to, by default the address in the file is used. If the SYSTEM FRU name is used, this is required by the user to correct outcome. Multiple FRUADDRESS commands are allowed for a FRUNAME command, but only the last FRUADDRESS command will be used. The FRUADDRESS command has three different addressing formats.
FRU Update Configuration File Table 102. FRU Area String Specifications FRU Area ASCII Strings “HEADER” “INTERNALUSE” “CHASSIS” “BOARD” “PRODUCT” “MULTIREC” The HEADER area is not selectable for writing; it is listed as an option to allow future use for comparisons. The internal use area is unique in that it has no fields, and can only be modified as a whole.
FRU Update Configuration File Table 103. Multi-Record Selection Parameters Parameter Number Parameter Value Description 1 APPEND, INSERT, REMOVE, REPLACE Operation to perform for the selected record. 2 "PICMG_ID", "RECORD_ID" Method to use for selecting the source and destination records. 3 Number Destination record ID to be selected. 4 Number Destination record count to be selected, 1 is the first record. 5 Number Source record ID to be selected.
FRU Update Configuration File Table 104. FRU Field First String Specifications FRU Field First ASCII String String Description “CT” Chassis Type (Chassis Area) The input string must represent a number. Regardless of the input type specified in the configuration file. This is because the chassis type field is an encoded value and is limited in range. The utility shall limit the input to the valid range and interpret the value correctly when decoding.
FRU Update Configuration File Table 105. FRU Field Maximum Allowed Lengths (Sheet 2 of 2) Chassis Part Number 17h bytes Chassis Serial Number 1Fh bytes Chassis Custom Fields (AMx) 1Fh bytes Product Asset Tag 1Fh bytes Whether entering information by way of STDIN, an environment variable, or from a file, if an input length of zero is entered, then the utility will treat it the same as an empty string.
FRU Update Configuration File Table 107 defines the valid types that can be used as the ‘TYPE’ option in FRU field 2nd string specifications. The load utility is not required to support all of these types. Table 107. Type Code Specification Type Description FRUSDR Version ASCII Straight 8 bit ASCII Ver 2.0 and later ASCII6 6 bit ASCII packed bytes Not supported BCD Binary Coded Decimal. Ver 2.0 and later. Support for BCD only exists when using Stdin and in the original FRU file.
FRU Update Configuration File 27.8.6 Input of Data When taking in data from a file, an environment variable or from standard in, the input type is always ASCII. If in the configuration file, the type is specified as something other than ASCII, then it will be read in as ASCII and converted to the correct type. The maximum number of characters accepted as input does not change based on the input type.
FRU Update Configuration File 27.9.1 DISPLAY The Display command displays a line of text to the user. If the text is more than one word, it must be encapsulated in double quotes. In order to display a CR-LF, you must use two separate DISPLAY commands. The text to display should be no longer than 80 ASCII characters to fit correctly on the screen, but the line to display can be of infinite length. In order to display a blank line, you must display a space enclosed in quotes (“ ”).
FRU Update Configuration File MENU “cpci” “Compact PCI” MENU “unknown” MENUPROMPT IFSET atca // do atca stuff ENDIF IFSET cpci // do cpci stuff ENDIF IFSET unknown // quit the update with an error ERRORLEVEL21 ENDIF 27.9.5 MENUTITLE The MENUTITLE command displays a line of text before displaying the options for the menu. This command is optional, and if this command is used it must immediately precede a MENU command. 27.9.
FRU Update Configuration File 27.9.8 YES The YES command requires that a PROMPT or NO command directly precedes it. It defines what tag is to be set when the user answers yes to the previous PROMPT. If preceded by a NO command, that NO command must be preceded by a PROMPT command. Example: 27.9.9 PROMPT “Is there a fan plugged into fan header #3?” YES “Fan3” NO “NO_Fan3” NO The NO command requires that a PROMPT or YES command directly precedes it.
FRU Update Configuration File Table 108. Command Quick Reference (Sheet 2 of 3) ELSE Processes and executes the commands between the ELSE and the matching ENDIF command if the matching IFSET command failed to find all the tags in the master tag list. ENDIF Indicates the end of the matching IFSET or ELSE command’s affect. ERRORLEVEL Exits the load utility when processed, exiting the application with the specified error code. Number Error level to exit the application with.
FRU Update Configuration File Table 108. Command Quick Reference (Sheet 3 of 3) FRUFIELD Specifies what field of the selected FRU area to modify and what or where the data is. ASCII String FRU field name, see Table 104, “FRU Field First String Specifications” on page 237. ASCII String Optional argument to indicate the FRU field input or where the input should be redirected from. If not specified, the input will come from the FRU file specified by FRUNAME. See Section 27.8.
FRU Update Configuration File Table 109 gives a brief overview of the various PROBE arguments and their expected inputs. All arguments in this table follow the PROBE command on the same line in the file. Table 109. Probe Arguments Quick Reference Probe Arguments Description BMCVER Format 1: 1+ arguments. Probes the system for the BMC operational code version and verifies that if falls within the range of versions supplied in the arguments.
FRU Update Configuration File IFSET SYS_CORRECT // Skip the else for the wrong system ELSE DISPLAY"Incorrect platform for FRU update" // This will exit the file ERRORLEVEL 14 ENDIF // ************************************************************************* // Validate the current version of the FRU is something we know about, if not // exit the update process with instructions on how to go from here.
FRU Update Configuration File DISPLAY "CDM FRU version is earlier than all known versions, no update can be performed.
FRU Update Configuration File FRUFIELD "ID" // replace the first picmg power distribution record FRUAREA "MULTIREC” REPLACE PICMG_ID 0x11 1 0x11 1 // remove the 2nd picmg power record FRUAREA "MULTIREC" REMOVE PICMG_ID 0x11 2 // replace the shelf power management record FRUAREA "MULTIREC" REPLACE PICMG_ID 0x12 1 0x12 1 // replace the shelf IP connection record FRUAREA "MULTIREC" REPLACE PICMG_ID 0x13 1 0x13 1 // remove the ipmb link entry record to the end of the records FRUAREA "MULTIREC” REMOVE PICMG_I
FRU Update Configuration File ERRORLEVEL 14 ENDIF // ************************************************************************* // Validate the current version of the FRU is something we know about, if not // exit the update process with instructions on how to go from here. // Later version than current update PROBE FRUVER "108+" FOUND FRUVER_LATER IFSET FRUVER_LATER DISPLAY "CDM FRU version is later than the version to update to, no update can be performed.
FRU Update Configuration File PROBE FRUVER "103" FOUND ALL_UPDATES PROBE FRUVER "104-105" FOUND IPMB_LINK_UPDATE // the update of the FRU to version 107 requires a power record update for versions 104 and later IFSET IPMB_LINK_UPDATE SET POWER_UPDATE ENDIF // To go from 106 to 107, we need to update the power distribution records PROBE FRUVER "106" FOUND POWER_UPDATE // Version 107 is the latest, no update required.
FRU Update Configuration File // replace the first picmig power distribution record FRUAREA "MULTIREC" REPLACE PICMG_ID 0x11 1 0x11 1 // append the new record after the first one FRUAREA "MULTIREC" APPEND PICMG_ID 0x11 1 0x11 2 // replace the shelf power management record FRUAREA "MULTIREC" REPLACE PICMG_ID 0x12 1 0x12 1 // replace the shelf IP connection record FRUAREA "MULTIREC" REPLACE PICMG_ID 0x13 1 0x13 1 // append the ipmb link entry record to the end of the records FRUAREA "MULTIREC” APPEND PICMG_I
Unrecognized Sensor Types Unrecognized Sensor Types 28.1 28 System Events Overview When a System Event is recorded in the CMM’s System Event Log (SEL), it contains 16 bytes. Below is an overview of the meaning of the bytes. For more information see Table 26-1 in the IPMI 1.5 specification. Record ID – (2 bytes) The record ID of the SEL record. Record Type – (1 byte) The type of the record. For 1.5 the values are 02h = System Event Record, C0h – DFh = OEM Timestamped, and E0h – FFh = OEM non-timestamped.
Unrecognized Sensor Types Event Data 2 and 3 – (2 bytes) Event data field contents which varies depending on how Event Data 1’s high nibble is set. The CMM uses the above 16 bytes of data from a SEL entry to produce human readable output. There are two general categories that an event can fall into: 1) data that the CMM code base recognizes, and 2) data that is unrecognized by the CMM. For unrecognized events the CMM does not have enough encoded knowledge to translate the event.
Unrecognized Sensor Types Raw Hex : [ 12 34 56 78 9A … (16 bytes hex) ] 28.3 SNMP Trap Raw Format SNMPTrapFormat, in the cmm.cfg file controls whether the “text” portion or the “raw” portion of a trap is sent along with the “header”. The header is always sent. If the SNMPTrapFormat variable is equal to 1 (text) the output is header plus text. The next figure shows what the output will look like. Figure 6.
Unrecognized Sensor Types 28.3.1 SNMP Trap Control To assist with backward compatibility a variable exists called SNMPSendUnrecognizedEvents. This controls whether the CMM should not send SNMP traps for unrecognized SEL events (a value of 0) or begin sending SNMP traps for unrecognized events (a value of 1). The default value is 0. Table 110.
Unrecognized Sensor Types provides the text interpretation of the event. Its format is shown below: \tSDRSensorName\tHealthEventString Where: • SDRSensorName is the name given to the sensor in the Sensor Data Record (SDR). • HealthEventString is the CMM’s translation of the event. 28.3.2.3 SEL Raw Format The final portion that SEL display might contain is the “raw” portion of the trap. This reports the original sixteen bytes of the System Event as ASCII, upper case, hex bytes.
Unrecognized Sensor Types 28.3.3.4 System Events – SEL Display Control In older firmware, the CMM always displays events for recognized events and never displays unrecognized events. To assist with backward compatibility a new configuration variable has been added, SELDisplayUnrecognizedEvents, that controls whether the CMM should continue with the old behavior (a value of 0) or begin displaying unrecognized events as well (a value of 1).
Warranty Information Warranty Information 29.
Warranty Information 29.3 For the Americas Return Material Authorization (RMA) credit requests e-mail address: requests.rma@intel.com Direct Return Authorization (DRA) repair requests e-mail address: uspss.repair@intel.com DRA on-line form: http://support.intel.com/support/motherboards/draform.htm Intel Business Link (IBL): http://www.intel.com/ibl Telephone No.: 1-800-INTEL4U or 480-554-4904 Office Hours: Monday - Friday 0700-1700 MST Winter / PST Summer 29.3.
Warranty Information If the Customer Support Group verifies that the product is defective, they will have the Direct Return Authorization/Return Material Authorization Department issue you a DRA/RMA number to place on the outer package of the product. Intel cannot accept any product without a DRA/RMA number on the package.
Customer Support Customer Support 30.1 30 Customer Support This chapter offers technical and sales assistance information for this product. Information on returning an Intel® NetStructure™ product for service is in the following chapter. 30.2 Technical Support and Return for Service Assistance For all product returns and support issues, please contact your Intel product distributor or Intel Sales Representative for specific information. 30.
Certifications Certifications 31 The Intel® NetStructureTM MPCMM0001 Chassis Management Module has the following approvals: • • • • • • • • UL/cUL 60950 EN/IEC 60950 EN55022 Class A EN55024 FCC CFR47 Part 15 Class A VCCI AS/NZS3548 BSMI MPCMM0001 Chassis Management Module Software Technical Product Specification 263
Agency Information Agency Information 32.1 32 North America (FCC Class A) FCC Verification Notice This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. For questions related to the EMC performance of this product, contact: Intel Corporation 5200 N.E.
Agency Information 32.3 Safety Instructions (English and French-translated below) 32.3.1 English CAUTION: This equipment is designed to permit the connection of the earthed conductor of the d.c. supply circuit to the earthing conductor at the equipment. See installation instructions.
Agency Information 32.4 Taiwan Class A Warning Statement 32.5 Japan VCCI Class A 32.6 Korean Class A 32.
Safety Warnings Safety Warnings Caution: 33 Review the following precautions to avoid personal injury and prevent damage to this product or products to which it is connected. To avoid potential hazards, use the product only as specified. Read all safety information provided in the component product user manuals and understand the precautions associated with safety symbols, written warnings, and cautions before accessing parts or locations within the unit. Save this document for future reference.
Safety Warnings Warning: Avoid electric shock: Do not operate in wet, damp, or condensing conditions. To avoid electric shock or fire hazard, do not operate this product with enclosure covers or panels removed. Warning: Avoid electric shock: For units with multiple power sources, disconnect all external power connections before servicing. Warning: Power supplies must be replaced by qualified service personnel only.
Safety Warnings Pour les systèmes C.A., utilisez uniquement un câble d'alimentation avec une prise de terre et établissez toujours les connexions à une prise secteur mise à la terre. Chaque câble d'alimentation doit être connecté à un circuit terminal dédié. Pour les systèmes C.C., la protection de cette unité repose sur les coupe-circuits (surintensité) du bâtiment.
Safety Warnings ventilateur ou les conduits de l'unité. Des boucliers ou des panneaux de gestion de l'air doivent être installés dans les connecteurs inutilisés du châssis. Les spécifications environnementales peuvent varier d'un produit à un autre. Veuillez-vous reporter au manuel de l'utilisateur pour déterminer les exigences en matière de flux d'air et d'autres spécifications environnementales. Avertissement : les dissipateurs de chaleur de l'appareil peuvent être chauds lors d'un fonctionnement normal.
Safety Warnings Das Gehäuse verfügt über einen eigenen Erdungs-Verbindungsbolzen. Stellen Sie die Erdungsverbindung her, ehe Sie das Stromkabel oder Peripheriegeräte anschließen, und trennen Sie die Erdungsverbindung niemals, so lange Strom- und Peripherieverbindungen angeschlossen sind. Um die Gefahr eines durch ein Telefon oder Ethernet*-System bedingten elektrischen Schlags zu verringern, schließen Sie das Stromkabel des Geräts an, ehe Sie diese Verbindungen einrichten.
Safety Warnings Vorsicht: Lithiumbatterien. Bei unsachgemäßem Austausch oder Umgang mit Batterien besteht Explosionsgefahr. Zerlegen Sie die Batterie nicht und laden Sie diese nicht wieder auf. Entsorgen Sie die Batterie nicht durch Verbrennen. Beim Auswechseln der Batterie muss dasselbe oder ein der Händlerempfehlung gleichwertiges Modell verwendet werden (CR2032). Gebrauchte Batterien müssen entsprechend den Anweisungen des Herstellers entsorgt werden.
Safety Warnings NORME DI SICUREZZA PER LE UNITÀ MONTATE IN UN RACK. Questa unità può essere alloggiata in modo permanente in un rack. Il montaggio in rack deve essere conforme ai requisiti di resistenza fisica delle norme NEBS GR-63-CORE e NEBS GR 487.Prima di installare o rimuovere l'unità da un rack, rimuovere tutte le fonti di alimentazione e i collegamenti esterni.
Safety Warnings 33.4 Instrucciones de Seguridad Examine las instrucciones sobre condiciones de seguridad que siguen para evitar cualquier tipo de daños personales, así como para evitar perjudicar el producto o productos a los que esté conectado. Para evitar riesgos potenciales, utilice el producto únicamente en la forma especificada.
Safety Warnings Advertencia: Evite sobrecargas eléctricas, calor y riesgos de descarga eléctrica o incendio: Conecte el sistema sólo a un circuito de alimentación que tenga el régimen apropiado, según lo especificado en el manual de usuario del producto. No realice conexiones con terminales cuya capacidad no se ajuste al régimen especificado para ellos. Consulte el manual de usuario del producto para que las conexiones que realice sean las correctas.
Safety Warnings 33.
Example CLI Commands Example CLI Commands A The following table shows examples of most CLI operations. Note: The variable “N” (as in bladeN or fantrayN) represents the chassis slot number of the device being acted on (such as Blade5 or fantray1). Please refer to chassis documentation for slot, fan, fan tray, and power supply location and information. Table 111. Example CLI Commands (Sheet 1 of 3) Use Case CLI Command Return Fantray1 is present. Get fan tray presence.
Example CLI Commands Table 111.
Example CLI Commands Table 111. Example CLI Commands (Sheet 3 of 3) Use Case CLI Command Return cmmset -l bladeN -d frucontrol -v [0-3] Where: Exercise control over the FRU payload 0 = Cold reset 1 = Warm reset Success or Failure 2 = Graceful reboot 3 = Issue diag.
Data Sheet Reference Data Sheet Reference B This appendix provides links to data sheets, standards, and specifications for the technology designed into the CMM. B.1 Intel® AdvancedTCA* Product Information Information, collateral, and software updates can be found for all Intel AdvancedTCA* products at: http://www.intel.com/technology/atca/index.htm B.2 AdvancedTCA* Current AdvancedTCA Specifications can be purchased from PICMG* for a nominal fee.
Customer Support Customer Support C This appendix offers technical and sales assistance information for this product as well as information on returning an Intel® NetStructureTM product for service. C.1 Technical Support and Return for Service Assistance For all product returns and support issues, please contact your Intel product distributor or Intel Sales Representative for specific information. C.
