®
Intel NetStructure™ ZT 7102
Chassis Management Module
Technical Product Specification
August 2004
Order Number: 273770-017
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
Contents
Introduction......................................................................................................................................13
Overview.............................................................................................................................13
ZT 7102 Features ...............................................................................................................13
Terms Used in This Document ...........................................................................................15
Hardware Specifications....................................................................................................................17
Overview.............................................................................................................................17
Backplane Connections......................................................................................................18
2.3.1 Slot Connections....................................................................................................18
2.3.2 Chassis Sensor Connections.................................................................................19
2.3.3 Chassis FRU Device Connections.........................................................................19
2.3.4 Redundancy...........................................................................................................19
Power Modules...................................................................................................................19
Fan Modules.......................................................................................................................19
Face Plate...........................................................................................................................20
2.6.1 Faceplate Features................................................................................................21
Mechanical..........................................................................................................................22
2.7.1 Board Dimensions and Weight ..............................................................................22
2.7.2 PCB Dimensions....................................................................................................22
2.8.1 J1 Backplane Connector........................................................................................24
2.8.2 J2 Backplane Connector........................................................................................24
2.8.3 J3 Backplane Connector........................................................................................25
2.8.4 Backplane Pin Descriptions...................................................................................26
2.8.5 JA1 Ethernet Port ..................................................................................................27
2.8.6 J6 Serial Port .........................................................................................................28
2.8.7 J7 Telco Alarm Connector .....................................................................................28
Electrical and Environmental ..............................................................................................29
2.9.1 CMM Power ...........................................................................................................29
2.9.2 Power Ramp Circuitry............................................................................................30
2.9.3 Operating Temperature .........................................................................................30
2.9.4 Reliability ...............................................................................................................30
2.9.5 Absolute Maximum Ratings...................................................................................30
2.9.6 DC Operating Characteristics ................................................................................31
2.10 Onboard Switches ..............................................................................................................31
2.10.1 Switch Descriptions ...............................................................................................32
2.10.1.1 S1 (Alarm Cutoff and Board Reset) .......................................................32
2.10.1.2 SW1-1 (Password Reset) ......................................................................32
2.11 Processor and Chipset .......................................................................................................32
2.12 Memory...............................................................................................................................33
2.12.1 Removing the SODIMM.........................................................................................33
2.12.2 Installing Memory...................................................................................................33
2.13 Flash...................................................................................................................................33
2.14 Dual Ethernet Controllers ...................................................................................................33
2.15 Serial I/O.............................................................................................................................33
Technical Product Specification
3
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
2.16 Telco Alarm Signal..............................................................................................................34
2.16.1 Alarm Relays .........................................................................................................34
2.16.2 Opto Inputs ............................................................................................................34
2.17 Real Time Clock .................................................................................................................34
2.18 Network Time Synchronization...........................................................................................34
2.19 Watchdog Timer .................................................................................................................35
2.20 Battery Backup ...................................................................................................................35
2.20.1 Replacing the Battery ............................................................................................35
2.21 Running Your System Without A CMM...............................................................................36
Software Specifications.....................................................................................................................37
Operating System...............................................................................................................37
Command Line Interface (CLI) ...........................................................................................37
SNMP/UDP.........................................................................................................................37
Remote Procedure Call (RPC) Interface ............................................................................37
Ethernet Interfaces .............................................................................................................37
Sensor Event Logs (SEL) ...................................................................................................38
3.6.1 CMM SEL Architecture ..........................................................................................38
3.6.2 Satellite Management Controller (SMC) Boards....................................................38
3.6.4 Retrieving a SEL....................................................................................................38
CMM Redundancy, Synchronization and Failover ................................................................................39
Overview.............................................................................................................................39
Hardware Redundancy Specification..................................................................................39
Synchronization ..................................................................................................................39
4.3.1 Synchronization Requirements..............................................................................40
CMM Failover .....................................................................................................................41
4.4.1 Scenarios That Force a Failover............................................................................41
4.4.2 Scenarios That Prevent Failover ...........................................................................41
4.4.3 Scenarios That Failover to a Healthier Standby CMM...........................................41
4.4.4 Scenarios That Failover to an Equally Healthy CMM ............................................42
4.4.5 Failover Timing ......................................................................................................42
4.4.6 Manual Failover .....................................................................................................42
CMM Installation and Removal ..........................................................................................................43
Unpacking...........................................................................................................................43
Connectivity ........................................................................................................................43
Installing the CMM..............................................................................................................43
Removing the CMM............................................................................................................44
Built-In Self Test...............................................................................................................................47
BIST Test Flow ...................................................................................................................47
Boot-BIST ...........................................................................................................................48
Early-BIST ..........................................................................................................................48
Mid-BIST.............................................................................................................................48
Late-BIST............................................................................................................................49
Event Log Area and Event Management............................................................................49
OS Flash Corruption Detection and Recovery Design .......................................................50
6.7.1 Monitoring the Static Images .................................................................................50
6.7.2 Monitoring the Dynamic Images ............................................................................50
4
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
6.7.3 CMM Failover ........................................................................................................50
BIST Test Descriptions.......................................................................................................51
6.8.1 Flash Checksum Test ............................................................................................51
6.8.2 Base Memory Test.................................................................................................51
6.8.3 Extended Memory Tests........................................................................................51
6.8.3.1 Walking Ones Test.................................................................................51
6.8.3.2 32-Bit Address Test ...............................................................................51
6.8.3.3 32-Bit Inverse Address Test...................................................................51
6.8.4 FPGA Version Check.............................................................................................52
6.8.5 DS1307 RTC Test .................................................................................................52
6.8.6 NIC Presence/Local PCI Bus Test.........................................................................52
6.8.7 OS Image Checksum Test.....................................................................................52
6.8.8 CRC32 Checksum .................................................................................................52
6.8.9 IPMB Bus Busy/Not Ready Test............................................................................52
CMM Connection and Setup..............................................................................................................53
CLI Overview ......................................................................................................................53
Connecting to the CLI.........................................................................................................53
7.2.1 Connecting through a Console ..............................................................................53
7.2.2 Telnet into the CMM ..............................................................................................53
7.2.3 FTP Into the CMM .................................................................................................54
Initial Setup - Logging in for the First Time.........................................................................54
7.3.1 Setting IP Address Properties................................................................................54
7.3.1.2 Setting Eth0 to DHCP ............................................................................55
7.3.2 Setting a Hostname ...............................................................................................56
7.3.3 Setting Auto-Logout Time Limit .............................................................................56
7.3.4 Rebooting the CMM...............................................................................................56
Command Line Interface (CLI) Syntax and Arguments..........................................................................57
cmmget and cmmset syntax...............................................................................................57
Help Parameter: -h .............................................................................................................57
Location Parameter: -l ........................................................................................................57
Target Parameter: -t ...........................................................................................................58
Dataitem Parameter: -d ......................................................................................................58
Value Parameter: -v............................................................................................................61
Generating a System Status Report...................................................................................62
Resetting the Password ....................................................................................................................63
Resetting the Password in a Single CMM System .............................................................63
Resetting the Password in a Dual CMM System................................................................63
10.0 Sensor Types...................................................................................................................................65
10.1 Threshold-Based Sensors ..................................................................................................65
10.1.1 Threshold-Based Sensor Events ...........................................................................65
10.2 Discrete Sensors ................................................................................................................65
10.2.1 Discrete Sensor Events .........................................................................................65
11.0 Health Event Strings .........................................................................................................................67
11.1 Syntax of Health Event Strings...........................................................................................67
Technical Product Specification
5
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
11.1.1 “healthevents” Query Event Syntax.......................................................................67
11.1.2 SEL Event Syntax..................................................................................................67
11.1.3 SNMP Trap Event Syntax......................................................................................68
11.2 Sensor Targets ...................................................................................................................68
11.3 Healthevents Queries .........................................................................................................69
11.3.1 HealthEvents Queries for Individual Sensors ........................................................69
11.3.2 HealthEvents Queries for All Sensors on a Location.............................................69
11.3.3 No Active Events ...................................................................................................69
11.3.4 Not Present or Non-IPMI Locations.......................................................................70
11.4 List of Possible Health Event Strings..................................................................................70
11.4.1 All Locations ..........................................................................................................71
11.4.3 CMM Location........................................................................................................72
11.4.4 Chassis Location ...................................................................................................73
12.0 Slot Power Control............................................................................................................................77
12.1 Difference between a Board’s HEALTHY# Signal and a Board’s Health ...........................77
12.2 Slot Power-Up Sequence ...................................................................................................77
12.2.1 Assertion of BD_SEL#...........................................................................................77
12.2.1.1 System Master Boards...........................................................................77
12.2.1.2 Peripheral Boards ..................................................................................77
12.2.1.3 Fabric and PCI-Less Slots .....................................................................78
12.2.1.4 Drone Mode Boards...............................................................................78
12.2.2 Assertion of HEALTHY# During Power-Up............................................................78
12.3 Obtaining the Power State of a Board ................................................................................78
12.4 Controlling the Power State of a Slot..................................................................................79
12.4.1 Powering Off a Board ............................................................................................79
12.4.2 Powering On a Board ............................................................................................79
12.4.3 Resetting a Board..................................................................................................79
12.5 Power Sequencing Commands and Policies......................................................................79
12.5.1 Retrieving the Healthy# Ramp-Up Time................................................................80
12.5.2 Setting the Healthy# Ramp-Up Time.....................................................................80
12.5.3 Retrieving the Maximum Power-Up Attempts........................................................80
12.5.4 Setting the Maximum Power-Up Attempts.............................................................80
12.5.5 Power Sequencing SEL Events.............................................................................81
13.0 Power Supplies................................................................................................................................83
13.1 Power Supply Detection .....................................................................................................83
13.2 Inhibit, Degrade, and Fail Signals.......................................................................................83
13.3 Inhibiting Power Supplies ...................................................................................................83
13.4 Precautions For Inhibiting Power Supplies.........................................................................83
13.5 Inhibiting Power Supplies ...................................................................................................84
13.6 Enabling Power Supplies....................................................................................................84
14.0 Drone Mode SBC Support.................................................................................................................85
14.0.1 Adding a Drone Mode Capable SBC.....................................................................85
14.0.2 Removing a Drone Mode Capable SBC................................................................85
15.0 Active vs. Offline Slots ......................................................................................................................87
15.1 Determining the State of a Slot...........................................................................................87
15.2 Setting a Slot to Offline Mode.............................................................................................87
6
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
15.3 Setting a Slot to Active Mode..............................................................................................87
15.4 Limitations of the Offline Mode ...........................................................................................87
16.0 Obtaining FRU Information ................................................................................................................89
16.1 FRU Information .................................................................................................................89
16.2 FRU Query Syntax..............................................................................................................89
16.3 Chassis FRU Validity Check...............................................................................................90
17.0 Fan Control and Monitoring ...............................................................................................................91
17.1 Setting Fan Speed..............................................................................................................91
17.1.1 Considerations for Turning Off the Fans................................................................91
17.2 Automatic Fan Control........................................................................................................91
17.3 Querying Fan Tray Sensors................................................................................................92
18.0 CMM Scripting .................................................................................................................................93
18.1 CLI Scripting .......................................................................................................................93
18.1.1 Script Synchronization ...........................................................................................93
18.2 Associating Scripts to Event Severity .................................................................................93
18.2.1 Listing Scripts Associated With Events..................................................................94
18.2.2 Removing Scripts From an Associated Event........................................................94
18.3 Setting Scripts for Specific Individual Events......................................................................94
18.3.1 Event Codes ..........................................................................................................94
18.4 Setting Event Scripts ..........................................................................................................95
18.5 Slot Events..........................................................................................................................95
19.0 SNMP .............................................................................................................................................97
19.1 CMM MIB............................................................................................................................98
19.2 MIB Design .........................................................................................................................98
19.2.1 CMM MIB Objects..................................................................................................98
19.3 SNMP Agent.......................................................................................................................98
19.3.1 Configuring the SNMP Agent Port .........................................................................99
19.3.3 Configuring the Agent Back to SNMP v1...............................................................99
19.3.4 Setting up an SNMP v3 MIB Browser....................................................................99
19.4 SNMP Trap Utility .............................................................................................................100
19.4.1 Configuring the SNMP Trap Port .........................................................................100
19.4.2 Configuring the CMM to Send SNMP v3 Traps ...................................................100
19.4.3 Configuring the CMM to Send SNMP v1 Traps ...................................................100
19.5 Configuring and Enabling SNMP Trap Addresses............................................................100
19.5.1 Configuring an SNMP Trap Address....................................................................100
19.5.2 Enabling and Disabling SNMP Traps...................................................................100
19.5.3 Alerts Using SNMPv3 ..........................................................................................101
19.5.4 Alert Using UDP Alert ..........................................................................................101
19.6 Security Model..................................................................................................................101
19.7 snmpd.conf .......................................................................................................................101
20.0 RPC..............................................................................................................................................103
20.1 Setting Up the RPC Interface ...........................................................................................103
20.2 Using the RPC Interface...................................................................................................103
Technical Product Specification
7
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
20.2.1 GetAuthCapability() .............................................................................................104
20.2.2 ChassisManagementApi() ...................................................................................104
20.2.6 FRU String Response Format .............................................................................114
20.3 RPC Sample Code ...........................................................................................................115
20.4 RPC Usage Examples......................................................................................................115
21.0 Command Logging .........................................................................................................................119
22.0 Telco Alarm Sensors ......................................................................................................................121
22.1 Configuring the Telco Alarm Connector Pins....................................................................121
22.2 Obtaining the Configuration of the Telco Alarm Sensor Connector Pins..........................121
22.3 Telco Alarm Connector Sensor Naming ...........................................................................121
22.3.1 Sensor Names using SNMP................................................................................122
22.4 Telco Alarm Sensors and Redundancy ............................................................................122
23.0 Application Hosting.........................................................................................................................123
23.1 System Details..................................................................................................................123
23.2 Startup and Shutdown Scripts ..........................................................................................123
23.3 System Resources Available to User Applications...........................................................123
23.3.1 File System Storage Constraints .........................................................................123
23.3.1.1 Flash Storage Locations ......................................................................123
23.3.1.2 RAM-Disk Storage Locations...............................................................124
23.3.2 RAM Constraints..................................................................................................124
23.3.3 Interrupt Constraints ............................................................................................124
23.4 Ram Disk Directory Structure ...........................................................................................124
24.0 Busless Backplane Support.............................................................................................................125
25.0 Updating Software..........................................................................................................................127
25.1 Key Features of the Firmware Update Process................................................................127
25.2 Update Process Architecture............................................................................................127
25.3 Critical Software Update Files and Directories .................................................................128
25.4 Update Package ...............................................................................................................128
25.4.1 Update Package File Validation...........................................................................129
25.4.2 Update Firmware Package Version.....................................................................129
25.4.3 Component Versioning ........................................................................................130
25.5 saveList and Data Preservation........................................................................................130
25.6 Update Mode ....................................................................................................................131
25.7 Update_Metadata File ......................................................................................................131
25.8 Synchronization ................................................................................................................132
25.8.1 Updating to a Newer Synchronization Version ....................................................132
25.8.2 Updating to an Older Synchronization Version....................................................132
25.8.3 Updating to the Same Synchronization Version ..................................................133
25.9 Single CMM System .........................................................................................................133
25.10 Redundant CMM Systems................................................................................................133
25.11 CLI Support.......................................................................................................................133
25.12 Hooks for User Scripts......................................................................................................134
25.12.1 Update Mode User Scripts...................................................................................134
8
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
25.12.2 Data Restore User Scripts. ..................................................................................134
25.12.3 Example Task - Replace /home/scripts/myScript with a newer version if updating for-
25.13 Update Process ................................................................................................................136
25.14 Update Process Status and Logging ................................................................................137
25.15 DEBUG_UPDATE Variable ..............................................................................................137
25.16 Update Process Sensor and SEL Events.........................................................................137
25.17 RedBoot Update Process .................................................................................................138
25.17.1 Required Setup....................................................................................................138
25.17.2 Update Procedure................................................................................................138
Example CLI Commands.................................................................................................................139
Datasheet Reference ......................................................................................................................141
Intel® CompactPCI* Product Information .........................................................................141
CompactPCI .....................................................................................................................141
IPMI ..................................................................................................................................141
Intel® IOP310 Processor Chipset .....................................................................................141
Warranty Information ......................................................................................................................143
Limited Warranty143
F.1.1 Returning a Defective Product (RMA)..................................................................143
F.1.2 For the Americas .................................................................................................143
F.1.3 For EMEA ............................................................................................................144
F.1.4 For APAC.............................................................................................................144
Customer Support ..........................................................................................................................147
G.2 Technical Support and Return for Service Assistance .....................................................147
G.3 Sales Assistance ..............................................................................................................147
Agency Approvals...........................................................................................................................149
H.1 CE Certification.................................................................................................................149
H.2 Safety................................................................................................................................149
H.3 Emissions Test Regulations .............................................................................................149
H.3.5 EN 50081-1 Emissions ........................................................................................149
H.3.6 EN 55024 Immunity .............................................................................................149
H.4 Regulatory Information .....................................................................................................150
H.4.7 FCC (USA)...........................................................................................................150
H.4.8 Industry Canada (Canada) ..................................................................................150
H.5 Product Safety Information ...............................................................................................150
Figures
Functional Block Diagram...........................................................................................................14
System Management Architecture..............................................................................................18
Face Plate...................................................................................................................................20
Backplane Connectors - Pin Locations.......................................................................................23
Ejector Handle Operation ...........................................................................................................44
Technical Product Specification
9
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
BIST Flow Chart .........................................................................................................................47
10 Timing of BIST Stages................................................................................................................49
11 High Level SNMP/MIB Layout....................................................................................................97
Tables
Glossary .....................................................................................................................................15
Faceplate Features.....................................................................................................................21
Board Dimensions and Weight ...................................................................................................22
Connector Assignments .............................................................................................................22
J1 Connector Pinout...................................................................................................................24
J2 Connector Pinout...................................................................................................................25
J3 Connector Pinout...................................................................................................................25
Pin Type Definitions....................................................................................................................26
Pin Descriptions..........................................................................................................................26
10 JA1 Ethernet Port Pinout............................................................................................................28
11 J6 Serial Port Pinout...................................................................................................................28
12 J7 Telco Alarm Connector Pinout...............................................................................................29
13 CMM Power Availability..............................................................................................................29
14 Absolute Maximum Ratings........................................................................................................30
15 DC Operating Characteristics.....................................................................................................31
16 Switch Cross Reference Table ...................................................................................................31
17 SW1-1 Functions........................................................................................................................32
18 Battery Characteristics ...............................................................................................................35
19 CMM Synchronization ................................................................................................................40
20 BIST Implementation..................................................................................................................48
21 Location (-l) Keywords................................................................................................................57
22 Target (-t) Keywords...................................................................................................................58
23 dataitem (-d) Keywords for All Locations....................................................................................58
24 dataitem (-d) Keywords for System location...............................................................................59
25 dataitem (-d) Keywords for BladeN Locations............................................................................59
26 dataitem (-d) Keywords for Chassis Location.............................................................................60
27 dataitem (-d) Keywords for CMM Location.................................................................................60
28 CMM Sensor Targets .................................................................................................................68
29 Threshold-Based Sensor Event Strings (Voltage, Temp, Current, Fan) ....................................71
30 Power Supply Event Strings (PowerSupplyN)............................................................................71
31 BIST Event Strings (BIST)..........................................................................................................72
32 Telco Alarm Sensor Event Strings (TASensor[1,2]) ...................................................................73
33 LAN Sensor Event Strings (Eth[0,1,1:1] Interface).....................................................................73
34 Fan Tray Presence Event Strings (Fan Tray [1-3] Presence) ....................................................73
35 Chassis Power Supply Event Strings (Pwr Supply N)................................................................73
36 Slot Event Strings (Slot N Event)................................................................................................74
37 CMM Redundancy Event Strings (CMM [1-2] Redundancy)......................................................74
38 CMM Failover Event Strings (CMM Failover).............................................................................74
39 CMM File Sync Event Strings (CMM File Sync) .........................................................................75
40 Chassis Sensor Event Strings....................................................................................................75
41 Dataitems Used With FRU Target (-t) to Obtain FRU Information .............................................89
42 MIB II Objects - System Group...................................................................................................98
43 MIB II - Interface Group..............................................................................................................98
44 SNMPv3 Security Fields...........................................................................................................101
45 Error and Return Codes for the RPC Interface.........................................................................106
10
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
46 Threshold Response Formats ..................................................................................................110
47 String Response Formats.........................................................................................................110
48 Integer Response Formats .......................................................................................................113
49 FRU Data Items String Response Format................................................................................114
50 RPC Usage Examples..............................................................................................................116
51 List of Critical Software Update Files and Directories...............................................................128
52 Contents of the Update Package..............................................................................................128
53 saveList Items and Their Priorities............................................................................................130
54 Synchronization Behavior for Differing Synch Versions ...........................................................132
55 Example CLI Commands..........................................................................................................139
Technical Product Specification
11
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructure™ ZT 7102 Chassis Management Module
Contents
Revision History
Date
Revision
Description
Changes related to V4.11h firmware
Added new BIST events for RTC and FRU checking.
Added new Chassis Slot event for IPMI capable
Added information on /etc/version checking
August 2004
017
Added infomation on chassis FRU validity checking.
Changes related to V4.11c firmware
Added rdate feature information
April 2004
016
015
March 2004
Changes related to V4.11b frimware verison
Changes related to V4.11a firmware version
Changes to Software Update section
Slotcontrol description
March 2004
014
Changes to Heatlh Event Strings
Changes related to V4.0x firmware version
New Password Reset Implementation
PSInhibit
October 2003
April 2003
010
005
Power Sequencing Policies
Updated Warranty and Customer Support information.
V3.00a Release
12
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Introduction
1.0
Introduction
1.1
Overview
The Intel® NetStructureTM ZT 7102 is a 3U, single-slot Chassis Management Module (CMM)
intended for use with PICMG* 2.1, 2.16, and 2.9-compliant systems (the CompactPCI* Hot Swap,
Packet Switching Backplane, and System Management specifications, respectively). This
document details the features and specifications of the ZT 7102.
The ZT 7102 plugs into a dedicated slot in compatible systems. It provides centralized
management and alarming for up to 21 node and/or fabric slots as well as for system power
supplies and fans. The ZT 7102 may be paired with a backup for use in high-availability
applications.
The ZT 7102 is a special purpose single board computer with its own CPU, memory, PCI bus,
operating system, and peripherals. The ZT 7102 monitors and configures Intelligent Platform
Management Interface (IPMI)-based components in the chassis. When thresholds such as
temperature and voltage are crossed or a failure occurs, the CMM captures these events, stores
them in an event log, sends SNMP traps, and drives the Telco alarm relays and alarm LEDs. The
CMM can query FRU information (such as serial number, model number, manufacture date, etc.),
detect presence of components (such as fan tray, CPU board, etc.), and perform health monitoring
of each component. In addition, the CMM controls the power-up sequencing of each node board
and the power to each slot via the BD_SEL# signal.
The ZT 7102 can also be used at a limited degree to manage non-IPMI based chassis components.
1.2
ZT 7102 Features
• High-density 3U X 1-slot form factor
• Compatible with PICMG* 2.1, 2.16, and 2.9-compliant chassis and components
• Monitors via the Intelligent Platform Management Bus (IPMB) protocol
• Provides isolated IPMB signals for each slot for maximum security and reliability
• Manage through the command line interface, SNMP v1/v3, or Remote Procedure Call (RPC)
• Hot-add/hot-swap support for IPMI-based, field-replaceable components
• µDB15 Telco Alarm Interface at the front panel
• Critical, Major, and Minor alarm LEDs at the front panel
• CMM status and hot swap LEDs at the front panel
• Monitors backplane voltages and status for up to eight power supplies
• Monitors system temperature sensors
• Monitors system fan tray presence
• Monitors tachometers for up to 16 system fans
• Monitors sensors on PICMG 2.9 compliant single board computers
• Power state control for single board compute blades
Technical Product Specification
13
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Introduction
1.3
Terms Used in This Document
Table 1. Glossary
Acronym
Description
CMM
CLI
Chassis Management Module
Command Line Interface
Field Replaceable Unit
FRU
IPMI
Intelligent Platform Management Interface
Intelligent Platform Management Bus
Management Information Base
RFC1213 - A standard Management Information Base for Network Management
System Event Log
IPMB
MIB
MIB II
SEL
SBC
Single Board Computer
SNMP
SNMP v.1
SNMP v.3
SDR
Simple Network Management Protocol
SNMP version 1
SNMP version 3
Sensor Data Record
Technical Product Specification
15
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Introduction
16
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.0
Hardware Specifications
2.1
Overview
The chassis management module (CMM) is intended to operate as a chassis management building
block in a CompactPCI chassis. The CMM uses a unique backplane interface pinout and requires a
dedicated slot within the chassis.
Caution: The ZT 7102 plugs into a dedicated chassis management slot. System components will be damaged
if a standard 3U board is plugged into the chassis management slot.
Intelligent Platform Management Buses (IPMBs) are the primary management connection between
components. A unique star topology radiating from the CMMs is used to provide reliability,
flexibility and security. In some cases, direct logic is used to support non-intelligent devices and to
eliminate active components on the backplane and chassis.
The CMM provides 30 master/slave two-wire serial bus (2WSB) interfaces. The 2WSBs are
electrically equivalent to I2C*. As such, all outputs are open drain, so they are driven low and
passively pulled high. The 2WSB interfaces support multi-master operation on the bus, however
they do not support being the target of a read transaction from another master device. The 2WSB
interfaces are used by the CMM as IPMBs or non-intelligent management busses. Refer to the
individual sections for specific usage information. The 2WSB interfaces are used for:
• Up to 21 general-purpose slots (21 independent 2WSBs, 2WSB_S0 - 2SB_S20)
• Power supplies (two buses, 2WSB_PS0 and 2WSB_PS1)
• Fan trays (one bus, 2WSB_FT)
• Chassis sensors (one bus, 2WSB_CS)
• Chassis FRU modules (two independent buses, 2WSB_CF0 and 2WSB_CF1)
• Redundant CMM link (one bus for bi-directional communication, 2WSB_RCMM)
Technical Product Specification
17
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.2
System Architecture
Figure 2. System Management Architecture
2.3
Backplane Connections
2.3.1
Slot Connections
The slots are connected to the CMM via an IPMB defined in the PICMG* 2.9 specification. The
CMM also has connections for BD_SEL# and HEALTHY# signals to each slot. Each slot has an
independent IPMB, BD_SEL#, and HEALTHY#. The CMM supports up to 21 general-purpose
node slots.
The IPMB is used for IPMI management communication between the CMM and the board in the
slot. Each board that is to be managed by the CMM is required to support the IPMB as a
management channel.
BD_SEL# is used in CompactPCI slots to control board power and to detect board presence. The
CMM provides a bi-directional open drain driver for each BD_SEL#. The board installed in the
slot provides a pull-up resistor (1.2 KΩ ± 5% per PICMG* 2.0). The CMM provides a weak
pulldown resistor (and a diode clamp). When not asserted, BD_SEL# can be read to determine if a
board is present in the slot. If BD_SEL# is high, a board is present. If BD_SEL# is not asserted a
board is not present. Asserting BD_SEL# allows the board to power up.
HEALTHY# is an input to the CMM. The CMM provides a pull-up resistor. The board in the slot
asserts HEALTHY# based on board power being good and optionally other board-specific
requirements. BD_SEL# must be asserted for HEALTHY# to be asserted. When BD_SEL# is
asserted, and a board is removed, HEALTHY# will be deasserted.
18
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.3.2
2.3.3
Chassis Sensor Connections
Chassis sensors are connected to the CMM via one two-wire serial bus.
Chassis FRU Device Connections
Chassis sensors are connected to the CMM via one two-wire serial bus. The CMM provides two
2WSB interfaces for chassis FRU modules. Each chassis FRU module is on a dedicated 2WSB in
order to provide redundant access to vital chassis information (e.g., the physical location of the
chassis). The backplane FRU storage device used MUST be an Atmel* AT24C16 or other
24C16-compatible device.
2.3.4
Redundancy
The CMM supports redundant operation with automatic failover under hardware or software
control. The following hardware interfaces exist for the support of redundancy and automatic
failover:
• Cross-connected CMM present inputs (PRES_I#) and outputs (PRES_O#)
• Cross-connected CMM healthy inputs (HLY_I#) and outputs (HLY_O#)
• Cross-connected negotiation inputs (NEG_I) and outputs (NEG_O)
The active CMM monitors its PRES_I# and HLY_I# inputs to determine if it has a healthy, standby
CMM. The active CMM deasserts its HLY_O# output to trigger a failover to the standby CMM.
The cross-connected negotiation signals are used to assure that only one CMM is active at a time.
At anytime, the standby CMM can trigger a failover by driving its NEG_O output low.
2.4
2.5
Power Modules
Power supply sleds are connected to the CMM via two IPMBs. Each power supply sled connects to
one IPMB. Multiple power supplies can share a single IPMB. The CMM also provides independent
DEG#, FAIL#, and INH# signals as defined in PICMG* 2.11 for up to eight power supplies. The
CMM will communicate with intelligent supplies via the IPMBs. Non-intelligent supplies are
supported via the DEG# (degrade), FAIL# (fail), and INH# (inhibit) signals.
The CMM uses INH# rather than EN# to control the power supplies. The EN# pin is grounded on
the backplane to signal to a power supply when it is fully seated in its connector.
Fan Modules
Fan trays are connected to the CMM via one two-wire serial bus (2WSB). Intelligent fan trays
communicate with the CMM via the IPMB. To support non-intelligent fan trays, the CMM also
provides independent fan tachometer inputs for up to 16 fans, fan tray present inputs for up to four
fan trays, and four fan speed outputs (four buffered copies of a single PWM). Non-intelligent fan
trays are monitored and controlled via the fan tachometer inputs and the fan speed output.
Technical Product Specification
19
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.6.1
Faceplate Features
The following features are found on the faceplate of the ZT 7102:
Table 2. Faceplate Features
Feature
Purpose
These LEDs indicate the presence of various event-triggered alarms.
The LEDs function as follows:
Minor, Major, and Critical Alarm
LEDs
Off = no alarm triggered.
Amber = alarm triggered.
Blinking = alarm cutoff (ACO) is activated.
This push button toggles the ACO state. When ACO is activated, the
active alarm LEDs blink and all of the alarm relays are deactivated. This
button does not clear alarms.
Alarm Cutoff (ACO) push button
The ZT 7102 can be reset by pressing and holding the ACO button for
about five seconds.
This interface relays alarm signals to off-board equipment. Contact Intel
“Customer Support.” for details.
Telco Alarm Interface (µDB15
connector)
This serial port may be used to access the CMM's Command Line
Interface (CLI).
COM Port (RJ-45 connector)
This port provides an out-of-band 10/100 Ethernet connection. The
port's integrated LEDs function as follows:
Yellow: Off = 10 Mbit
On = 100 Mbit
Ethernet Port (RJ-45 with LEDs)
Green: Off = No Link
On = Link
Blinking = Activity
This LED indicates CMM status as follows:
Green = power is on and the board is acting as the master (active)
CMM.
CMM Status LED
Blinking green = power is on and the board is acting as the backup
(standby) CMM.
Red = the CMM needs attention (a critical problem exists).
This LED indicates when it is safe to remove the CMM from a live
(powered-on) chassis. The LED functions as follows:
Hot Swap LED
Off = the CMM is not ready to be removed from a live chassis.
Blue = the CMM is ready to be removed from a live chassis.
The ejector functions as a handle and a lever for installing or removing
the CMM. The ejector incorporates a switch that tells the CMM when the
board is about to be removed from a system.
Ejector with hot swap switch
Technical Product Specification
21
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.7
Mechanical
2.7.1
Board Dimensions and Weight
In a compatible enclosure, the ZT 7102 occupies a single 3U CMM slot. Mechanical dimensions
Table 3. Board Dimensions and Weight
PCB Dimensions:
Board Dimensions:
Weight:
100 mm x 160 mm x 1.6 mm
3U x 4HP (one slot)
7.7 ounces w/ 128 Mbyte SODIMM
2.7.2
PCB Dimensions
Figure 4. PCB Dimensions
2.8
Connectors
devices. A brief description of each connector is given in Table 4 below. A detailed description and
pinout for the backplane connectors is given in the following sections.
Table 4. Connector Assignments
Connector
Function
J4
Backplane Connector (110-pin, 2 mm x 2 mm, female)
Backplane Connector (55-pin, 2 mm x 2 mm, female)
Backplane Connector (55-pin, 2 mm x 2 mm, female)
Connector reserved for test.
Ethernet Connector (RJ-45, 8-pin)
Serial Port (RJ-45, 8-pin)
22
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Table 4. Connector Assignments
Connector
Function
Telco Alarm Connector (uDB-15, 15-pin)
SODIMM Socket (144-pin)
Connector reserved for test.
J8,
J9
Figure 5. Connector Locations
Figure 6. Backplane Connectors - Pin Locations
Technical Product Specification
23
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.8.1
J1 Backplane Connector
J1 is a 110-contact, 2 mm x 2 mm female CompactPCI form-factor connector (AMP 352152-1).
for relative pin placement.
Table 5. J1 Connector Pinout
Pin#
22
A
B
C
D
E
F
PDEG0#
PDEG2#
PDEG3#
PFAIL2#
PFAIL3#
PINH2#
PINH3#
PS_SDA0
PS_SDA1
FT_SDA
CS_SDA
CF_SDA0
CF_SDA1
RES
GND
IPMB_PWR
GND
PDEG4#
PDEG5#
PFAIL4#
PFAIL5#
PINH4#
PDEG6#
PDEG7#
PFAIL6#
PFAIL7#
PINH6#
PINH7#
GA0
21
20
19
18
17
16
15
14
13
12
11
10
9
PDEG1#
PFAIL0#
PFAIL1#
PINH0#
PINH1#
PS_SCL0
PS_SCL1
FT_SCL
CS_SCL
CF_SCL0
CF_SCL1
RES
IPMB_PWR
GND
IPMB_PWR
GND
PINH5#
PRES_I#
FANP0#
FANP1#
FANPWM0
FANPWM1
FANTK0
FANTK1
FANTK2
FANTK3
FANTK4
FANTK5
FANTK6
FANTK7
BP_3.3V
RpTx+
RES
FANP2#
FANP3#
FANPWM2
FANPWM3
FANTK8
FANTK9
FANTK10
FANTK11
FANTK12
FANTK13
FANTK14
FANTK15
VIO
GND
RES
GND
GROUND
SHIELD
RES
GND
RES
RES
RES
8
STx
SRx
SRI
7
SCTS
SRTS
SCD
6
SDSR
SDTR
RES
5
RPMAC#
RPCR#
BP_5V
RPMIC#
RPMAR#
BP_N12V
SwTx-
RES
4
RPMIR#
BP_12V
GND
3
2
SwTx+
RpTx-
1
SwRx+
SwRx-
GND
RpRx+
RpRx-
NOTE: # Designates a low true signal. All signals interface to medium length pins on the backplane.
2.8.2
J2 Backplane Connector
J2 is a 55-contact, 2 mm x 2 mm female CompactPCI* form-factor connector (AMP* 352115-1).
24
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Table 6. J2 Connector Pinout
Pin#
A
B
C
D
E
F
11
10
9
N_SCL1
N_SCL2
N_SCL3
N_SCL4
N_SCL5
N_SCL6
N_SCL7
N_SCL8
N_SCL9
R_SCL
N_SDA1
N_SDA2
N_SDA3
N_SDA4
N_SDA5
N_SDA6
N_SDA7
N_SDA8
N_SDA9
IPMB_PWR
R_SDA
N_SCL10
N_SCL11
N_SCL12
N_SCL13
N_SCL14
N_SCL15
N_SCL16
N_SCL17
GND
N_SDA10
N_SDA11
N_SDA12
N_SDA13
N_SDA14
N_SDA15
N_SDA16
N_SDA17
NEG_O
N_SCL18
N_SDA18
N_SCL19
N_SDA19
N_SCL20
N_SDA20
N_SCL21
N_SDA21
HLY_O#
HLY_I#
8
7
GROUND
SHIELD
6
5
4
3
2
RES
IPMB_PWR
NEG_I
1
GND
CMM_SEL#
GND
NOTE: # Designates a low true signal.
All signals interface to medium length pins on the backplane except as noted.
= Interfaces to long connector pins on the backplane.
= Interfaces to short connector pins on the backplane.
2.8.3
J3 Backplane Connector
J3 is a 55-contact 2 mm x 2 mm female CompactPCI form-factor connector (AMP 352115-1). See
Table 7. J3 Connector Pinout
Pin#
11
A
B
C
D
E
F
N_HLY1#
N_BDS1#
N_BDS2#
N_BDS3#
N_BDS4#
N_BDS5#
N_BDS6#
N_BDS7#
N_BDS8#
N_BDS9#
GND
N_HLY10#
N_HLY11#
N_HLY12#
N_HLY13#
N_HLY14#
N_HLY15#
N_HLY16#
N_HLY17#
IPMB_PWR
RES
N_BDS10#
N_BDS11#
N_BDS12#
N_BDS13#
N_BDS14#
N_BDS15#
N_BDS16#
N_BDS17#
PIMP0#
N_HLY18#
N_BDS18#
N_HLY19#
N_BDS19#
N_HLY20#
N_BDS20#
N_HLY21#
N_BDS21#
RES
10
9
N_HLY2#
N_HLY3#
N_HLY4#
N_HLY5#
N_HLY6#
N_HLY7#
N_HLY8#
N_HLY9#
RES
8
7
GROUND
SHIELD
6
5
4
3
2
GND
RES
1
IPMB_PWR
RES
PRES_O#
PIMP1#
IPMB_PWR
NOTE: # Designates a low true signal.
All signals interface to medium length pins on the backplane except as noted.
= Interfaces to long connector pins on the backplane.
= Interfaces to short connector pins on the backplane.
Technical Product Specification
25
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.8.4
Backplane Pin Descriptions
Table 8. Pin Type Definitions
Pin Type
Definition
OD
I
Open Drain
Input
I/O
O
Input/Output
Output
Table 9. Pin Descriptions (Sheet 1 of 2)
Name
Count
Type
Description
N_SCL[1..21]
N_SDA[1..21]
PS_SCL[0..1]
PS_SDA[0..1]
FT_SCL
21
21
2
OD
OD
OD
OD
OD
OD
OD
OD
OD
OD
OD
OD
I
Node IPMI clock
Node IMPI data
Power Supply Chassis IMPI clock
Power Supply Chassis IMPI data
Fan Tray Chassis IMPI clock
Fan Tray Chassis IMPI data
Chassis Sensor IMPI clock
Chassis Sensor IMPI data
2
1
FT_SDA
1
CS_SCL
1
CS_SDA
1
CF_SCL[0..1]
CF_SDA[0..1]
R_SCL
2
Chassis FRU IMPI clock
2
Chassis FRU IMPI data
1
Redundant CMM serial clock
Redundant CMM serial data
Node Healthy (0 = Node is healthy)
R_SDA
1
N_HLY#[1..21]
21
OD
I/O
Node Board Select (5 V = Node is present, drive to 0
to turn node on)
N_BDS#[1..21]
21
SwTx(+/-)
SwRx(+/-)
FANTK[0..15]
FANPWM[0..3]
FANP#[0..3]
PDEG#[0..7]
PFAIL#[0..7]
PINH#[0..7]
STx
2
2
I/O
10/100 Ethernet To Switch
10/100 Ethernet From Switch
Fan Tach Inputs
I/O
I
16
4
O
I
Fan Speed Control (3.3 V = ON)
Fan tray present (3.3 V = fan tray is missing)
Power supply degrade
Power supply fail
4
8
I
8
I
8
O
O
I
Power supply inhibit
1
Serial transmit
SRx
1
Serial receive
SCTS
1
I
Serial clear to send
SRTS
1
O
I
Serial request to send
Serial data set ready
SDSR
1
26
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Table 9. Pin Descriptions (Sheet 2 of 2)
Name
Count
Type
Description
Serial data terminal ready
SDTR
SRI
1
1
1
2
2
1
1
1
1
1
1
1
O
I
Serial ring indicator
SCD
I
Serial carrier detect
RpTx(+-)
RpRx(+-)
NEG_O
NEG_I
I/O
I/O
O
I
10/100 Ethernet To rear panel
10/100 Ethernet From rear panel
Negotiate output to other CMM
Negotiate input from other CMM
Healthy output to other CMM
Healthy input from other CMM
Other CMM is present (0V)
Grounded on CMM.
HLY_O#
HLY_I#
PRES_I#
PRES_O#
GA0
O
I
I
O
I
Location Address
Tells CMM it has been seated. (Backplane grounds
this pin)
CMM_SEL#
1
I
GND
14
8
I
I
CMM GND
IPMB_PWR
CMM Power
BP_12V, BP_N12V,
BP_5V, and
4
I
Monitor backplane power 12,-12,5,3.3
BP_3.3V
RPMAC#
RPMIC#
RPCR#
1
1
1
1
1
I
Rear panel major alarm clear
Rear panel minor alarm clear
Rear panel critical alarm relay
Rear panel major alarm relay
Rear panel minor alarm relay
I
O
O
O
RPMAR#
RPMIR#
Backplane IO voltage (may not be present in non-PCI
system)
VIO
1
I
RES
18
NC
No Connect on Backplane
TOTAL
220
2.8.5
JA1 Ethernet Port
JA1 is an RJ-45 Ethernet port providing 10 Mbit (10BASE-T) and 100 Mbit (100BASE-TX)
protocols. JA1 connects to the CMM's LAN0 Ethernet channel. A second Ethernet channel, LAN1,
is only available at the backplane.
Two LEDs are located in the RJ-45 Ethernet connector:
• Yellow indicates speed
• Green indicates a link/activity
Technical Product Specification
27
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Table 10. JA1 Ethernet Port Pinout
Pin #
Description
1
2
3
TX+
TX-
RX+
4,5
6
Unused pair; terminated on ZT 7102
RX-
7
Unused pair; terminated on ZT 7102
2.8.6
J6 Serial Port
J6 is an RJ-45 connector providing a front-panel RS-232 serial port interface. Serial port signals are
Table 11. J6 Serial Port Pinout
Pin#
Function
SRTS
Description
1
Serial Request To Send
Serial Data Terminal Ready
Serial Transmit
2
3
4
5
6
7
8
-
SDTR
STx
GND
GND
SRx
Ground
Ground
Serial Receive
SDSR
SCTS
SRI
Serial Data Set Ready
Serial Clear to Send
Serial Ring Indicator (not utilized)
Serial Carrier Detect (not utilized)
-
SCD
2.8.7
J7 Telco Alarm Connector
alarm connector pin definitions. Contact Intel for information about obtaining a compatible
For additional information on the Telco Alarm Connector, refer to the Wiring Telco Alarm
Connectors Application Note posted at the following location:
28
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Table 12. J7 Telco Alarm Connector Pinout
Pin #
Function
AMIR+
Description
MinorReset +
1
2
AMIR-
MinorReset -
3
AMAR+
AMAR-
ACNO
MajorReset +
4
MajorReset -
5
CriticalAlarm - NO
CriticalAlarm - NC
CriticalAlarm - COM
MinorAlarm - NO
MinorAlarm - NC
MinorAlarm - COM
MajorAlarm - NO
MajorAlarm - NC
MajorAlarm - COM
PwrAlarm - NO
PwrAlarm - COM
Not Utilized
6
ACNC
7
ACCOM
AMINO
AMINC
AMINCOM
AMANO
AMANC
AMACOM
APRCO
APRCOM
GND
8
9
10
11
12
13
14
15
-
COM=Common
NO=Normally Open
NC=Normally Closed
2.9
Electrical and Environmental
The ZT 7102 requires +5 VDC ±5% @ 1.8 A typical. CMM power comes from the backplane's
IPMI_PWR rail; other voltages are derived as needed.
Caution: The processor core temperature must never exceed 100° C under any condition of ambient
temperature or usage. This may result in permanent damage to the processor.
2.9.1
CMM Power
voltages.
Table 13. CMM Power Availability
Voltage
Maximum Current
Where Used
5
100 mA
4 A
Miscellaneous components that cannot use 3.3 V.
3.3
2.5
1.5
80312 and most logic
FPGA core
700 mA
500 mA
80200 core
Technical Product Specification
29
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.9.2
Power Ramp Circuitry
The ZT 7102 features a power controller with power ramp circuitry to allow the board’s voltages to
be ramped in a controlled fashion. The power ramp circuitry eliminates large voltage or current
spikes caused by hot swapping boards. Controlled voltage ramping is a requirement of the
CompactPCI* Hot Swap Specification, PICMG* 2.1, Version 2.0.
Fault current sensing is also provided. When a board fault (short circuit) or overcurrent condition is
detected, the hot swap controller automatically removes power from the CMM components, and
protection activates when the current exceeds 10 A for longer than 10 ms.
2.9.3
Operating Temperature
The ZT 7102 processor can operate between +5° C and approximately +65° C ambient. It is the
users' responsibility to ensure that the ZT 7102 is installed in a chassis capable of supplying
adequate airflow. The maximum power dissipation of the processor is 15 W (10 W typical).
External airflow must be provided at all times.
Caution: The processor core temperature must never exceed 100° C under any condition of ambient
temperature or usage. This may result in permanent damage to the processor.
2.9.4
Reliability
MTBF: 479,000 hours at 40° Celsius
MTTR: Three minutes (based on hot-swap board replacement), plus system startup
2.9.5
Absolute Maximum Ratings
Note: These are stress ratings only. Do not operate the ZT 7102 at these maximums. See Section 2.9.6,
“DC Operating Characteristics” on page 31 for operating conditions.
Table 14. Absolute Maximum Ratings
Signal or Characteristic
Range
Supply Voltage, V
5 V ±5% with 50 mV maximum ripple
-40° to +85° Celsius
CC
Storage Temperature
Operating Temperature
+5° to +65° Celsius
Non-Condensing Relative Humidity
<95% at 40° Celsius
30
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.9.6
DC Operating Characteristics
Table 15. DC Operating Characteristics
Signal
Range
4.85 V minimum to 5.25 V maximum
Supply Voltage, V
CC
1.8 A average (with 733 MHz processor and 32 Mbyte of SDRAM. Peak
(short duration) power supply current may be significantly higher (up to
50%) and varies depending upon the application.
Supply Current, I
CC
2.10
Onboard Switches
The ZT 7102 contains a push-button switch on the faceplate and one bank of DIP switches on the
Note: Where switches are referenced in this chapter, “SWx” refers to the switch number and “-N” refers
to the switch segment (SW1-2 indicates “switch number 1, segment 2”).
Table 16. Switch Cross Reference Table
Switch
Function
Reset Password
Reserved
SW1-2
SW1-3
SW1-4
Reserved
Reserved
Figure 7. Default Switch Configuration
Technical Product Specification
31
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.10.1
Switch Descriptions
The following topics provide a detailed description of each switch.
2.10.1.1
S1 (Alarm Cutoff and Board Reset)
S1 is a push button at the faceplate of the ZT 7102. S1 toggles the CMM's alarm cutoff (ACO)
state. When ACO is activated, the active alarm LEDs blink and the alarm relays are deactivated.
This button does not clear alarms.
The Alarm Cutoff feature automatically cancels itself under the following conditions:
• When the ACO is engaged for more than 10 minutes without an active alarm present. This
prevents the ACO from being accidentally left engaged after an alarm is cleared).
• When the ACO is engaged for more than x minutes, even if an active alarm is present (x can be
set in the Command Line Interface with the Data item keyword AlarmTimeOut, see Table 23,
In addition to its ACO function, S1 is used to reset the CMM by pressing and holding the button for
about five seconds. Reset is discussed in more detail in Section 4.0, “CMM Redundancy,
2.10.1.2
SW1-1 (Password Reset)
Closing this switch resets the CMM's root logon password. Use this feature if you forget your
password or want to restore the default root password for other reasons. For more information
about resetting to the default root password, refer to Section 9.0, “Resetting the Password” on
Table 17. SW1-1 Functions
SW1-1
Function
Open [default]
Closed
Does not reset the CMM's root password at reboot.
Resets the CMM's root password at reboot.
2.11
Processor and Chipset
The Intel® IOP310 chipset contains two devices, the Intel® 80200 processor and the Intel® 80312
I/O companion chip. The 733 MHz 80200 processor features 32 Kbit data and instruction caches.
The 80312 companion chip provides a memory controller and a PCI interface for the CMM's
chipset.
The ZT 7102 uses the Intel® IOP310 I/O processor chipset. Based on Intel XScale®
microarchitecture, this chipset combines high performance processing with ultra-low power
consumption.
32
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.12
Memory
The ZT 7102 includes 128 Mbytes of SDRAM on a Small Outline Dual Inline Memory Module
(SODIMM). The SODIMM used is 16 Mbits x 72 PC133 unbuffered SDRAM with ECC on a
144-pin module.
2.12.1
Removing the SODIMM
The following instructions cover the mechanical aspects of removing the SODIMM from a
ZT 7102.
1. Take the necessary precautions to protect the ZT 7102 and the SODIMM from static discharge.
socket's location.
3. Press outward on the clips at either end of the SODIMM socket (press both clips at the same
time) until the module ejects from the slot and tilts upward.
4. Pull the SODIMM away from the socket.
2.12.2
Installing Memory
The following instructions cover the mechanical aspects of installing the SODIMM in a ZT 7102.
1. Take the necessary precautions to protect the ZT 7102 and the SODIMM from static discharge.
“Connector Assignments” on page 22 for the socket's location.
3. Align the notches on the ends of the module with the matching bumps on the latches and
gently push the module down until it clicks in place.
2.13
2.14
Flash
The ZT 7102 uses an on-board 64 Mbyte flash memory device.
Dual Ethernet Controllers
The ZT 7102 uses two Intel® 82559 Fast Ethernet Controllers. The 82559 consists of both the
Media Access Controller (MAC) and the physical layer (PHY) interface combined into a single
component solution.
The CMM provides an RJ-45 connector on the faceplate to connect to out-of-band 10/100 LAN0.
taken not to confuse the RJ-45 Ethernet port with the RJ-45 serial port that is next to it. (Note that
the Ethernet port has integrated speed and activity LEDs).
2.15
Serial I/O
The ZT 7102 provides an RS-232 compatible RJ-45 serial port connector on the faceplate. Serial
port signals are also available for rear panel access.
Technical Product Specification
33
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
2.16
Telco Alarm Signal
2.16.1
Alarm Relays
The ZT 7102’s alarm relay circuits are capable of carrying 60 VDC or 1 A, with a maximum rating
of 30 VAC.
2.16.2
Opto Inputs
The ZT 7102 accepts timed pulse inputs for clearing Minor and Major alarm states (there is no
reset for the Critical state). Reset is accomplished by asserting a voltage differential from 3.3 V to
48 V for between 200 and 300 ms. The acceptable voltage range is from 0 to 48 VDC continuous
(handles up to 60 VDC at a 50 percent duty cycle). The current drawn by a reset input should not
exceed 12 mA.
Caution: Do not apply more than 60 V (maximum) to any pin or combination of pins on the CMM's J7 Telco
Alarm connector.
2.17
Real Time Clock
A Dallas Semiconductor* DS1307 Serial Real-Time Clock allows the ZT 7102 to keep track of
time for accurate event logging. The DS1307 features 56 bytes of nonvolatile SRAM, a 100-year
calendar, and battery backup.
The Real-Time Clock keeps time in UTC only. If the time is set for a different time zone, as in the
example below, the difference will be automatically calculated giving the UTC equivalent. In this
example, the time will be set 8 hours ahead of the local time.
To set the real-time clock, enter the correct date and time in the following format:
setdate 'Thu Apr 01 09:04:29 PST 2004'
The above command would set the time and date to the following:
Thu Apr 1 17:04:29 UTC 2004
Note: The real-time clock should be set to current date and time out of the box.
2.18
Network Time Synchronization
The CMM supports the RFC 868 Time Protocol. This allows the CMM to be configured to retrieve
the date and time from a server over a TCP/IP network using the rdate command. To properly
configure time synchronization using the RFC 868 Time Protocol, follow the steps below.
Enable RFC 868 Time Protocol on a Linux/Unix Host (server):
• In general this depends upon the OS and version. Please consult your OS documentation.
• The easiest way to enable this service is to use the OS GUI to enable the "time" server. This is
part of inetd/xinetd.
34
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Enable RFC 868 Time Protocol on CMM (client):
1. Create file "/etc/rdate.cfg".
2. Edit file "/etc/rdate.cfg" with a valid host name or IP address of an enabled RFC 868 Time
Protocol server.
3. Reboot the CMM, and check the new date (use "date") to make sure it is identical to the RFC
868 Time Protocol server (use "busybox rdate -p <host name or IP>".
4. This file will only be preserved during upgrades to same or newer versions.
Note: Since rdate is executed during CMM boot, it is possible that on a chassis powerup the CMM may
not be able to sync up with a server if the network path to it is through the backplane Ethernet port.
For proper network time synchronization during CMM boot, the CMM should be able to contact
the time server through the front Ethernet port.
2.19
2.20
Watchdog Timer
The ZT 7102 uses a Maxim* MAX6374KA-T watchdog timer to supervise processor activity.
When the software fails to strobe the watchdog within a set period (once every second), the
watchdog alerts the CMM's Complex Programmable Logic Device (CPLD), which resets the CPU.
Battery Backup
The CMM contains a CR 1025 onboard battery to retain certain functions such as the real time
clock, even when no standby power to the board is present. If it becomes apparent that the time and
date no longer stay current, then the battery should be replaced. The battery should only be
replaced with a lithium CR 1025 or equivalent. After the battery is replaced, use the setdate
information on setting the time and date.
Note: Date and time are critical to the operation of the CMM because health events are stamped with this
information. Always ensure the date and time of the CMM are kept current.
2.20.1
Replacing the Battery
1. Slide the battery out from the battery retention clip.
2. Slide the new battery into the clip with the positive (+) side up. The metal arm of the retention
clip should rest on top of the positive side of the battery.
Table 18. Battery Characteristics
Characteristic
Description
Battery Voltage:
3 V
Battery Capacity:
30 mAh
Real-Time Clock Requirements:
300 uA typical, 500 uA maximum (Vbat = 3 V, Vcc = 0 V)
11.4 years typical/6.8 years minimum (not powered). When powered,
RTC takes its power from +5v, not battery.
Real-Time Clock Data Retention:
Electrochemical Construction:
Long-life lithium with solid-state polycarbon monofluoride cathode.
Technical Product Specification
35
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Hardware Specifications
Caution: The ZT 7102 contains a lithium battery. Do not disassemble or recharge the battery. Do not dispose
of the battery in fire. When the battery is replaced, the same type or an equivalent type
recommended by the manufacturer must be used. Used batteries must be disposed of according to
the manufacturer's instructions.
2.21
Running Your System Without A CMM
In CMM-based systems, the CMM controls power to the general-purpose slots in accordance with
the PICMG* 2.1 specification. PICMG* 2.1 defines the power control signals (BD_SEL#) as
pulled up on general-purpose boards. When the BD_SEL# signals are not asserted (grounded) by
external means, the general-purpose boards will not power up. Therefore, to operate a CMM-based
system without a CMM board, BD_SEL# must be grounded at each slot on the backplane.
Your system may have jumpers at each slot on the backplane to ground BD_SEL#. Inserting the
BD_SEL# jumper will allow the node slot to power up regardless of the CMM. Node slots with the
BD_SEL# jumper installed cannot be managed using the CMM. Refer to system-specific
documentation for more information about running the system with or without a CMM board.
36
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Software Specifications
3.0
Software Specifications
3.1
Operating System
®
The CMM runs a customized version of embedded BlueCat* Linux* 4.0 on an Intel 80200
processor with Intel XScale® technology. Development support for BlueCat Linux* is available on
3.2
3.3
Command Line Interface (CLI)
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 Telnet or the CMM's serial port. Using the CLI, users
can access information about the current state of the system including current sensor values,
threshold settings, recent events, and overall chassis health.
SNMP/UDP
The chassis management module supports both queries and traps on SNMP v1 or v3. The SNMP
version can be configured through the CLI interface. The default is for SNMP v1. A MIB for the
entire platform is included with the CMM.
Along with SNMP traps, the CMM sends UDP alerts to port 10000. The content of these UDP
alerts is the same as the SNMP traps.
3.4
3.5
Remote Procedure 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).
Ethernet Interfaces
Eth1 is the Ethernet port going to the backplane on the CMM. Eth1 should remain static at all
times. It is through this port that synchronization will be attempted initially. For synchronization to
occur on eth1, both Ethernet switches must be present in the chassis.
Eth1:1 is a an IP address used to connect to the active CMM at any time through the chassis
backplane and therefore should remain static. Eth1:1 is a static alias of eth1 defined in the
/etc/ifcfg-eth1 file as STATICIP2. Because this IP address is synced between the two CMMs, it
should only be changed on the active CMM. See Section 7.3.1, “Setting IP Address Properties” on
page 54 on how to set the eth1:1 IP address.
Eth0 is the Ethernet interface on the front of the CMM that can connect to an external or private
management network through a switch or through a crossover to the other CMM. This is used if no
Ethernet switches are available in the chassis. Eth0 can be set to static or DHCP.
Technical Product Specification
37
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Software Specifications
In a platform containing redundant CMMs, upon initial power up, both CMMs will have identical
IP addresses on all of their Ethernet interfaces. The standby CMM will automatically decrement its
IP address on Eth1 by 1 so that synchronization can occur; however, the user must change these IP
addresses upon initial login so that an address conflict does NOT occur and synchronization and
further information and instructions on changing the IP addresses. See Section 4.0, “CMM
Redundancy, Synchronization and Failover” on page 39 for further information regarding
synchronization, failover, and redundancy.
3.6
Sensor Event Logs (SEL)
The chassis management module utilizes a dual domain for hosting the sensor event logs (SEL) of
the chassis components and boards used in the platform. With the dual domain architecture, some
SEL files are stored locally on the CMM in /etc/cmm, and some SEL files are stored on the
individual blades.
For the CMM, backplane, and chassis components, the CMM stores the SELs locally on the CMM
in /etc/cmm.
3.6.1
3.6.2
CMM SEL Architecture
The SEL files stored locally on the CMM in /etc/cmm have a maximum size of 8 Kbytes. If a SEL
becomes full, the CMM will wrap the SEL to the beginning, and all previous SEL entries will be
cleared.
Satellite Management Controller (SMC) Boards
For a board inserted into the platform acting as a satellite management controller (SMC), the CMM
will also store the SEL file locally. Some SMC-based boards may also contain their own SEL.
Health events generated from SMC-based boards will be stored in the SEL on the CMM as well as
on the SMC board if a SEL exists. When the command is issued to get the SEL from an
SMC-based board, the CMM will always retrieve the SEL file stored locally on the CMM in
/etc/cmm.
3.6.3
3.6.4
Baseboard Management Controller (BMC) Boards
For boards inserted into the system acting as a baseboard management controller (BMC), the SEL
file will be stored on that particular board. All health events will be logged in the SEL on that
board. When the command is issued to get the SEL from the board, the CMM will retrieve the
entire SEL via IPMB from that board.
Retrieving a SEL
The CLI can be used to retrieve the SEL for a location. To retrieve the SEL for a particular
location, issue the following get command:
cmmget -l [location] -d SEL
Where location is the component you wish to retrieve the SEL for (cmm, chassis, bladeN).
38
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Redundancy, Synchronization and Failover
4.0
CMM Redundancy, Synchronization and
Failover
4.1
Overview
The CMM supports redundant operation with automatic failover in chassis using redundant CMM
slots. In systems where two CMMs are present, one acts as the active chassis manager and the other
as standby. Both CMMs monitor each other, and either can trigger a failover if necessary.
Data is always synchronized from the active CMM to the standby CMM whenever any changes
occur. Existing data on the standby CMM is overwritten. A full synchronization between the active
and standby CMM occurs on initial power up or insertion of a new CMM. See Table 19, “CMM
Synchronization” on page 40 for a list of data items that are synchronized between the active and
standby CMM.
4.2
Hardware Redundancy Specification
The following hardware interfaces exist for the support of redundancy and automatic failover:
• Cross-connected CMM present inputs (PRES_I#) and outputs (PRES_O#)
• Cross-connected CMM health inputs (HLY_I#) and outputs (HLY_O#)
• Cross-connected negotiation inputs (NEG_I) and outputs (NEG_O)
The active CMM monitors its PRES_I# and HLY_I# inputs to determine if it has a healthy standby
CMM. The active CMM deasserts its HLY_O# output to trigger a failover to the standby CMM.
The cross-connected negotiation signals are used to assure that only one CMM is active at a time.
At any time, the standby CMM can trigger a failover by driving its NEG_O output low.
4.3
Synchronization
To ensure data on the standby CMM matches the data on the active CMM, the active CMM
synchronizes its data with the standby CMM, overwriting any existing data on the standby CMM.
The CMMs will initially fully synchronize data from the active to the standby CMM approximately
30 seconds after the CMMs boot (which can take up to 2 minutes total for both CMM boot and
synchronization). An insertion of a new CMM will also cause a full synchronization from the
active to the newly inserted standby, which also takes 2 minutes. Partial synchronization will also
occur any time files are modified or touched via the Linux* “touch” command. Date and time are
synched every hour.
Note: During synchronization, the LEDs on the standby CMM may blink on and off as the healthevents
that were logged in the SEL are synchronized.
The following items are synchronized between CMMs. During a full synchronization, all of these
files and data are synchronized. A change to any of these files results in that file being synched.
The active CMM overwrites these files on the standby CMM.
Technical Product Specification
39
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Redundancy, Synchronization and Failover
Table 19. CMM Synchronization
File(s) or data
Description
CMM’s main configuration file
Path:
Ethernet
/etc/cmm.cfg
/etc/passwd
Password file
Password file
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
IPMB
/etc/shadow
/etc/cmm/sel_*
All SEL files except the CMM SEL files
All SDR Files
/etc/cmm/*.bin
/etc/cmm/*.sif
All SIF Files
/etc/cmm/DroneList.cfg
/etc/cmm/PWMMap.cfg
/etc/cmm/SlotLayout.cfg
/etc/var/snmpd.conf
/etc/snmpd.conf
/home/scripts
Drone mode compatible forms
PWM Fanspeed Mapping
Chassis slot layout configuration
SNMP configuration files
SNMP configuration files
Entire user scripts area
date and time
Date and time
IP Address Settings
Blade power states
Power Supply Inhibit States
CMM eth1, eth1:1, and eth0 IP address settings
Status of blade power states
Status of power supplies that are inhibited by the CMM
IPMB
IPMB
IPMB
Warning: The /.rhosts file is used for synchronization and should NEVER be modified.
4.3.1
Synchronization Requirements
For synchronization to occur:
• The CMMs must be able to communicate with each other over their dedicated IPMB. The
CMMs use a heartbeat via their dedicated IPMB to determine if they can communicate with
each other over IPMB.
• An Ethernet connection must exist between the two CMMs. The CMMs must be able to ping
each other via Ethernet for synchronization to be successful. This can be a connection through
the Ethernet switches in the chassis, which requires both switches to be present in the chassis.
A connection can occur through an external Ethernet switch connected to the front ports of the
CMM pair, or alternatively, the connection can be a crossover cable connecting the two front
ports of the CMM pair. If synchronization fails on Eth1, it will be attempted on Eth0. If the
CMMs cannot successfully ping each other via Eth0 or Eth1, synchronization cannot occur.
A failure of synchronization to occur will result in a health event being logged in the chassis SEL,
however this will not inhibit a failover from occurring.
40
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Redundancy, Synchronization and Failover
4.4
CMM Failover
Once information is synchronized between the redundant CMMs, the active CMM will constantly
monitor its own health as well as the health of the standby CMM. In the event of one of the
scenarios listed in the sections that follow, the active CMM will automatically fail over to the
standby CMM so that no management functionality is lost at any time.
4.4.1
Scenarios That Force a Failover
The following scenarios cause a failover as long as the standby CMM is operational:
• The active CMM is pulled out of the chassis.
• The active CMM’s HEALTHY# signal is deasserted.
• A reboot command is issued to the active CMM.
• The front panel reset button on the active CMM is pushed in for more than five seconds.
• The internal synchronization code version of the active CMM is less than that of the standby
CMM.
4.4.2
Scenarios That Prevent Failover
The following are reasons a failover cannot occur:
• The active CMM cannot communicate with the standby CMM via their IPMB bus.
• Not all data has been completely synchronized between the CMMs.
To determine the active CMM, use the CLI command:
cmmget –d redundancy
Eth1:1 will always point to the active CMM, which will allow you to access the active CMM
through the chassis at all times.
4.4.3
Scenarios That Failover to a Healthier Standby CMM
The scenarios listed below can only cause a failover if the standby CMM is in a healthier state than
the active CMM. The health of the CMM is determined by computing a CMM health score, which
is equal to the sum of the weights of the following active conditions. A CMM health score is
determined for each CMM whenever any of these conditions occur on the active CMM. The CMM
health score is composed of the sum of the weights of any of the three conditions listed below. Each
condition has a default weight of 1 assigned to it, causing all conditions to have equal importance
in causing failover.
To determine if a failover is necessary when one of these conditions occurs, the active CMM
computes its CMM health score, and requests the health score of the standby CMM. If the score of
the standby CMM is LESS than the score of the active CMM, a failover will occur. If a failover
does not occur, the Chassis SEL will contain an entry indicating the reason failover did not occur.
1. SNMPTrapAddress1 ping failure:
A condition is asserted and a health score is computed if the active CMM cannot ping its first
SNMP trap address as defined in the SNMPTrapAddress1 setting. Only a ping failure of the
first SNMP trap address (SNMPTrapAddress1) can cause the condition to assert.
SNMPtrapaddress2 through SNMPtrapaddress5 do not perform this ping test.
Technical Product Specification
41
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Redundancy, Synchronization and Failover
Note: The frequency of the ping to the first trap address can vary from one second to approximately 20
seconds.
2. Unhealthy Ethernet Switch:
A condition is asserted and a health score is computed if the active CMM’s corresponding
Ethernet switch is not healthy or not present. The switch health is determined by the state of
the HEALTHY# hardware signal coming from the Ethernet switch. Refer to the chassis
specification to see which switch corresponds to the CMM. If both CMMs have unhealthy
switches or are not present in the chassis, then a failover can still occur based on other failover
conditions depending on the CMM health scores.
3. Critical events on the active CMM:
A condition occurs if the active CMM has critical events for any of the CMM sensors (not
chassis or blade sensors). Critical events are events associated with crossing an upper or lower
nonrecoverable threshold of a sensor. If both CMMs have critical CMM events, then the
number of major and minor CMM events is examined to decide if a failover should occur. The
number of major events is compared, and if they are equal, the number of minor events is used.
4.4.4
4.4.5
Scenarios That Failover to an Equally Healthy CMM
The following conditions will cause a failover only if the health score of the standby CMM is equal
to that of the active CMM:
1. The ejector latch on the active CMM is opened.
2. A manual failover is executed on the active CMM.
Failover Timing
Times required to detect different possible failover conditions and perform data synchronization
vary. For example, detecting network connection loss can take up to approximately 20 seconds.
Complete synchronization typically takes 7 to 30 seconds to occur, assuming both CMMs are fully
booted and a healthy Ethernet network connection and IPMB connection exist between the two
CMMs). Synchronization with a newly inserted CMM can take two minutes, since a newly inserted
CMM needs that time to boot and initialize.
Once the CMM data is initially synchronized, failover happens instantaneously at the hardware
level. However, the CMM software requires some time to initialize various components following
a failover. Software-based remote management applications accessing the CMM will need to
reconnect to the newly active CMM. The newly active CMM may respond with unexpected errors
while initializing.
4.4.6
Manual Failover
The following command can be issued to the active CMM to cause a failover manually to the
standby CMM:
cmmset -l cmm -d failover -v 1
A manual failover can only be initiated on the active CMM. A failover will only occur if the
standby CMM is at least as healthy as the active CMM. Once the command executes, the former
standby CMM immediately becomes the active CMM.
If the failover could not occur, the CLI will indicate the reason why the failover could not occur,
and a SEL event will be recorded.
42
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Installation and Removal
5.0
CMM Installation and Removal
This chapter describes the steps necessary to install and set up the ZT 7102 Chassis Management
Module (CMM). It includes instructions on unpacking, installing, and removing the CMM. Some
systems may come with the CMM(s) already installed.
Caution: The ZT 7102 plugs into a dedicated chassis management slot. System components will be damaged
if a standard 3U board is plugged into the chassis management slot.
5.1
Unpacking
Check the shipping carton for damage. If the shipping carton and contents are damaged, notify
Intel Customer Support. Retain the shipping carton and packing material for inspection by the
Support” for assistance information.
Caution: This board must be protected from static discharge and physical shock. Never remove any of the
socketed parts except at a static-free workstation. Use the anti-static bag shipped with the product
to handle the board. Wear a wrist strap grounded through one of the system's ESD Ground jacks
when servicing system components.
5.2
Connectivity
The ZT 7102 is intended to be installed as the CMM in a system's Chassis Management Slot.
Where two Chassis Management Slots are available in a system, two CMMs may be installed.
(They will automatically negotiate for active and standby roles.)
The ZT 7102 is designed to operate in a backplane providing CompactPCI-style 2 mm hard metric
connectors to the board's J1, J2, and J3 backplane interfaces. The backplane's CMM interfaces are
specific to the CMM and do not support other 3U CompactPCI boards. See Section 2.8,
“Connectors” on page 22 for connector descriptions and pinouts.
5.3
Installing the CMM
The following instructions cover the mechanical aspects of installing the ZT 7102 CMM in a
compatible system. For a better understanding of what happens when a CMM is absent from a
Warning: When the system is plugged in, high voltages are present on the backplane. Do not reach into the
enclosure.
Warning: Static electricity can damage electronic components. Wear a wrist strap grounded through one of
the system's ESD ground jacks when servicing system components.
1. Take the necessary precautions to protect the ZT 7102 from static discharge. System power
does not need to be off to install a CMM board.
2. Locate the system's dedicated CMM slot and remove the filler panel or existing CMM (see
Section 5.4 for removal instructions).
Technical Product Specification
43
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Installation and Removal
4. Carefully align the edges of the board with the card guides in the CMM slot. It may be helpful
to look into the enclosure to verify correct alignment of the rails in the guides.
5. Taking care to keep the board aligned in the guides, slide the board in until the injector/ejector
mechanism engages the retention bar.
6. Simultaneously push in the board and rotate the ejector handle to its closed position (rotate
inward) to seat the backplane connectors.
7. If system power is on, the CMM will boot and its Status LED will light green (active CMM) or
blink green (standby CMM).
8. Screw in the board retention screw to anchor the board in the chassis. This screw is located at
the opposite end of the faceplate from the ejector handle. Refer to Figure 3, “Face Plate” on
page 20 for the screw's location.
9. Use the CMM's Command Line Interface (CLI) to configure the CMM.
Figure 8. Ejector Handle Operation
5.4
Removing the CMM
Note: The CMM should only be removed when the blue hot swap LED is lit.
In CMM-based systems, the CMM controls power to every slot in the system via BD_SEL#. If a
system's only CMM is removed, all the boards in the system lose power. When hot swapping a
CMM, it performs a controlled shutdown of itself but not the other boards in the system. Therefore,
you should ensure that the entire system is in a “safe” state before removing the CMM. The CMM's
hot swap LED will not light while other boards in the system are powered on.
If a redundant CMM is available, the CMM being removed automatically fails over to the standby
CMM if it is active when the ejector latch is opened. If the active CMM is being removed, the
CMM status light will begin to blink indicating that a failover has occurred. The other CMM’s
status light will be solid green. If a failover does not occur, check the Chassis SEL to see why a
failover cannot occur. In a redundant system, the CMM's removal does not cause a loss of system
power or an interruption in service (you must still wait for the blue hot swap LED to light before
removing the CMM).
If the CMM loses power or is removed suddenly, the CMM's flash memory could become
corrupted. If this happens, restore the board to operation using the instructions in “Updating
44
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Installation and Removal
Note: Removing the CMM before safely shutting it down is highly discouraged. Corruption of the flash
could occur if the CMM is yanked suddenly during a flash operation.
To remove the ZT 7102 CMM from a system:
Note: Take the necessary precautions to protect the ZT 7102 from static discharge. System power does
not need to be off to remove a CMM board. However, other boards in the system should be shut
down.
1. Unscrew the board retention screw that fastens the board to the enclosure. This screw is
located at the opposite end of the faceplate from the ejector handle. Refer to Figure 3, “Face
Plate” on page 20 for the screw's location.
2. If system power is off or the CMM's blue hot swap LED is on, proceed to the next step. If not,
the CMM needs to be in a “safe” state before it can be removed. Signal the CMM that it is
about to be removed by partially unlatching its ejector. Do not fully open the ejector as this
levers the board out of the enclosure and breaks its backplane connection before the board can
shut down properly.
3. Wait for the blue hot swap LED to light. It will take a few seconds to light up. The LED will
not light if other boards in the system are powered on. Refer to Figure 3, “Face Plate” on
page 20 for the LED's location.
4. Open the ejector handle fully, rotating it outward until the board disengages from the
5. Slide the board evenly out of the enclosure.
6. Install a replacement CMM or cover the empty slot with a filler panel to maintain the system’s
shielding and cooling performance.
Technical Product Specification
45
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Installation and Removal
46
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Built-In Self Test
6.0
Built-In Self Test
The CMM provides for a Built-In Self Test (BIST). The test will be run automatically after
power-up or front-panel reset. This test will detect flash corruption as well as other critical
hardware failures.
Results for the BIST are displayed on the console through the serial port during boot time. Results
of BIST will also be available through the CLI if the OS successfully boots.
If the BIST detects a fatal error, the CMM will not be allowed to function as an active CMM.
6.1
BIST Test Flow
The following state diagram shows the order of the tests RedBoot* runs following a power-up or
front-panel reset. On every state before reaching active CMM, if there is an error, RedBoot will log
the error event into the EEPROM, route the error message to the serial port, and continue booting.
If the execution hangs before the OS loads due to the nature of the error, the CMM hangs. If the OS
successfully boots, it will alert users to any errors that occurred during boot.
Figure 9. BIST Flow Chart
RedBoot*
Image
FPGA
Image
Checksum
Checksum
Power Up/
Reset
Memory Test
BlueCat*
loaded (active
CMM)
BlueCat
Image
Checksum
IPMB
Bus Test
FPGA,
DS1307, NIC
*Other names and brands may be claimed as the property of others.
Technical Product Specification
47
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Built-In Self Test
The BIST is broken down into stages consisting of groups of tests run at serious times throughout
the boot process. Table 20 shows the different BIST stages and the tests associated with each stage:
Table 20. BIST Implementation
Boot-BIST
Early-BIST
Mid-BIST
Late-BIST
RedBoot image
checksum
Strobe watchdog timer to
extend timeout period
Extended memory test
BlueCat image checksum
IPMB bus test
FPGA image checksum
FPGA version check
DS1307 RTC test
Base memory test
Local PCI bus / NIC
presence test
6.2
Boot-BIST
The codes in Boot-BIST will be executed at the very early stage of the RedBoot bootstrap, which is
just before the FPGA programming and memory module initialization. Boot-BIST will perform
checksum checking over the RedBoot image and the FPGA image. Checksum errors will be
detected if there is a mismatch of between the calculated checksum and the stored checksum in FIS
directory.
Boot-BIST will also perform a Base Memory Test for the first 1 Mbyte of memory. Whenever there
is an error, BIST will inform the user by prompting a warning message through the console
terminal and log the event to event-log area.
6.3
6.4
Early-BIST
The early BIST stage will extend the reset timeout period on the watchdog timer (MAX6374) by
strobing GPIO7 on FPGA1. This prevents any possible hardware reset during the BIST process.
The watchdog timer will be enabled after the ADM1026 GPIO initialization, and disabled once it
reaches the RedBoot console. The OS will enable the watchdog timer again and start the strobing
thread at the kernel level.
Mid-BIST
Mid-BIST will be started just after some basic modules initialization, such as flash and zlib
compression. In this stage of BIST, the Extended Memory Test will be performed to scan and
diagnose the possible bit errors in the memory. It starts scanning from 1 MByte to the maximum
available memory size on the board. It will not test the memory below 1 MByte because portion of
RedBoot has already loaded and resided on it. The memory test includes: the walking ones test,
32-bit address test, and 32-bit inverse address test. Furthermore, voltage and temperature ratings
will be verified to lie within the hardware tolerable ranges. The FPGA firmware version will be
checked and will alert if an older version of an FPGA image has been detected. Also, system date
and time will be read out from the real time clock and displayed through the console terminal. NIC
presence is also checked here. NIC self-test is not performed here because it is performed in the
existing NIC driver module.
48
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Built-In Self Test
6.5
Late-BIST
Late-BIST involves disabling the watchdog timer to indicate a successful boot of RedBoot. It will
also verify the checksum of the OS image stored in the FIS directory before proceeding with the
boot script execution.
Figure 10 shows at which times during the boot cycle the various stages of BIST are performed.
Figure 10. 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
Late-BIST
Module
initialization
(ethernet interface)
Display copyright
banner, and
execute boot script
Done
6.6
Event Log Area and Event Management
Errors detected by the BIST are stored in an event log. The event-log area is designed to have 269
entries. Each entry is 14 bytes. The event-log area is located in EEPROM on the CMM. The BIST
can place entries into the event log until it becomes full. Once full, any new entries will be lost. The
BIST event log is cleared by the OS once the OS logs any BIST errors into the SEL.
Technical Product Specification
49
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Built-In Self Test
At OS start-up, the CMM will read the contents of BIST results in the reserved event log area and
store the errors as entries in the CMM SEL. This will allow the CMM application to take the
appropriate action based upon the SEL events as a result of RedBoot BIST tests. If there is not
enough space to log the events in the CMM SEL, no results are logged to the CMM SEL.
The BIST event log will be erased only after the event log is stored into the CMM SEL. Event
6.7
OS Flash Corruption Detection and Recovery Design
The OS is responsible for flash content integrity at runtime. Flash monitoring under the OS
environment can be divided into two parts: monitoring static images and monitoring dynamic
images.
Static images refer to the RedBoot image, FPGA image and BlueCat image in flash. These images
should not change throughout the lifetime of the CMM unless they are purposely updated or
corrupted. The CRC for these files are written into flash when the images are uploaded.
Dynamic image refers to the OS Flash File System (JFFS2). This image will dynamically change
throughout the runtime of the OS.
6.7.1
6.7.2
Monitoring the Static Images
A static test is run at specified time intervals during CMM operation. The interval is specified on
the command line in the CMM startup script. The default interval is 24 hours. A value of zero will
turn off the test. The static test will read each static image (RedBoot, FPGA, BlueCat), calculate the
image checksum, and compare with the checksum in the RedBoot configuration area (FIS). If the
check sum test fails, the error will be logged to the CMM SEL.
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 will be 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. If a flash corruption is detected, an event will be logged to the
CMM SEL.
6.7.3
CMM Failover
If during normal OS operation a critical error occurs on the active CMM, such as for a flash
corruption, the standby CMM will be checked to see if it is in a healthier state. If the standby CMM
is in a healthier state, then a failover will occur.
50
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Built-In Self Test
6.8
BIST Test Descriptions
6.8.1
Flash Checksum Test
This test is targeted to verify the RedBoot image and FPGA image are not corrupted.This test will
calculate the CRC32 checksum from the RedBoot image, and then compare with the image
checksum stored in the FIS directory. If one mismatches another, BIST will switch to the backup
image. If checksum mismatch was found from the FPGA image, BIST will load the backup image
to program the FPGA device.
6.8.2
6.8.3
Base Memory Test
This test will write the data pattern of 55AA55AA into every 4-byte of memory below 1 Mbyte. Its
objective is to verify wire connectivity of address and data pins between the memory module and
the processor. The test will write the data pattern into the complete first 1 Mbyte, then verify the
written data pattern by reading them out from the memory module. If the data pattern mismatches,
the test will log the error event into event-log area and route error message to serial port.
Extended Memory Tests
6.8.3.1
Walking Ones Test
This test is targeted to verify the data bus wiring by testing the bus one bit at a time. The data bus
passes the test if each data bit can be set to 0 and 1 independently of the other data bits.
6.8.3.2
32-Bit Address Test
This test is targeted to verify the address bus wiring. The smallest set of addresses that will cover
all possible combinations is the set of “power-of-two” addresses. These addresses are analogous to
the set of data values used in the walking 1's test. The corresponding memory locations are 0001h,
0002h, 0004h, 0008h, 0010h, 0020h, and so on. In addition, address 0000h must also be tested. The
possibility of overlapping locations makes the address bus test harder to implement. After writing
to one of the addresses, we must check that none of the others has been overwritten.
Note that not all of the address lines can be tested in this way. Part of the address-the left most
bits-selects the memory chip itself. Another part-the right most bits-may not be significant if the
data bus width is greater than eight bits. These extra bits will remain constant throughout the test
and reduce the number of test addresses. For example, if the processor has 32 address bits, it can
address up to 4 Gbytes of memory. If we want to test a 128 Kbyte block of memory, the 15
most-significant address bits will remain constant. In that case, only the 17 rightmost bits of the
address bus can actually be tested. (128 K is 1/32,768th of the total 4 Gbyte address space.)
To confirm that no two memory locations overlap, first write some initial data value at each
power-of-two offset within the device. Then a new value is written-an inverted copy of the initial
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, you have found a problem with the current address bit. If no overlapping is found, the
procedure is repeated for each of the remaining offsets.
6.8.3.3
32-Bit Inverse Address Test
This test is similar to the 32-bit address test except the addresses are tested in the inverse direction.
The test helps identify a broader scope of possible addressing errors inherent in memory modules.
Technical Product Specification
51
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Built-In Self Test
6.8.4
6.8.5
FPGA Version Check
This test is targeted to verify the correct FPGA image programmed into both FPGA chips. This test
will display the FPGA version on both FPGAs. Both versions should be the same, or the user will
be prompted with a warning message. If the programmed version is older than the expected, user
will be prompted to upgrade to the latest FPGA image.
DS1307 RTC Test
This test is targeted to verify the functionality of DS1307 RTC chip. This test will display the
date/time settings from the RTC and validate the readings. If any readings found to be non-BCD
format, user will be prompted with warning message. This test will also capture current time, sleep
a while, then compare the previously captured time and new time. If they differ, it means the RTC
is working. Otherwise, user will be prompted with warning message.
6.8.6
6.8.7
6.8.8
NIC Presence/Local PCI Bus Test
This test generates the PCI bus transaction by scanning the PCI buses available on the board. This
test will detect the two Ethernet devices and verify each device has the valid Vendor ID and Device
ID in the PCI configuration space. NIC internal self-test will not be performed here, as the self-test
will be executed when loading the Ethernet driver.
OS Image Checksum Test
This test is targeted to verify the OS image stored in the flash is not corrupted. This test will
calculate the CRC32 checksum from the OS image, then compare with the image checksum stored
in the FIS directory. If one mismatches the other, BIST will log an error event to the event-log area
and route the error message to serial port.
CRC32 Checksum
CRC32 is the 32-bit version of Cyclic Redundant Check technique designed to ensure the bits’
validity and integrity within the data.
It first generates the diffusion table, which consists of 256 entries of double-word; each entry is
known as a unique diffusion code. The checksum calculation is started by fetching the first byte in
data buffer, exclusive-OR with the temporary checksum value. The resulting value will be AND-ed
with 0xFF to restrict an index from 0 to 255 (decimal). That index will be used to fetch a new
diffusion code from the table. Next, the newly fetched diffusion code will be exclusive-OR with the
most significant 24 bits of the temporary checksum value (effectively 8 bits left-shifting the
checksum value). The resulting value is the new temporary checksum value. The calculation
process is repeated until the last byte in the data buffer. The final temporary checksum value
becomes the final checksum value.
6.8.9
IPMB Bus Busy/Not Ready Test
This test identifies any potential FPGA lockup before loading BlueCat. If the FPGA is detected to
be locked up, an event indicating which bus actually failed will be logged into the Event log.
52
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Connection and Setup
7.0
CMM Connection and Setup
7.1
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 Telnet or the CMM's serial port. Using the CLI, users
can access information about the current state of the system including current sensor values,
threshold settings, recent events, and overall chassis health.
Note: Commands should always be issued to the CLI on the active CMM. The standby CMM can only
respond to commands to the CMM location.
7.2
Connecting to the CLI
• An Ethernet connection via an RJ-45 connector
• An RS-232 serial port interface also via an RJ-45 connector
Either of these interfaces can be used to log into the CMM, as well as the Ethernet interface
provided through the backplane of a chassis. Use Telnet to log into the CMM over a Ethernet
connection, or use a terminal application or serial console over the RS-232 interface.
If logging in for the first time to set up IP addresses, use the serial port console interface to perform
configuration.
7.2.1
Connecting through a Console
Connect an RS-232 serial cable with an RJ-45 connector to the serial console port on the front of
the CMM. Set your terminal application settings as follows:
• Baud – 115200
• Data Bits – 8
• Parity – None
• Stop Bits – 1
• Flow Control – Xon/Xoff or none
Connect using your terminal application.
7.2.2
Telnet into the CMM
To telnet into the CMM, point your console or telnet application to the IP address of the CMM you
wish to telnet to. If you wish to telnet to the active CMM through the backplane, you can point the
telnet application to the Eth1:1 IP address.
Technical Product Specification
53
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Connection and Setup
7.2.3
FTP Into the CMM
Using an FTP client, FTP to the IP address of the CMM you wish to transfer files to or from.
7.3
Initial Setup - Logging in for the First Time
The default 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. For information on resetting the
7.3.1
Setting IP Address Properties
By default, the CMM assigns IP addresses statically. Eth0, the front panel Ethernet port, is
configured with the static IP address 10.90.90.91. Eth1, the Ethernet port to the backplane, is
configured with a static IP address of 192.168.100.92. Eth1:1, an alias of Eth1 is used to always
point to and be active on the active CMM, is configured with a static IP address of 192.168.100.93.
On initial power up of a chassis with two CMMs, both CMMs will have the same IP addresses
assigned by default. When the chassis is powered up, the standby CMM automatically decrements
its eth1 IP address by one less than the active CMM.
Example:
1. A dual CMM Chassis is powered up.
2. Active CMM is assigned IP address of 192.168.100.92 to Eth1 on the active CMM.
3. Standby CMM is assigned IP address of 192.168.100.91 to Eth1 on the standby CMM.
At this point, the static IP addresses must be changed to appropriate values for their network
configuration. Ensure that the two CMMs do not contain duplicate IP addresses on Eth0 and eth1 to
avoid address conflicts on the network.
eth0 can also be set using DHCP. eth1, and eth1:1 will always remain static.
Note: eth0 should always be set to a different subnet than eth1. Failure to set eth0 to a different subnet
than eth1 will cause network errors on the CMM and redundancy will be lost.
Note: A DHCP server must be present on the network for the CMM to get a valid IP address. The
network reload command will refresh the IP addresses on both network interfaces.
54
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Connection and Setup
7.3.1.1
Eth0
Setting IP Information (IP Address, Netmask, and Gateway)
1. Open the /etc/ifcfg-eth0 file using the vi editor
2. Ensure the BOOTPROTO variable is set to static.
Note: Linux is case sensitive, so ensure that the BOOTPROTO variable is entered in lower case letters in
the step above.
3. Set the STATICIP variable to the IP address you want to assign to that interface.
4. Set the NETMASK variable to the appropriate netmask for your network.
5. Set the GATEWAY variable to the appropriate value for the gateway on your network
6. To activate the changes, at the user prompt, type:
/etc/rc.d/network reload
Eth1 and Eth1:1
Note: Eth1 and Eth1:1 are static IP addresses only. They do not support DHCP.
1. Open the /etc/ifcfg-eth1 file using the vi editor
2. Set the STATICIP1 variable to the IP address you want to assign to that interface.
3. Set the STATICIP2 variable to the IP address you want to assign to the active CMM on the
network. This value should ONLY be set on the active CMM, as it will be synchronized to and
overwritten on the standby CMM.
4. Set the NETMASK variable to the appropriate netmask for your network.
5. Set the GATEWAY variable to the appropriate value for the gateway on your network.
6. To activate the changes, at the user prompt, type:
/etc/rc.d/network reload
Note: The Eth1:1 address should only be changed on the active CMM. The new address will be
synchronized to the standby CMM automatically when the /etc/rc.d/network reload command is
executed.
7.3.1.2
Setting Eth0 to DHCP
1. Using the vi editor, change the BOOTPROTO variable in the /etc/ifcfg-eth0 file to dhcp.
Note: Linux is case sensitive, so ensure that the BOOTPROTO variable is entered in lower case letters in
the step above.
2. To activate the changes, the user can reboot the CMM, or at the user prompt, type:
/etc/rc.d/network reload
Note: eth1 and eth1:1 should not be set to dhcp. The BOOTPROTO variable does not exist in these files.
Technical Product Specification
55
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Connection and Setup
7.3.2
Setting a Hostname
The hostname of the CMM is a logical name that is used to identify a particular CMM. This name
is shown at login time and advertised to any DNS servers on a network.
To change the hostname:
1. Using the vi editor, change the HOSTNAME variable in /etc/HOSTNAME to the desired
name.
2. To activate the changes, at the user prompt, type: /etc/rc.d/network reload
Note: Executing network reload also causes the network interfaces to reload their IP addresses. If DHCP
is being used on a network interface, then it is possible that the IP address on that interface will
change.
7.3.3
Setting Auto-Logout Time Limit
For security purposes, the CMM automatically logs the user out of the current console session after
15 minutes (900 seconds). This auto-logout time can be changed by editing /etc/profile and
changing the TMOUT value to the desired setting. The timeout (TMOUT) value is set in seconds
(900 seconds is the default). A setting of TMOUT=0 will disable the automatic logout. This can
also be set at the command line, however doing so at the command line will not be persistent across
a reboot of the CMM.
7.3.4
Rebooting the CMM
To reboot the CMM, type the reboot command in the CLI. Telnet sessions will have to be
reestablished after the CMM is rebooted.
Do not use the “init 0” or “init 6” command to reboot the CMM as problems may result.
56
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Line Interface (CLI) Syntax and Arguments
8.0
Command Line Interface (CLI) Syntax and
Arguments
The command line interface on the CMM supports two types of commands: cmmgets and
cmmsets. Cmmgets are used to query for information, whereas cmmsets are used to write
information.
8.1
cmmget and cmmset syntax
The syntax for calling the CLI from the command line is as follows:
cmmget [-h] [-l location] [-t target] -d dataitem
cmmset [-h] [-l location] [-t target] -d dataitem -v value
Where cmmget and cmmset are the CLI executables. The parameters can be in any order. The CLI
is case insensitive, except for the executable name. Parameters shown in brackets are optional.
Any attribute value that contains a space must be enclosed in quotes. This happens often when
specifying targets. For example, to get the current value of a sensor called Brd Temp on the CMM,
the command would be:
cmmget –l cmm –t “Brd Temp” –d current
8.2
8.3
Help Parameter: -h
If the Help parameter is given, then the rest of the parameters are ignored, and the help text is
output to the user.
Location Parameter: -l
The Location parameter is the location in the system that the user is executing the cmmget or
cmmset on. If no location is given then the default location is the CMM. The Location keywords
are shown in the following table.
Table 21. Location (-l) Keywords
Keyword
Function
cmm
The Chassis Management Module.
One of the CPU boards in the chassis. N refers to the chassis slot number into which
the CPU board is inserted. Refer to the chassis documentation for slot information.
bladeN
system
chassis
fantrayN
The entire platform.
Chassis specific items excluding the boards (such as fan trays and power supplies).
One of the fan trays in the system. N refers to the number of the fan tray in the system.
(Only works with IPMI power supplies.) One of the power supplies in the system
where N is a number between 1-8.
powersupplyN
If no location parameter is given, then the default is CMM.
Technical Product Specification
57
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Line Interface (CLI) Syntax and Arguments
8.4
Target Parameter: -t
The Target parameter is the sensor or variable that the cmmget or cmmset acts on. The Target
keywords are shown in the following table.
Note: If the target is not specified, then it is assumed that Dataitem is an attribute of Location.
Table 22. Target (-t) Keywords
Keyword
Description
Used to query the FRU or individual FRU fields for a specific location. For more
information on querying a component’s FRU and individual FRU fields, see Section 16.0,
fru
The sensor name as defined in its Sensor Data Record (SDR) for that component. Sensor
names can be retrieved for an IPMI based location using the ListTargets Dataitem.
SDR Sensors
none
Same as not entering a target.
8.5
Dataitem Parameter: -d
The Dataitem parameter is the Target or Location attribute that the user is getting or setting.
Dataitem must be given for every CLI command. The Dataitem keywords are shown in the
following table.
Table 23. dataitem (-d) Keywords for All Locations (Sheet 1 of 2)
Get/
Set
Valid Set
Values:
Data Item
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 script to be
executed must be located in the /home/scripts directory on
the CMM and the /home/scripts path should be omitted
when specifying the script. See Section 18.0, “CMM
Scripting” on page 93 for more information.
Valid filename
of a script that
resides in
criticalaction
majoraction
minoraction
normalaction
Both
/home/scripts
none
current
health
The current value of a sensor.
Get
Get
N/A
N/A
Returns the health of the location and if any events exist.
Returns the specific health events that are occurring on
the location if any exist.
healthevents
listdataitems
Get
Get
N/A
N/A
Used to find the data items available on a location.
The output lists dataitems that the location supports.
Used to find what sensors or targets are available on the
listtargets
location. This is the list of sensors defined by the SDR for Get
that particular location.
N/A
Used to find out if a particular location is occupied or
present in the chassis. This can be blades or intelligent fan Get
trays.
presence
sel
N/A
N/A
Returns a location's System Event Log.
Get
58
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Line Interface (CLI) Syntax and Arguments
Table 23. dataitem (-d) Keywords for All Locations (Sheet 2 of 2)
Get/
Set
Valid Set
Values:
Data Item
Description
All thresholds of a sensor. This includes lower
thresholdsall
non-recoverable, lower critical, lower non-critical, upper
non-critical, upper critical, and upper non-recoverable.
Get
N/A
uppercritical
uppernoncritical
lowercritical
Used to query individual thresholds for a value based
sensor, such as temperature or voltage.
Get
Set
N/A
lowernoncritical
uppernonrecoverable
lowernonrecoverable
Used to trigger a script based on event code of a health
event. Refer to Section 18.0, “CMM Scripting” on page 93
The event code
of the event
eventaction
Table 24. dataitem (-d) Keywords for System location
Get/
Set
Valid Set
Values
Data Item
Description
Output:
Critical: CritList
Major: MajList
Minor: MinList
unhealthylocations
Get
N/A
where each list is a list of locations having that level of
health events (space separated).
In the output, PSn refers to PowerSupplyN (i.e., PS1 =
PowerSupply1, PS2 = PowerSupply2, etc.)
Table 25. dataitem (-d) Keywords for BladeN Locations
Get/
Set
Data Item
Description
Valid Set Values:
1 - Add board to
drone mode list
Used to add IPMI capable drone mode compatible
blades to the list of recognized drone mode boards. For
further information on drone mode see Section 14.0,
ignorespcirst
Set
0 - Delete board
from drone mode
list
poweron
poweroff
Used to query or control the power state of a board. This
is also used to reset a board.
powerstate
Both reset
offline
activate
Technical Product Specification
59
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Line Interface (CLI) Syntax and Arguments
Table 26. dataitem (-d) Keywords for Chassis Location
Get/
Set
Data Item
Description
Valid Set Values:
Used to set or query the fan speed of all the fans in
the system as a percentage of their full speed. Some
fan trays may prevent the fan speed from going to
zero. Querying the fan speed does not show actual
fanspeed, but reflects what the CMM fan speed output
is set to as a percentage of the actual full fan speed.
page 91 for further information.
100 (default)
fanspeed
Both 80
0
Note: In case of a temperature upper threshold
violation, the fans will be automatically set by the
CMM to run at full speed until the violation deasserts.
Used to set or query the value configured in the CMM
for the maximum amount of time the CMM will wait for
the HEALTHY # hardware signal to be asserted by an
SBC.
2 (default)
through 60
healthyrampuptime
location
Both
in seconds
Location String of
Both up to 16
characters
Used to set or query the location field in the chassis
FRU.
“ -1” (Default)
Used to set or query the value for the maximum
number of tries the CMM will attempt to power up a
board during the power sequencing loop.
0
maxpowerupattempts
Both
through
2000000000
1 - Enable
Both
psinhibit[1..8]
slotinfo
Used to inhibit the power supplies in the chassis.
0- Inhibit
Queries chassis slot layout information. This will tell
the user what slots are system slots, peripheral slots,
or busless slots. It will also show which slots are
occupied by blades.
Get
N/A
Table 27. dataitem (-d) Keywords for CMM Location (Sheet 1 of 2)
Get/
Set
Valid Set
Values:
Data Item
Description
Used to engage the Alarm Cutoff (ACO) or get its value.
When engaged, the ACO silences active alarms and
blinks the alarm LEDs on the CMM. This Dataitem is
only valid when used with the CMM as the location.
1 - Set cut off
alarmcutoff
Both
0 - Unset cut
off
Number of
minutes:
0-1000.
Used to set the Alarm Cutoff timeout value (in minutes)
or get its value. This is the length of time the CMM waits
before automatically canceling an engaged ACO (if the
user fails to cancel it manually). A value of 0 disables the
timeout. This dataitem is only valid when used with the
CMM as the location.
alarmtimeout
Both
Value of 0
disables the
timeout.
1 - Turn On
LED
criticalled
minorled
majorled
Used to turn on or off the critical, major and minor LEDs. Set
Used to change to the eth0 direction to either the front
0 - Turn Off
LED
front (default)
rear
Ethernet
Both
panel or the rear panel IO card.
60
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Line Interface (CLI) Syntax and Arguments
Table 27. dataitem (-d) Keywords for CMM Location (Sheet 2 of 2)
Get/
Set
Valid Set
Values:
Data Item
Description
Used only from the active CMM to failover to the standby
CMM. This command will only successfully execute if
the standby CMM is in a healthy enough state to accept
a failover.
failover
Set
1 - Failover
Used to query CMM redundancy information. Indicates
CMM(s) presence, which CMM is active, which CMM is
stand by, and which one the user is logged into.
redundancy
version
Get
Get
N/A
N/A
The version of the CMM software.
Valid SNMP
community
name:
snmptrapcommunity
Set or query the SNMP trap community string.
Both
public (default)
Enable
(default)
snmpenable
Sets or queries the SNMP trap enabled status.
Both
Both
Disable
IP Address in
the form:
The IP address of the machines receiving SNMP traps
from the CMM.
snmptrapaddress[1..5]
x.x.x.x
Valid port
number:
Sets or queries the TCP/IP port that the SNMP trap will
be sent from.
snmptrapport
Both
Both
0-65536
162 (default)
V1(default)
V3
snmptrapversion
Sets or queries the SNMP trap version.
Used with the cmmget command to update the CMM
firmware on the CMM.
Starts the
The syntax of the command is: cmmset -l cmm -d update
-v [Update Package path and filename] [force]
[overwrite] [ftp:server:user:password]
update of the
firmware on
that CMM.
update
Set
8.6
8.7
Value Parameter: -v
The Value parameter specifies the new value for a Dataitem. This parameter is required for all
cmmset commands and is only used for cmmset commands. Valid value parameters are shown in
with their corresponding data items in the data item tables listed above.
Sample CLI Operations
Technical Product Specification
61
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Line Interface (CLI) Syntax and Arguments
8.8
Generating a System Status Report
The CLI includes an executable script (cmmdump) that is used to generate a system status report
for use in communicating system health and configuration information to technical support
personnel. This is useful in helping technical support successfully troubleshoot any issues that may
be affecting the system. Cmmdump outputs system information to the screen by default or to a file.
To send the output to a file use the following command:
cmmdump > [filename]
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 7.2.3, “FTP Into the CMM” on
page 54).
62
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Resetting the Password
9.0
Resetting the Password
It may become necessary to reset the CMM password to its default of cmmrootpass. The CMM has
an onboard dip switch labeled SW1-1 to perform this action. See Section 2.10, “Onboard
Switches” on page 31 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 must be removed, and the switch
must be turned off again.
9.1
Resetting the Password in a Single CMM System
For non-redundant systems that contain only a single CMM, resetting the password requires
removing the CMM. This causes any boards that are power controlled by the CMM to power off.
1. If necessary, safely shut down and power off boards being power controlled by the CMM.
2. Remove the CMM from the system.
3. Turn on the dip switch SW1-1. The dip switch has a label indicating which way is on.
4. Reinsert the CMM into the system and allow the CMM to fully boot into Bluecat Linux*.
5. Once at the login prompt, the password should now be reset to its default of cmmrootpass.
6. Log in to the CMM to ensure the password was reset.
7. Remove the CMM from the system.
8. Turn off dip switch SW-1 by moving it back to its original off position.
9. Reinsert the CMM into the system and allow the CMM to fully boot into Bluecat Linux.
10. Log in to the CMM and operate as normal.
9.2
Resetting the Password in a Dual CMM System
In redundant systems containing dual CMMs - one active, one standby - the password should be
reset on the standby CMM. Once reset to its default, the default password will synchronize itself to
the active CMM. This prevents the need to perform the reset on both CMMs and a failover.
1. Open the ejector latch on the standby CMM and wait for the blue hot swap LED to illuminate,
indicating the CMM is safe to remove from the system.
2. A health event will occur on the active CMM indicating redundancy has been lost. A SEL
entry will be recorded, and a trap will be sent out.
3. Remove the standby CMM from the chassis.
4. Turn on the dip switch SW1-1. The dip switch has a label indicating which way is on.
5. Reinsert the CMM into the system and allow the CMM to fully boot into Bluecat Linux.
6. A health event will occur indicating that the passwords on both CMMs have been reset and
was synched from the standby CMM.
7. Once at the login prompt, the password should now be reset to its default of cmmrootpass.
8. Login to the active CMM to ensure the password was reset.
Technical Product Specification
63
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Resetting the Password
9. Open the ejector latch on the standby CMM and wait for the blue hot swap LED to illuminate,
indicating the CMM is safe to remove from the system.
10. A health event will occur on the active CMM indicating redundancy has been lost. A SEL
entry will be recorded, and a trap will be sent out.
11. Remove the standby CMM from the chassis.
12. Turn off the dip switch SW1-1.
13. Reinsert the CMM into the system and allow the CMM to fully boot into Bluecat Linux.
14. The password can now be set on the active CMM and it will get synched to the standby CMM
and the CMM can now be operated normally.
64
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Sensor Types
10.0 Sensor Types
The CMM provides access to and can log events from different IPMI sensor types. These sensors
can be 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.
10.1
Threshold-Based Sensors
Threshold based sensors are sensors that generate or change an event status based on comparing a
current value to a threshold value for a given hardware monitor device. Examples of threshold
based sensors are temperature, voltage, and fan tachometer sensors.
10.1.1
Threshold-Based Sensor Events
Threshold-based sensors generate events when a current value for a device becomes greater than or
less than a given threshold value. The IPMI specification defines six thresholds that can be
assigned to a given sensor. The sensor will generate an event when its current reading goes above
or below any of these thresholds. The severity of the event generated depends on which threshold is
crossed. These six thresholds and their associated event severity are as follows:
Upper non-recoverable---> Critical Event
Upper critical--->Major Event
Upper non-critical--->Minor Event
Lower non-critical--->Minor Event
Lower critical--->Major Event
Lower non-recoverable--->Critical Event
10.2
Discrete Sensors
Discrete sensors are sensors that have a predefined set of states. An examples of a discrete sensor
would be board presence, where a board is either present or not present.
10.2.1
Discrete Sensor Events
Discrete sensors can generate events on state changes. The severity of the event is determined by
the CMM. Discrete sensor events for the CMM are located in the next section, Chapter 11.0,
Technical Product Specification
65
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Sensor Types
66
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
11.0 Health Event Strings
This section describes the health event strings that are associated with CMM events and includes
information on the different types of sensors.
Note: For this section, “health event” (two words) refers to any event that is generated that reports the
health of a sensor. “healthevents” (all one word) refers specifically to the “healthevents” dataitem
or the output of that dataitem (healthevents query).
11.1
Syntax of Health Event Strings
Health event string is a string that is associated with the particular health event occurring. Active
events are displayed in a healthevents query using the following command in the CLI:
cmmget -l [location] [-t [target]] -d healthevents
Active health events are also returned when healthevents queries are executed over SNMP. In
addition, all health events are logged in the SEL and sent out as SNMP Traps.
Note: SEL entries and SNMP traps do not include the severity of the event. Only healthevents query
results display the severity of an event.
11.1.1
“healthevents” Query Event Syntax
The following is the syntax of a string returned by a healthevents query for an associated active
health event. The \n represents newline characters (seen as <0A> in SNMP queries).
[Timestamp]\n
[Severity] Event : [SDR Sensor Name] [Health Event String]\n
• Timestamp is in the format: [Day] [Month] [Date] [HH:MM:SS] [Year]. For example,
Thu Dec 11 22:20:03 2003
• Severity is either Minor, Major, or Critical.
• SDR Sensor Name is the name given to the sensor in the Sensor Data Record (SDR).
11.1.2
SEL Event Syntax
The following is the syntax of each SEL entry for an associated health event. The \n represents
newline characters and the \t represents tab characters.
[Timestamp]\n
\t[SDR Sensor Name]\t[Health Event String]\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).
Technical Product Specification
67
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
11.1.3
SNMP Trap Event Syntax
The following is the syntax of each SNMP trap for an associated event:
Time : [TimeStamp] , Location : [ChassisLocation] , Chassis Serial # :
[ChassisSN] , Board : [Location] , Sensor : [SDR Sensor Name] , Event :
[Health Event String]
• 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 recorde 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).
11.2
Sensor Targets
Available sensors for a location can be retrieved with the listtargets dataitem argument of the
cmmget command. To view a list of sensor targets on the cmm using the listtargets command:
cmmget -l cmm -d listtargets
The CMM lists the following sensors that can be queried for health events:
Table 28. CMM Sensor Targets
Sensor Target
Description
Board Temperature Sensor
Brd Temp
+1.5V
+1.5 Volt Sensor
+2.5V
+2.5 Volt Sensor
+3.3V
+3.3 Volt Sensor
+5V
+5 Volt Sensor
Eth0 Interface
Eth1 Interface
Eth1:1 Interface
TASensor1
TASensor2
BIST
Eth0 LAN Sensor
Eth1 LAN Sensor
Eth1:1 LAN Sensor
Telco Alarm Input Sensor 1
Telco Alarm Input Sensor 2
Built-in Self Test Sensor Type
For complete lists of sensors on other components (i.e., voltage sensors on blade1), refer to the
corresponding Technical Product Specification for that product.
68
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
11.3
Healthevents Queries
Healthevents queries, whether done from the CLI or through SNMP, output the same event strings
and syntax for active events. This section explains the various types of output that are retrieved
from healthevents queries. For more information on using the healthevents dataitem, refer to
11.3.1
HealthEvents Queries for Individual Sensors
Executing a healthevents query on a particular sensor target returns all active healthevents for that
sensor target in a concatenated string. One sensor may have multiple events. For example, running
the following healthevents query on the CMM BIST sensor:
cmmget -l cmm -t BIST -d healthevents
might return multiple events that are active on the BIST sensor in a concatenated string like this:
Mon Feb 2 19:51:05 2004
Major Event : BIST RTC Not Working
Mon Feb 2 19:51:09 2004
Major Event : BIST Both Ethernet interfaces are not working.
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
powersupplyN* locations.
* - PowersupplyN healthevents are dependent on the presence of IPMI-compliant power supplies.
The “pwr supply N” target on the chassis location is used for querying non-IPMI capabilities of
power supplies (i.e., Failure Detected). Querying the healthevents on the chassis location will
return all active events for all “pwr supply N” targets.
The CMM’s SNMP interface provides a “cmm” target that can be found in the listtargets ouput.
This target is used to execute healthevents queries for all active events on the CMM. Since each
OID in the MIB requires a target on the location, the “cmm” target was implemented in SNMP to
give the user the ability to do a healthevents query of the cmm location equivalent to the CLI
command “cmmget -l cmm -d healthevents”. Similar SNMP-specific targets also exist for chassis
and bladeN that allow users to retrieve all active events for that location. Refer to Section 19.0,
11.3.3
No Active Events
When a healthevents query is executed in the CLI on a target that doesn’t have active events a
string will be returned that is a single line string with no timestamp or severity. Only this string will
be returned and won’t be concatenated with any other strings. For example, doing a healthevents
query from the CLI of a location or target that doesn’t have any active healthevents will return the
following string:
“[Target] has no problems.” - i.e., “chassis has no problems” or “temp snsr 1 has no problems”
Technical Product Specification
69
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
Executing a healthevents query through SNMP on a target with no active events returns different
values than the CLI does. When a healthevents query is executed in SNMP on:
• A location target (i.e., in SNMP, the cmm target on the cmm location) that has no active
events, the value returned is a zero length string.
• An individual sensor (i.e., the +3.3V sensor on the CMM) that has no active events, the value
returned is a null value.
Note: Attempting to execute a healthevents query on the “FRU” target will return a “CLI Invalid Data
Item Error.” string since “FRU” is not a sensor.
11.3.4
Not Present or Non-IPMI Locations
Doing a healthevents query of a blade or powersupply, or a target on a blade or powersupply, that is
not present or non-IPMI compliant will return one of the following:
“BPM Blade Not Present.” - if querying an empty blade slot.
“BPM Non IPMI Blade.” - if querying a blade that is present but doesn’t support IPMI.
“Power Supply Not Present.” - if querying an empty power supply slot or a power supply that
doesn’t support IPMI.
11.4
List of Possible Health Event Strings
Table 29 through Table 40 list possible event strings for sensors on the CMM, chassis, fan tray, and
powersupply. Each event will log an entry in the SEL and generate an SNMP Trap, and can be
retrieved through a healthevents query on a target or location. Locations and sensor names are
listed as well.
The event severity is not displayed in the SEL entry or the SNMP trap. The severity of the event
(Minor, Major, or Critical) is displayed in a healthevents query while the event is active. OK
HealthEvents are displayed in healthevents queries for only a limited time when they are asserted.
For each event, the event code is listed in base 10 format for use with event scripting, which is
The table for threshold-based sensors is common to other threshold-based sensors on other
components (e.g., voltage, temp, current).
70
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
11.4.1
All Locations
Table 29. Threshold-Based Sensor Event Strings (Voltage, Temp, Current, Fan)
Event String
Event Code
Event Severity
Minor
"Lower non-critical going low asserted "
"Lower non-critical going high asserted "
"Lower critical going low asserted"
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Minor
Major
Major
Critical
Critical
Minor
Minor
Major
Major
Critical
Critical
OK
"Lower critical going high asserted"
"Lower non-recoverable going low asserted"
"Lower non-recoverable going high asserted"
“Upper non-critical going low asserted"
“Upper non-critical going high asserted"
"Upper critical going low asserted"
"Upper critical going high asserted"
"Upper non-recoverable going low asserted"
"Upper non-recoverable going high asserted"
"Lower non-critical going low deasserted "
"Lower non-critical going high deasserted "
"Lower critical going low deasserted"
OK
OK
"Lower critical going high deasserted"
"Lower non-recoverable going low deasserted"
"Lower non-recoverable going high deasserted"
"Upper non-critical going low deasserted"
"Upper non-critical going high deasserted"
"Upper critical going low deasserted"
OK
OK
OK
OK
OK
OK
"Upper critical going high deasserted"
"Upper non-recoverable going low deasserted"
"Upper non-recoverable going high deasserted"
OK
OK
OK
Note: For Threshold-based sensor events, strings for SEL entries are the same except they begin with the
word “Crossed” (i.e., “Crossed Upper critical going high asserted")
11.4.2
PowerSupplyN Location (IPMI-Compliant Supplies Only)
Table 30. Power Supply Event Strings (PowerSupplyN)
Event String
Event Code
51
Event severity
Critical
"Power Supply feed lost"
“Power Supply feed lost or out of range”
"Recovered from error conditions"
52
48
Critical
OK
Note: “Power Supply feed lost” event string is currently not implemented.
Technical Product Specification
71
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
11.4.3
CMM Location
Table 31. BIST Event Strings (BIST) (Sheet 1 of 2)
Event String
Event Code
112
Event Severity
OK
“Boot is Successful.”
“Event-log area full.”
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130 - 159
160
161
162
163
164
165
166
179
180
181
182
183
184
185
186
187
188
Critical
Major
Critical
Major
Critical
Critical
Critical
Critical
Minor
Minor
Minor
Major
Major
Critical
Minor
Major
OK
“RedBoot image corrupted.”
“Backup RedBoot image corrupted.”
“FPGA image corrupted. Using backup image.”
“Backup FPGA image corrupted.”
“OS image corrupted.”
“Base memory test failed.”
“Extended memory test failed.”
“FPGA1 firmware outdated.”
“FPGA2 firmware outdated.”
“FPGA 1+2 version mismatched.”
“RTC date is invalid.”
“RTC time is invalid.”
“RTC is not working.”
“One of the Ethernet interfaces is not working.”
“Both Ethernet interfaces are not working.”
“CMM Boot.”
“IPMB bus [0-29] busy/not ready.”
“Software update successful.”
Major
OK
“Update of RedBoot failed.”
Critical
Critical
Critical
Critical
Critical
Critical
OK
“Update of FPGA failed.”
“Update of Bluecat OS failed.”
“Update of /etc failed.”
“Restore of /etc files failed.”
“Software update failed.”
“Standby CMM has completed FPGA re-programming.”
“FPGA re-programmed 2 times and no further lockup detected.”
“FPGA re-programmed 3 times and no further lockup detected.”
“FPGA re-programming has failed.”
“FPGA re-programmed more than 3 times and lockup still detected.”
“Dynamic FLASH image corruption detected.”
“Static Redboot image is corrupt.”
“Static OS image is corrupt.”
Minor
Minor
Critical
Critical
Critical
Critical
Critical
Critical
Minor
“Static FPGA image is corrupt.”
“Primary FRU unreadable - using Secondary"
72
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
Table 31. BIST Event Strings (BIST) (Sheet 2 of 2)
Event String
Event Code
189
Event Severity
Critical
"FRU unreadable!"
"RTC battery power lost."
190
191
272
273
274
Critical
Critical
Major
"I2C failure while reading RTC."
"Primary FRU is corrupted."
"Secondary FRU is corrupted."
"FRU is corrupted!"
Major
Critical
Table 32. Telco Alarm Sensor Event Strings (TASensor[1,2])
Event String
Event Code
Event Severity
“asserted.”
96
97
Major
OK
“deasserted.”
\
Table 33. LAN Sensor Event Strings (Eth[0,1,1:1] Interface)
Event String
Event Code
Event Severity
“Duplicate IP address detected on the network.”
“Duplicate IP address corrected.”
84
85
Major
OK
11.4.4
Chassis Location
Table 34. Fan Tray Presence Event Strings (Fan Tray [1-3] Presence)
Event String
Event Code
Event Severity
"Fan Tray Removed"
"Fan Tray Inserted"
64
65
Major
OK
Table 35. Chassis Power Supply Event Strings (Pwr Supply N)
Event String
Event Code
Event Severity
"Recovered from error conditions"
"Power Supply Failure detected"
"Power Supply Degraded"
“Power Supply detected”
48
49
50
53
54
OK
Critical
Minor
OK
“Power Supply removed”
Major
Note: Chassis power supply detected and removed events are only generated with IPMI power supplies.
Technical Product Specification
73
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
Table 36. Slot Event Strings (Slot N Event)
Event String
Event Code
192
Event Severity
OK
"Blade Removed"
“Blade Presence Detected”
"Blade Deasserted HEALTHY#"
"Blade Asserted HEALTHY#"
“Blade Failed HEALTHY# After Maximum Attempts”
“Blade Powered On”
193
194
195
196
197
198
199
200
201
202
203
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
“Blade Powered Off”
“Blade Reset”
“Blade set to Offline”
“Blade set to Active”
“Blade is not IPMI capable”
"Blade is IPMI capable"
Table 37. CMM Redundancy Event Strings (CMM [1-2] Redundancy)
Event String
Event Code
Event Severity
"Regained"
208
209
210
211
OK
"Established"
OK
"Lost due to switch failure"
Major
Major
"Lost due to unhealthy signal"
"Lost due to failed network connectivity between the CMM and the
Primary SNMP trap destination (SNMPTrapAddress1)."
212
Major
"Lost due to CMM removal"
213
214
215
Major
Major
Major
"Lost due to CMM reboot"
"Lost due to critical event on the CMM"
"Lost due to inability to communicate with the other CMM over its
management bus."
216
239
Major
Major
"Lost due to incompatible firmware versions on the CMMs. Please
upgrade the CMMs to the same version."
Table 38. CMM Failover Event Strings (CMM Failover)
Event String
Event Code
217
Event Severity
"Failover occurred."
OK
OK
"Failover occurred because of switch failure."
218
219
220
221
222
"Failover occurred because of failed network connectivity between
the CMM and the Primary SNMP trap destination."
OK
OK
OK
OK
"Failover occurred because of critical CMM health events."
"Failover occurred because of a bad hardware signal from the other
CMM."
"Failover occurred because it was forced by the user."
74
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
Table 38. CMM Failover Event Strings (CMM Failover)
Event String
Event Code
223
Event Severity
OK
"Failover occurred because the other CMM rebooted."
"Failover cannot occur because the other CMM has a bad switch."
224
225
OK
OK
"Failover cannot occur because the other CMM has lost network
connectivity with its Primary SNMP trap destination."
"Failover cannot occur because the other CMM has critical health
events."
226
227
228
229
240
OK
OK
OK
OK
OK
"Failover cannot occur because the other CMM is not responding
over its management bus."
"Failover cannot occur because the critical items have not been
synced."
“Failover cannot occur because the other CMM has a bad hardware
signal.”
“Failover occurred because the active CMM had older firmware than
the newly active CMM.”
Note: In the CMM Redundancy and Failover event strings, the phrases “bad switch” and “switch failure”
refer to the switch that is associated with that CMM having deasserted its HEALTHY# signal. The
“bad hardware signal” refers to the CMM itself having deasserted its HEALTHY# signal.
Table 39. CMM File Sync Event Strings (CMM File Sync)
If HealthEvents, its
Event String
Event Code
230
severity
"Could not copy the /etc/CMM.cfg file to the standby CMM."
OK
OK
"Could not copy the /etc/passwd and /etc/shadow files to the standby
CMM."
231
“Default password files synced to active CMM. Passwords have been
reset to default.”
232
233
234
OK
OK
OK
"Could not copy the /etc/sel_* files to the standby CMM."
"Could not copy the /etc/snmpd.conf and /etc/var/snmpd.conf files to
the standby CMM."
"Could not copy the SDR file to the standby CMM."
"Could not copy the /etc/scripts directory to the standby CMM."
"All files successfully synced."
235
236
237
OK
OK
OK
Table 40. Chassis Sensor Event Strings
Event String
Event Code
Event Severity
Critical
“No PCI connectivity record found in chassis FRU information.”
“cmm.sif file not found. Cannot scan CMM sensors.”
256
257
258
Critical
Critical
“chassis.sif file not found. Cannot scan Chassis sensors.”
Technical Product Specification
75
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Health Event Strings
76
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Slot Power Control
12.0 Slot Power Control
The chassis management module controls power to the node and fabric slots of a chassis using the
BD_SEL# and HEALTHY# hardware signals. The CMM can power up, power down, and reset a
board in a particular slot, as well as to place a slot into an offline mode. The CMM can also be used
to query the power state of a board at any time.
12.1
Difference between a Board’s HEALTHY# Signal and a
Board’s Health
Confusion may arise as to the difference between the HEALTHY# hardware signal coming from a
board and the board’s health retrieved using the CLI command:
cmmget -l bladeN -d health
A board’s HEALTHY# signal is a PICMG-specified hardware signal on the CompactPCI
connector. The PICMG 2.0 specification defines HEALTHY# to be a signal generated by a board’s
hot swap control logic. At a minimum, HEALTHY# should be asserted by the hot swap control
when all of the voltages are good. Additional logic may be implemented above this to generate the
HEALTHY# signal. The CMM uses the HEALTHY# hardware signal to determine when a board is
powered up completely.
The board’s health, as returned by the CLI command listed above, is used to determine whether
there are any active health events occurring on a particular board, such as temperature or voltage
violations.
12.2
Slot Power-Up Sequence
The CMM constantly polls the status of the BD_SEL# lines coming from the node and fabric slots.
Boards inserted into the chassis will pull the BD_SEL# line to Vcc, indicating insertion of the
board.
12.2.1
Assertion of BD_SEL#
Upon detection of board insertion, the CMM determines whether to assert BD_SEL# based on the
type of board being inserted and the type of slot the board is being inserted to.
12.2.1.1
System Master Boards
For system master boards in system master slots, the CMM will always assert BD_SEL#.
12.2.1.2
Peripheral Boards
For peripheral boards inserted into peripheral slots, the CMM will ONLY assert BD_SEL# if a
system master board is present for that PCI segment. If a peripheral board is inserted into a system
master slot, or into a peripheral slot in a PCI segment with no system master, the CMM will not
assert BD_SEL# for that board.
Technical Product Specification
77
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Slot Power Control
12.2.1.3
Fabric and PCI-Less Slots
For node slots containing no PCI bus (PCI-less slots) as well as fabric slots, the CMM will always
assert BD_SEL#.
12.2.1.4
Drone Mode Boards
For drone mode capable boards that have been added to the CMM, the CMM will always assert
BD_SEL# regardless of the type of node slot where they are inserted. For more information on
Intel SBCs are recognized as drone mode capable.
12.2.2
Assertion of HEALTHY# During Power-Up
Upon assertion of BD_SEL#, the CMM will wait a minimum of two seconds for the board to assert
the HEALTHY# signal. The amount of time the CMM will wait for HEALTHY# to be asserted by
an SBC can be configured from the CMM interfaces from 2 to 60 seconds and is referred to as the
A board should generate a HEALTHY# signal indicating all of its onboard voltages are good per
the PICMG 2.1 R2.0 specification. Depending on the logic of the board, HEALTHY# can also be
generated by additional logic, such as from a BIST, OS boot-up, etc.
If within the defined HEALTHY# ramp-up time the CMM detects HEALTHY# being asserted, the
CMM will leave BD_SEL# asserted, and the board will go through its normal power-on sequence.
BD_SEL# will remain asserted unless the HEALTHY# signal gets deasserted for that board or the
command to power down a board is issued.
If within the defined HEALTHY# ramp-up time the CMM does not detect HEALTHY# being
asserted, the CMM will deassert BD_SEL# to that slot, and that board will not power up. If the
board remains inserted in the slot, the process will repeat on the next polling cycle of that slot. This
process will continue until either the board powers up, the board is removed from the slot, or the
maximum number of power up attempts is reached.
The maximum number of attempts the CMM will try to power on a board can be configured
through the CMM interfaces. See Section 12.5, “Power Sequencing Commands and Policies” on
page 79 for further information on how to set and retrieve the maximum power-up attempts.
12.3
Obtaining the Power State of a Board
The CMM can obtain the power state information of a board at any time by issuing the following
command:
cmmget -l bladeN -d powerstate
Where N is the number of the slot in which the blade you are querying resides. This command will
give information on whether the blade is present, the state of the HEALTHY# signal (asserted/
deasserted), whether the board has been powered up or not, and whether the slot is in the active or
offline mode. Output will look similar to this:
Board is present
78
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Slot Power Control
Board HEALTHY# signal is asserted
Board has been powered up by the CMM
Board is in active mode.
For further information on active and offline mode see Section 15.0, “Active vs. Offline Slots” on
12.4
Controlling the Power State of a Slot
The CMM can power a slot off, on, reset the slot, or place a slot in an offline mode. Placing a slot
in offline mode allows the CMM to ignore the state of the HEALTHY# signal from that slot.
12.4.1
Powering Off a Board
The following command will power a board off:
cmmset -l bladeN -d powerstate -v poweroff
N is the number of the slot the blade to be powered down resides in. Once issued, the command
will ask for confirmation by entering “y” before continuing.
12.4.2
12.4.3
Powering On a Board
The following command will power a board on:
cmmset -l bladeN -d powerstate -v poweron
N is the number of the slot the blade to be reset resides in.
Resetting a Board
The following command will reset a board:
cmmset -l bladeN -d powerstate -v reset
N is the number of the slot the blade to be reset resides in. Once issued, the command will ask for
confirmation by entering “y” before continuing.
12.5
Power Sequencing Commands and Policies
The following section describes how to set and retrieve the HEALTHY# ramp up time and
maximum power up attempts for the chassis.
HEALTHY# ramp up time is used to determine the maximum amount of time the CMM will wait
for an SBC to generate the HEALTHY# hardware signal during the current power sequencing loop.
If the amount of time defined in the healthyrampuptime expires, the CMM deasserts BD_SEL# to
the slot, and continues through the power up sequence loop. For example, on initial power up, if the
healthyrampuptime is set to two seconds, a blade can be reset during its powerup sequence. If set to
60 seconds, a reset command won’t take effect until 60 seconds after power on in which time the
blade will typically be booted.
Technical Product Specification
79
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Slot Power Control
The maximum power-up attempts variable is used to configure the number of times the CMM will
attempt to power on a board during the power sequencing loop. Once the maxpowerupattempts is
exceeded for a particular board, the CMM will no longer attempt to power on the board by
asserting the BD_SEL# signal during the power sequencing loop.
Setting these variables applies to the entire chassis, not just a single board or slot.
12.5.1
Retrieving the Healthy# Ramp-Up Time
Issuing the following command will retrieve the value configured in the CMM for the maximum
amount of time the CMM will wait for the HEALTHY # hardware signal to be asserted by an SBC.
cmmget -l chassis -d healthyrampuptime
This returns the time (in seconds) the CMM will wait for an SBC to generate the HEALTHY#
hardware signal for ALL node slots in the chassis. This time can range from 2 to 60 seconds. The
default is 2 seconds.
12.5.2
Setting the Healthy# Ramp-Up Time
The following command can be used to set the maximum amount of time in seconds the CMM will
wait for the HEALTHY# hardware signal to be asserted all SBCs in the chassis.
cmmset -l chassis -d healthyrampuptime -v [time]
Where time is a value between 2 and 60 seconds. The default is 2 seconds.
Setting this value applies to all boards in the chassis. For every newly inserted board, or every
board being powered on, the CMM will always wait the allotted healthyrampuptime, even if the
board asserts HEALTHY# before healthyrampuptime expires.
12.5.3
Retrieving the Maximum Power-Up Attempts
The following command is used to retrieve the configured value for the maximum number of tries
the CMM will attempt to power up a board during the power sequencing loop.
cmmget -l chassis -d maxpowerupattempts
The default value for maxpowerupattempts is -1, and indicates an infinite number of attempts will
be made by the CMM to power up boards in the chassis. This value applies to all boards in the
chassis.
12.5.4
Setting the Maximum Power-Up Attempts
The following command is used to set the value for the he maximum number of tries the CMM will
attempt to power up boards in the chassis during the power sequencing loop.
cmmset -l chassis -d maxpowerupattempts -v “[# of attempts]”
Where # of attempts is the desired number of attempts the CMM should try to power up boards in
the chassis enclosed in quotes. The default is a value of “ -1” and indicates the CMM will try an
infinite number of times to power up boards.
80
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Slot Power Control
Note: To set the maxpowerupattempts back to the default value of -1, you need to have a space between
the first quote and the number 1 (i.e., “ -1”).
Setting a value of “0” will cause the CMM to discontinue attempting to power up boards in the
chassis. Rebooting the chassis when the value is set to “0” will prevent the CMM from powering
up any blades in the chassis.
The maximum value that can be set for maxpowerupattempts is 2000000000.
This value applies to all boards in the chassis. Changing this value to a greater value with boards
that failed to power by reaching the previous maximum power up attempts will cause the CMM to
incrementally attempt to power up the board with the difference between the two maximums. For
example, for a board that failed to power up with a maxpowerupattempts of 5, changing the
maximumpowerupattempts to a value of 12 will cause the CMM to attempt to power up that board
an additional seven more times.
Failure of a board to power after reaching the maximum number of attempts will cause a SEL event
to be logged indicating this.
12.5.5
Power Sequencing SEL Events
The following power sequencing events will cause an event to be recorded in the chassis SEL.
1. CMM detects the presence or removal of a board
Slot X Event Blade Presence Detected
Slot X Event Blade Removed
2. CMM detects the assertion/deassertion of the HEALTHY# signal from the board
Slot X Event Blade Asserted HEALTHY#
Slot X Event Blade Deasserted HEALTHY#
3. CMM detects a board has failed to power up after reaching the maximum power up attempts
Slot X Event Blade Failed HEALTHY# After Maximum Attempts
4. CMM detects the powering on or off of a board
Slot X Event Blade Powered On
Slot X Event Blade Powered Off
5. CMM detects a board has reset
Slot X Event Blade Reset
6. CMM detects a slot has been placed in offline or active
Slot X Event Blade set to Offline
Slot X Event Blade set to Active
Technical Product Specification
81
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Slot Power Control
82
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Power Supplies
13.0 Power Supplies
13.1
Power Supply Detection
Unlike blades, there is no hardware support for the detection of power supply presence. Therefore,
an additional process is used to periodically scan for the presence of IPMI power supplies.
Specifically, every five seconds, the process sends an IPMI GetDeviceID to each of the possible
power supply slots. If a response is received, then it is known that an IPMI power supply is present.
13.2
Inhibit, Degrade, and Fail Signals
The CMM and power supplies do share several hardware signals that provide some limited
functionality. These signals work with existing (non-IPMI) power supplies and are expected to
work in the same way for the IPMI power supplies. The Inhibit signal is an output from the CMM
that can be used to effectively turn off a power supply. Querying the Inhibit signal will indicate
whether the CMM has inhibited the supply or not. When a power supply degrades or fails, it
signals these conditions to the CMM using the Degrade and Fail inputs.
The CMM can detect if any power supply is Degraded or Failed, then it can be deduced that there
is a power supply present. The new feature provided by IPMI supplies is the ability to detect the
presence of a power supply when the power supply is operating normally.
13.3
13.4
Inhibiting Power Supplies
The CMM has the ability to inhibit any of the power supplies in the chassis. Each power supply can
be inhibited individually.
The state of inhibited power supplies is synchronized from the active to the standby CMM. If a
failover were to occur, the inhibited power supplies would remain inhibited.
The state of inhibited power supplies is not persistent across chassis power cycles.
Precautions For Inhibiting Power Supplies
Care should be taken when inhibiting power supplies. Inhibiting certain supplies or groups of
supplies may cause the loss of power to portions of the chassis, including power to the CMMs. It is
also possible to inhibit all of the power supplies, which causes a loss of power to the entire chassis,
including the CMMs.
Once the CMMs lose power, they are no longer able to drive the INHIBIT# line to the power
supplies, which causes all of the supplies to power up again. Losing power to both CMMs is
equivalent to power cycling the chassis.
Care should be taken to prevent inhibiting all of the supplies in a chassis as well as losing power to
both CMMs so that the reset condition does not occur.
Technical Product Specification
83
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Power Supplies
13.5
Inhibiting Power Supplies
Power supplies can be inhibited through the CMM. This is accomplished using the following
command:
cmmset -l chassis -d psinhibitN -v 0
Where N is the number of the power supply that is to be inhibited.
Note: When a non-IPMI supply is inhibited, a SEL entry is logged indicating a failure condition. When
the non-IPMI supply is enabled a SEL entry is logged indicating that the power supply has
recovered from a failure condition. This does not occur in current IPMI-compliant power supplies.
13.6
Enabling Power Supplies
To enable a supply which has been inhibited, issue the following command:
cmmset -l chassis -d psinhibitN -v 1
Where N is the number of the power supply that is to be enabled.
Note: When a non-IPMI supply is enabled a SEL entry is logged indicating that the power supply has
recovered from a failure condition. This is because when a non-IPMI supply is inhibited, a SEL
entry is logged indicating a failure condition. This does not occur in current IPMI-compliant power
supplies.
84
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Drone Mode SBC Support
14.0 Drone Mode SBC Support
An SBC is said to be “drone mode capable” if it can be configured to ignore the PCI_RST# signal
coming from the PCI bus when inserted in a peripheral slot in a CompactPCI chassis. In this “drone
mode,” the board is operating independently of the PCI bus.
Because it is not acting as a peripheral on the PCI bus, and therefore not dependant on the system
master for correct initialization and power up, the normal methods used by the CMM for power
sequencing a peripheral board do not apply to the drone board in that PCI segment. This allows two
things to occur for drone boards that normally wouldn’t occur for standard peripheral boards:
• A drone mode capable board can be powered up in a peripheral slot without the system master
slot being populated and running for that particular PCI segment.
• If the system slot board is extracted/goes unhealthy, the drone mode capable boards in that
particular PCI segment should not be powered off.
14.0.1
Adding a Drone Mode Capable SBC
The CMM maintains an internal table of drone mode capable SBCs. For the CMM to recognize a
drone mode capable board, it must also support IPMI 1.0 or above in addition to being able to
operate in a drone mode. To add a drone mode capable SBC to the table issue the following CLI
command, substituting the appropriate blade number for N:
cmmset -l bladeN -d IgnoresPCIRst -v 1
Once this command is issued, the CMM will send a GetDeviceID command to the blade and
retrieve its manufacturer and product ID. It then adds this information to its internal table of drone
mode capable SBCs. That drone mode capable SBC can now be configured to operate in drone
mode and placed in any node slot within the chassis thereafter.
The CMM will then treat any board whose manufacturer and product ID match the one listed in the
table as drone mode capable.
14.0.2
Removing a Drone Mode Capable SBC
To remove a drone mode SBC from the internal table on the CMM, issue the following command:
cmmset -l blade5 -d IgnoresPCIRst -v 0
This removes the listing for that manufacturer and product ID from the internal table on the CMM,
and any boards matching this manufacturer and product ID thereafter will be treated as standard
CompactPCI system or peripheral boards.
Technical Product Specification
85
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Drone Mode SBC Support
86
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Active vs. Offline Slots
15.0 Active vs. Offline Slots
A slot operating normally is in what is defined as an active mode. The CMM has the capability to
place a slot in an offline mode. In an offline mode the CMM ignores the HEALTHY # signal from
the board in terms of power sequencing, and also does not send any health events that occur on the
board. Placing a slot into offline mode allows for troubleshooting and debugging an unhealthy
board.
If the board has an IPMI controller on it that is powered by IPMB power (standby), the CMM can
access the IPMI controller and hardware monitors connected to it even if the board itself has
powered down. A slot in which a board goes unhealthy can be placed into the offline mode so that
the CMM can get information from the IPMI controller and hardware monitors on the board which
can be used to diagnose problems with the board.
15.1
15.2
Determining the State of a Slot
Slots are set by default to the active mode, which allows for normal CompactPCI operation. A
cmmget of the powerstate of a slot can be used to determine if a slot has been placed into an offline
on obtaining the powerstate of a slot.
Setting a Slot to Offline Mode
The following command will place a slot in offline mode:
cmmset -l bladeN -d powerstate -v offline
N is the number of the slot to be placed in an offline mode.
15.3
15.4
Setting a Slot to Active Mode
The following command will place a slot into the active mode for normal operation:
cmmset -l bladeN -d powerstate -v activate
N is the number of the slow to be placed into the active mode.
Limitations of the Offline Mode
The CMM does not deassert BD_SEL# and power to an offline slot. Thus, when presence for an
offline slot is queried, it will return as present even with the board extracted from the slot.
Also, because the CMM does not recognize board extractions/insertions in an offline slot due to
BD_SEL# remaining asserted, the slot should be placed into active mode before a new board is
inserted into a slot in the offline mode. If this is not done, the CMM retains all of the information of
the board that was in the slot when it was placed in the offline mode.
Technical Product Specification
87
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Active vs. Offline Slots
88
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Obtaining FRU Information
16.0 Obtaining FRU Information
The CMM has the ability to obtain FRU information from IPMI 1.0 and higher compliant devices.
The entire FRU can be retrieved, or individual fields from the FRU.
16.1
FRU Information
The FRU of an IPMI compliant device should be compliant with the “Platform Management FRU
Information Storage Definition v1.0.” In this specification, the FRU can contain information in
any, all or none of the following areas: chassis info, board info, and product info.
The CMM can query the entire FRU of a device, entire areas of a FRU, or individual fields in the
different areas of the FRU.
For detailed information on FRUs, please refer to the “Platform Management FRU Information
Storage Definition v1.0.”
16.2
FRU Query Syntax
To query FRU information, the CMM uses FRU as its target (-t) parameter. The format for
querying the FRU of a particular location is:
cmmget -l [location] -t fru -d [FRUdataitem]
Where location is the component for which the FRU information is to be retrieved from, and
FRUdataitem is the field(s) of the FRU which will be retrieved.
Table 41 lists the various FRU data items and the information they retrieve.
Table 41. Dataitems Used With FRU Target (-t) to Obtain FRU Information (Sheet 1 of 2)
Data Item
Description
all
Returns all FRU information for the location (Not supported over SNMP)
Lists all board area FRU information for the location (Not supported over
SNMP)
boardall
boarddescription
boardmanufacturer
boardpartnumber
boardserialnumber
Lists the description field in the FRU board area for the location
Lists the manufacturer field in the FRU board area for the location
Lists the part number field in the FRU board area for the location
Lists the serial number field in the FRU board area for the location
boardmanufacturedatetime Lists the manufacture date and time field in the FRU board area for the location
Lists all product area FRU information for the location (Not supported over
productall
SNMP)
productdescription
productmanufacturer
productmodel
Lists the description field in the FRU product area for the location
Lists the manufacturer field in the FRU product area for the location
Lists the model field in the FRU product area for the location
Lists the part number field in the FRU product area for the location
productpartnumber
Technical Product Specification
89
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Obtaining FRU Information
Table 41. Dataitems Used With FRU Target (-t) to Obtain FRU Information (Sheet 2 of 2)
Data Item
Description
productserialnumber
productrevision
chassisall
Lists the serial number field in the FRU product area for the location
Lists the revision field in the FRU product area for the location
Lists all chassis area FRU information for the location
chassispartnumber
chassisserialnumber
chassislocation
chassistype
Lists the part number field in the FRU chassis area for the location
Lists the serial number field in the FRU chassis area for the location
Lists the location field in the FRU chassis area for the location
Lists the type field in the FRU chassis area for the location
listdataitems
Displays a list of all of the FRU dataitems that can be queried for the FRU target
16.3
Chassis FRU Validity Check
Chassis FRU validity is read on a periodic basis (every 24 hrs). A reuse/redefinition of two
existing BIST FRU error messages in place when one or both of the Chassis FRU cannot be read.
When the FRU (usually primary) cannot be read, and another message for when both primary and
secondary cannot be read
"Primary FRU unreadable - using Secondary"
"FRU unreadable!"
These two error messages are now used if the chassis FRU is detected to be corrupt will be a SEL
entry and an error message will go into /home/log/error.log
90
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Fan Control and Monitoring
17.0 Fan Control and Monitoring
The CMM controls the fan speeds and the fan tray LEDs. In a healthy state (no events) the LED
changes to a green color. If any of the fan tray sensors (temperature, voltages, fan tachs) are in an
unhealthy state, the LED changes to orange.
17.1
Setting Fan Speed
The factory default fan speed is 100 percent. The user can set the fan speed to 100 percent, 80
percent and 0 percent of the full speed through any of the supported interfaces. Setting the fan
speed from the CMM changes the fan speeds for all of the fans in the chassis. Setting the fan speeds
to 0 percent turns off the fans.
Note: The fan speed setting is persistent between CMM reboots.
The following command can be used to set the fan speed:
cmmset -l chassis -d fanspeed -v [100, 80, 0]
Where the value is 100 for 100 percent, 80 for 80 percent, or 0 for off.
Note: Querying fanspeed on the CMM will always reflect what the fan speed value was set to, not what
the actual fan speed is.
17.1.1
Considerations for Turning Off the Fans
Some fan tray designs will not allow the fans to be turned off and will override the CMM setting
with hardware on the fan trays. The CMM cannot detect fan tray hardware that provides such an
override. Consult the fan tray or chassis documentation for further information on setting fan
speeds.
For fan trays that do not allow fans to be turned off, querying the fanspeed on the CMM after
setting it to zero will still show the fanspeed as set to zero because this is what is being output by
the CMM.
Also, setting the fan speed to 0 (off) will override the automatic fan control of the CMM.
Temperature and fan tray events will no longer cause the CMM to drive the fans to full speed.
17.2
Automatic Fan Control
The CMM will drive the fans to full speed (100 percent) under any of the following conditions:
• An upper temperature threshold is violated in the platform, including blades.
• A fan tray is removed from the chassis.
• A fan tachometer crosses a lower threshold.
• A fan board controller has a failure.
The fans are also driven to full speed automatically if both CMMs are removed from the chassis.
Technical Product Specification
91
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Fan Control and Monitoring
Note: Once the CMM automatically drives the fan speeds to 100 percent because of one of the above
health events, it is still possible to set the fan speeds to 80 or 0 through the supported interfaces
(CLI, etc). Once the automatic override of the fan speeds has been deactivated by resetting the fan
speed to 80 or 0, the fans will remain at the newly set speed even after the condition that caused the
automatic override has cleared.
17.3
Querying Fan Tray Sensors
To query the fan trays and fan tray sensors, use fantrayN as the location (-l) of the cmmget
command, where N is the number of the fan tray being queried. For example, to query the current
value of FANTK1 on fantray1, issue the command:
cmmget -l fantray1 -t “FANTK1” -d current
92
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Scripting
18.0 CMM Scripting
18.1
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. Next it would find out what fan sensors are in each fan tray. Finally it
would call the CLI to get the current speeds of each of the fans.
Scripts can be written directly on the CMM and should be saved on the CMM as a file in flash in
the /home/scripts directory.
18.1.1
Script Synchronization
Script files are not synchronized automatically when copied or changed (by deleting, renaming,
altering its chown/chmod/chgrp permissions, etc) in the /home/scripts directory on the active
CMM. The Linux “touch” command should be issued to the /home/scripts directory on the active
CMM to synchronize the scripts. Scripts are automatically synchronized on any full
synchronization (chassis power up, insertion of a new CMM) as well as when they are edited (i.e.,
using vi and writing the file).
Scripts need to be deleted from both CMMs manually. Deleting a script on the active CMM does
not automatically delete the script on the standby.
Note: Scripts are always synchronized from the active CMM to the standby CMM. Adding, editing, or
modifying scripts on the standby CMM should be done with caution, and will need to be manually
copied to the active CMM.
18.2
Associating Scripts to Event Severity
Health events triggered on the CMM can be used to execute scripts stored locally in the
/home/scripts directory. Any level of an event can be used as a trigger: normal, minor, major, and
critical.The CLI command for associating a script with an event is:
cmmset –l [location] –t [target] –d [action type] –v [script]
Location is the component in the chassis that the health event is associated with.
Target is the sensor to be triggered on.
Action type is NormalAction, MinorAction, MajorAction, or CriticalAction based upon the
severity of the event to be triggered on.
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.
Technical Product Specification
93
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Scripting
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).
For example, if you wanted to run a blade powerdown script called “powerbladedown” stored in
/home/scripts when the ambient temperature triggered a major event for a blade 4, the command
would be:
cmmset –l blade4 –t “Ambient Temp” –d MajorAction –v “bladepowerdown 4”
In this example, the /home/scripts/bladepowerdown script or executable will be executed with “4”
as a parameter when blade4’s Ambient Temp sensor generates a major health event.
18.2.1
18.2.2
Listing Scripts Associated With Events
The scripts that are associated with events are put into the /etc/cmm.cfg file. To display a list of
scripts associated with events, cat the /etc/cmm.cfg file.
For further information on event scripting commands and its arguments, see Section 7.0, “CMM
Removing Scripts From an Associated Event
To remove scripts from occurring for an event in which they have been associated, issue the
following command:
cmmset –l [location] –t [target] –d [action type] –v none
Location is the component in the chassis that the health event is associated with.
Target is the sensor that was being triggered on.
Action type is NormalAction, MinorAction, MajorAction, or CriticalAction based upon the
severity of the event that was being triggered on.
18.3
Setting Scripts for Specific Individual Events
The CMM allows scripts to be associated with specific events which may not necessarily be health
related, such as the insertion or removal of a board from the chassis. This allows any single event
that can occur on the CMM to have an associated script, or scripts with it.
18.3.1
Event Codes
To allow the user to set scripts based on any event, a unique event code is assigned to each event
that can occur on the CMM. The list of events and the codes associated with each event is detailed
.
94
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Scripting
18.4
18.5
Setting Event Scripts
Setting event 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 cmm.cfg file and is synced to the standby CMM. It is persistent
across boots.
Slot Events
The CMM treats slot related events by assigning a sensor to each slot. These sensors will be called
"Slot X Event" where X is the slot number. These will be discrete sensors and will show up in the
chassis "listtargets" command. This allows an event script like to be associated to slot related
events like any other sensor type.
For example, to launch a script called "Notify" when blade 5 is removed, the user would execute:
cmmset -l chassis -t "Slot 5 Event" -d EventAction -v [Removal Event
Code]:Notify
Assigning sensors to slot based events affects the strings shown in SNMP traps and SEL entries for
slot events. The SEL entry and trap messages will now reflect the following:
Slot [Blade Number] Event [Event]
Where Event will be a string such as "Blade inserted", "Slot powered off", etc.
Technical Product Specification
95
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
CMM Scripting
96
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
SNMP
19.0 SNMP
The CMM supports the Simple Network Management Protocol (SNMP). The CMM can support
SNMP queries and send SNMP traps in 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.
The following diagram shows the high-level layout of the SNMP/MIB components and the flow of
the data via SNMP protocol.
Figure 11. High Level SNMP/MIB Layout
MIB/SNMP Manager
DMM MIB
Get/
Get-next/
Set
SNMP Trap
CMM
SNMP
Agent
CMM/MIB-ll
Modules
(calls API)
SNMP Trap
Utility
CMM API
Linux*
System Call
CMM Management
Software
* Other names and brands may be claimed as property of others.
B0473-01
Technical Product Specification
97
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
SNMP
19.1
19.2
CMM MIB
The CMM comes with a text file (ZT 7102.mib) that describes the CMM objects to be managed, as
well as all of the managed objects in the platform. 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 ZT 7102.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.
MIB Design
The CMM supports the following MIB II objects. The writeable objects can be set in their
respective fields in the /etc/snmpd.conf file.
Table 42. MIB II Objects - System Group
Object
Syntax
Size
Access
Value
“Linux ZT 7102 2.4.2-1 #156 [DATE] armv5”
Date is the actual current date.
sysDscr
DisplayString
0..127
read-only
iso(1).org(3).dod(6).internet(1).private(4).enter
prises(1).intel(343).products(2).Chassis-Mana
gement(14).ZT 7102(1)
OBJECT
IDENTIFIER
sysObjectID
read-only
sysUpTime
sysContact
sysName
Days and Time
DisplayString
DisplayString
DisplayString
read-only
read-write
read-write
read-only
Time since ZT7102 began running
max. 128 bytes
0..127
0..8
Default:”ZT 7102”
sysLocation
0..127
Table 43. MIB II - Interface Group
Object
Syntax
Size
0..127
Access
Value
ifDscr
DisplayString
read-only
10/100BASE-TX
19.2.1
19.2.2
CMM MIB Objects
Detailed descriptions of the MIB objects can be found in the ZT7102.mib file located on the CMM.
Querying Non-IPMI Compliant Blades and Power Supplies
Slot control is a target that is specific to SNMP that is displayed in response to a listtargets
command when used on an unoccupied slot in the chassis. This target is not available if the slot is
occupied. The Slot Control target allows the user to perform other commands against that slot
without an IPMI-compliant blade or IPMI-compliant power supply present.
19.3
SNMP Agent
The SNMP agent (snmpd) listens to SNMP v1 queries (gets/sets) by default, evokes the
corresponding MIB Module to process the request, and sends the SNMP response with return data
to the SNMP/MIB manager. All SNMP “set” queries are logged in the command log file.
98
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
SNMP
Note: Changing IP addresses when using SNMP v3 will require a restart of the snmpd process. This is
due to SNMP v3 using the IP address to generate the encryption keys. To restart the snmpd process
19.3.1
Configuring the SNMP Agent Port
The SNMP agent is set up to use port 161 by default. The port can be configured to use a different
port number by adding the following line to the snmpd.conf file:
agentaddress port_number
19.3.2
Configuring the Agent to Respond to SNMP v3 Requests
The agent can also be configured to respond to SNMP v3 queries, in which case it checks the
security, decodes the request, then evokes the corresponding MIB Module to process the request,
and sends the SNMP response with return data to the SNMP/MIB manager. SNMP v3 adds support
for strong authentication and private communication.
To change the SNMP agent to respond to SNMP v3 queries:
1. Copy /etc/snmpdv3.conf to /etc/snmpd.conf.
2. Find the process ID of the snmpd process by issuing the command:
ps -ax
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.
19.3.3
19.3.4
Configuring the Agent Back to SNMP v1
To reconfigure the agent back to SNMP v1, follow the same steps as above, substituting the
/etc/snmpdv1.conf for /etc/snmpdv3.conf. The rest of the process is the same.
Setting up an SNMP v3 MIB Browser
To manage the CMM via SNMPv3 MIB browser/manager (mg-soft, net-snmp, etc.), the user needs
to configure the browser with the following parameters:
1. Load and compile the ZT 7102.MIB file
2. Set the SNMPv3 security parameters:
— Set SNMPv3 agent user
— At default, User: root
— Set the MD5 Authentication password: cmmrootpass
— Set the DES Encryption password: cmmrootpass
Technical Product Specification
99
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
SNMP
19.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. The SNMP
trap port can also be configured. For a description of all the traps that are issued, refer to Section
19.4.1
Configuring the SNMP Trap Port
To configure the SNMP Trap Port to a different port number, issue the command:
cmmset -l cmm -d SNMPTrapPort -v [Port Number]
Where Port Number is the desired SNMP Trap Port number.
19.4.2
19.4.3
Configuring the CMM to Send SNMP v3 Traps
To configure the CMM to send SNMP v3 Traps, issue the command:
cmmset -l cmm -d SNMPTrapVersion -v v3
Configuring the CMM to Send SNMP v1 Traps
To configure the CMM to send SNMP v1 Traps, issue the command:
cmmset -l cmm -d SNMPTrapVersion -v v1
19.5
Configuring and Enabling SNMP Trap Addresses
The CMM allows up to five SNMP trap addresses destinations, SNMPTrapAddress1-5. In
redundant CMM systems, SNMP Trap Address 1 MUST be set to a valid IP address on the
network that the CMM can ping to at all times. This is used as a test of network connectivity as
well as being the first SNMP Trap Address.
19.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.
19.5.2
Enabling and Disabling SNMP Traps
SNMP Trap addresses are enabled by default. To disable SNMP traps, issue the command:
cmmset -l cmm -d SNMPenable -v disable
To enable SNMP trap addresses, issue the command:
cmmset -l cmm -d SNMPenable -v enable
100
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
SNMP
To check the status of SNMP traps, issue the command:
cmmget -l cmm -d SNMPenable
19.5.3
Alerts Using SNMPv3
The CMM utilizes the SNMPtrap utility to send the SNMPv3 ‘trap’ message. For receiving the
SNMPv3 Trap, the remote application such as the trap listener needs to:
1. Set the SNMPv3 Trap User. The default trap user is root.
2. Set the MD5 Authentication password. The default MD5 Authentication password: is
publiccmm.
3. Set the DES Encryption password. The default DES Encryption password is publiccmm.
Note: To change the passwords (MD5 and DES) for SNMPv3 trap, change the snmpTrapCommunity
from the CLI interface or from the SNMP manager console.
19.5.4
Alert Using UDP Alert
The CMM Management software also sends the alert via UDP port 10000. The IP address to
receive this alert is the same as the SNMP Trap IP addresses. The UDP alert is enabled by default
when the user enables SNMP traps.
19.6
Security Model
19.6.1
SNMPv3 Security: Authentication Protocol and Privacy Protocol
The CMM supports the highest security level for SNMPv3. The MD5 is used for authentication
Protocol in the CMM. The DES is used for Privacy Protocol in the CMM. When in this mode, the
user needs to specify each password (authKey, privKey) for these protocols. The SNMPv3 packet
is securely encrypted during the transmission.
This is the default security level of the CMM when configured for SNMP v3.
The following fields are defined to handle all SNMPv3 security levels:
Table 44. SNMPv3 Security Fields
SecurityName
user name
Default Value:
AuthProtocol
AuthKey
authentication type (MD5)
authentication password
privacy type (DES)
publiccmm
publiccmm
PrivProtocol
PrivKey
privacy password
19.7
snmpd.conf
For more information regarding SNMP configuration, and the snmpd.conf file, please visit:
Technical Product Specification
101
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
SNMP
102
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
20.0 RPC
In addition to the command-line interface, the CMM may be administered by custom remote
applications through an RPC.
RPC calls are useful for managing the CMM from:
• A remote machine through the management network
• Another blade in the same chassis as the CMM, through the chassis backplane network
• An application running on the CMM itself
The RPC interface supports the same functionality as the command-line interface.
Note: System Event Log (SEL) information is currently not available through the RPC interface.
20.1
Setting Up the RPC Interface
Before you can use RPC calls in a custom application, you must download the following RPC
source code files from the Intel developer web site located at:
• rcliapi.h
• rcliapi_xdr.c
• rcliapi_clnt.c
• cli_client.c
• cli_client.h
The first three files should be compiled and linked into the application under development. These
files implement the RPC calling subsystem for use in an application.
The file cli_client.c contains a small sample program for calling the CMM through RPC. These
files currently support Linux and VxWorks*. Future revisions may support Microsoft* Windows*.
The last file, cli_client.h, contains declarations and function prototypes necessary for interfacing
with the RPC calling subsystem. Include the file in a ‘#include’ statement in all application files
that make RPC calls.
20.2
Using the RPC Interface
The RPC interface may be used to manage the CMM whether the calling application is on a remote
network, on a blade in the same chassis as the CMM, or even running on the CMM itself.
The following two functions are defined by the RPC subsystem for calling the CMM through RPC:
• GetAuthCapability()
• ChassisManagementApi()
Technical Product Specification
103
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
20.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.
E_RPC_INIT_FAIL
RPC initialization failure.
E_RPC_COMM_FAIL
RPC communication failure.
GetAuthCapability is used to authenticate the calling application with the remote CMM. The
remote CMM will not respond to RPC communications until the application has successfully
authenticated. To authenticate, the application will need to pass the CMM’s current IP address,
username and password to GetAuthCapability(). The default username and password are ‘root’ and
‘cmmrootpass’. When the authentication is successful authentication, GetAuthCapability() will
return an authentication code for use with all further RPC communication.
Note: Clients will need to re-authenticate to the CMM whenever the CMM is reset. Re-authentication is
necessary when ChassisManagementApi() returns E_ECMM_SVR_AUTH_CODE_FAIL.
20.2.2
ChassisManagementApi()
The following is the calling syntax for ChassisManagementApi():
int ChassisManagementApi(
char*
int
unsigned int
pszCMMHost,
nAuthCode,
uCmdCode,
unsigned char* pszLocation,
unsigned char* pszTarget,
unsigned char * pszDataItem,
unsigned char * pszSetData,
104
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
void **
unsigned int *
ppvbuffer,
uReturnType
);
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). When not applicable, use "NA” (such
as when pszDataItem is an attribute of the pszLocation rather than pszTarget.
pszDataItem
[in] The attribute that uCmdCode acts upon, either an attribute of pszLocation or
pszTarget.
pszSetData
[in] The new value to set. When not applicable, use "NA”.
ppvbuffer
[out] A pointer to the buffer containing the returned data.
uReturnType
[out] The type of data that ppvbuffer points to (see the defines in cli_client.h).
Once the application has authenticated, it may proceed to get and set CMM parameters by calling
ChassisManagementApi(). For each call to ChassisManagementApi(), the calling application must
pass in the authentication code returned from GetAuthCapability(). The get and set commands
available through ChassisManagementApi() are the same as those available on the command-line
interface with cmmget and cmmset.
Note: System Event Log (SEL) information is currently not available through the RPC interface. This
limitation may be removed in a future CMM firmware release.
For more information on the command-line interface, see Section 8.0, “Command Line Interface
Technical Product Specification
105
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 45. Error and Return Codes for the RPC Interface (Sheet 1 of 4)
Code #: Error Code String
Error Code Description
0
1
2
E_SUCCESS
Success
E_BPM_BLADE_NOT_PRESENT
Blade isn't in the chassis
ECMM_SVR: Unsupported Command
Error
E_ECMM_SVR_COMMAND_UNSUPPORTED
3
4
E_CLI_MSG_SND
CLI Send Message Error
E_CLI_INVALID_TARGET
Not a valid -t parameter.
5
E_CLI_INVALID_LOCATION
E_CLI_INVALID_DATA_ITEM
E_CLI_INVALID_SET_DATA
E_CLI_INVALID_REQUEST
E_CLI_MSG_RCV
Not a valid -l location.
6
Not a valid -d parameter.
7
Not a valid -v parameter.
8
CLI Invalid Request Error
CLI Receive Message Error
No data found to retrieve.
CLI Data Type Unsupported
ECMM_CLIENT: RPC Connect Error
Invalid auth code passed to RPC interface
9
10
11
12
13
14
E_CLI_NO_MORE_DATA
E_CLI_DATA_TYPE_UNSUPPORTED
E_ECMM_CLIENT_CONNECT_ERROR
E_ECMM_SVR_AUTH_CODE_FAIL
Operation cannot Be Performed on
Standby CMM
E_CLI_STANDBY_CMM
15
The CMM is Initializing and Not Ready.
Wait a few seconds and try again.
E_WP_INITIALIZING
16
17
E_BPM_NON_IPMI_BLADE
E_BPM_STANDBY_CMM
Blade does not support IPMI
BPM Operation cannot Be Performed on
Standby CMM
18
Couldn't delete a board from the drone
mode list
E_BPM_NO_MORE_DATA
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
E_BPM_INVALID_SET_DATA
E_CLI_INVALID_BUFFER
E_CLI_INVALID_CMM_SLOT
E_CLI_NO_MSGQ_KEY
E_CLI_NO_MSGQ
Not a valid -v parameter
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
E_CLI_NO_MSGQ_LOCK
E_CLI_NO_MSGQ_UNLOCK
E_CLI_FILE_OPEN_ERROR
E_CLI_CFG_WRITE_ERROR
E_IMB_NO_MSGQ
Internal CMM Error
Internal CMM Error
Internal CMM Error
CMM Config File Error
Internal CMM Error
E_IMB_NO_MSGQ_KEY
E_IMB_SEND_TIMEOUT
E_IMB_DRIVER_FAILURE
E_IMB_REQ_TIMEOUT
E_IMB_RECEIVE_TIMEOUT
Internal CMM Error
Internal CMM Error
Internal CMM Error
A blade is not responding to IPMI requests.
A blade is not responding to IPMI requests.
106
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 45. Error and Return Codes for the RPC Interface (Sheet 2 of 4)
Code #: Error Code String
Error Code Description
34
An IPMI request returned with a non
successful completion code. User should
try the command again.
E_IMB_COMPCODE_ERROR
35
36
37
Invalid IPMI response. Blade may be
returning invalid data.
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
38
39
40
41
42
43
E_IMB_DATA_COPY_FAILED
E_IMB_INVALID_EVENT
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
E_IMB_OPEN_DEVICE_FAILED
E_IMB_MMAP_FAILED
E_IMB_MUNMAP_FAILED
Invalid IPMI response. Blade may be
returning invalid data.
E_IMB_RESP_LEN_ERROR
E_NEM_SNMPTRAP_ERROR
44
Error setting snmptrap parameters. Retry
command
45
46
47
48
49
50
51
52
53
54
E_NEM_SYSTEMHEALTH_ERROR
E_NEM_GETHEALTH_ERROR
E_NEM_SNMPENABLE_ERROR
E_NEM_SENSOR_HEALTH_ERROR
E_NEM_FILTER_SEL_ERROR
E_NEM_INITIALIZE_ERROR
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
E_NEM_SENSOR_EVENT
E_NEM_SENSOR_ERROR
E_NEM_SNMP_PROCESS_EVENT_ERROR
SNMP Trap address that the user is setting
is invalid
E_NEM_SNMP_DEST_ADDR_ERROR
E_NEM_SNMP_COMMUNITY_STRING_ERROR
E_NEM_SNMP_TRAP_VERSION_ERROR
E_NEM_SNMP_TRAP_PORT_ERROR
E_NEM_SNMP_CFG_ERROR
55
56
57
58
SNMP Community that user is setting is
invalid
SNMP Trap version that the user is setting
is invalid
SNMP Trap port that the user is setting is
invalid
Cannot read SNMP config parameter.
Config file may be corrupted.
59
60
61
E_NEM_SEND_SNMP_TRAP_ERROR
E_SFS_INVALID_TRANSACTION
Internal CMM Error
Internal CMM Error
Can't read SDRs. Blade may be busy, try
again.
E_SFS_LOCK_SDR
62
63
E_SFS_ENTITY_ID
Internal CMM Error
Internal CMM Error
E_SFS_DEVICE_LOCATOR_NULL
Technical Product Specification
107
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 45. Error and Return Codes for the RPC Interface (Sheet 3 of 4)
Code #: Error Code String
Error Code Description
64
65
66
67
68
69
70
71
72
73
74
75
76
E_SFS_NO_MEMORY
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Not a valid -d parameter
E_SFS_UNSUPPORTED_DEVICE
E_SFS_RESPONSE_LENGTH
E_SFS_RESPONSE_DATA
E_SFS_POWER_SUPPLY_FRU
E_SFS_PATTERN_FOUND
E_SFS_SEMAPHORE_FAILED
E_SFS_CALLBACK_NOT_FOUND
E_SFS_END_OF_DATA
E_SFS_NO_SEL_ENTRY
E_SHEM_INTERNAL_ERROR
E_SHEM_INVALID_DATA_ITEM
Can't execute this command on the
standby CMM
E_SHEM_STANDBY_CMM
77
78
79
80
81
82
83
84
85
86
87
88
89
90
E_SNSR_STATUS_UNSUPPORTED
E_SNSR_UNSUPPORTED
E_SNSR_CATEGORY
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
E_SNSR_NO_MEMORY
E_SNSR_NOT_FOUND
E_SNSR_ACTION_UNSUPPORTED
E_SNSR_NON_FIRMWARE
E_SNSR_SHARE_CODE
E_SNSR_LOW_STORAGE
E_SNSR_EVENT_TYPE
E_SNSR_INVALID_REQUEST
E_SNSR_OS_ERROR
E_SNSR_PROCESSOR_NOT_PRESENT
The sensor being queried doesn't support a
particular threshold
E_SNSR_THRESHOLD_UNSUPPORTED
91
92
93
94
95
96
97
98
99
E_SNSR_CAPABILITY_UNSUPPORTED
E_SNSR_SCANNING_DISABLED
E_SNSR_MAX_RETRIES
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
E_SNSR_TRIGGER_TYPE
E_SNSR_STATE
E_SNSR_EVENT_DEREGISTER
E_SNSR_SEL_EVENT_FUNCTION
E_SNSR_BASE_INDEX
E_SNSR_PRESENCE_DETECTED
108
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 45. Error and Return Codes for the RPC Interface (Sheet 4 of 4)
Code #: Error Code String
Error Code Description
100
101
102
103
104
105
106
107
E_SNMP_CMD_UNSUPPORTED
Internal CMM Error
E_SNMP_ERROR
Internal CMM Error
E_SNSR_VALUE_OUT_OF_RANGE
E_SNSR_AUTH_ERROR
E_WP_INITIALIZE_LIBS
Internal CMM Error
Internal CMM Error
Internal CMM Error
E_WP_CFG_READ_ERROR
E_WP_CFG_WRITE_ERROR
CMM config file may be corrupted
CMM config file may be corrupted
The sensor being queried doesn't support a
particular threshold.
E_WP_THRESHOLD_UNSUPPORTED
E_WP_INVALID_TARGET
108
The sensor doesn't support a "current”
value. This happens when querying a
current value on a discrete sensor type.
109
110
111
112
113
E_WP_INVALID_LOCATION
E_WP_INVALID_DATA_ITEM
E_WP_INVALID_SET_DATA
E_WP_CMD_UNSUPPORTED
Not a valid -l location
Not a valid -d parameter
Not a valid -v parameter
Not a supported command
Can't execute this command on the
standby CMM.
E_WP_STANDBY_CMM
114
115
116
117
118
119
120
121
122
E_WP_I2C_ERROR
Internal CMM Error
Internal CMM Error
Internal CMM Error
Internal CMM Error
Power Supply Not Present Error
Internal CMM Error
Internal CMM Error
Update in Progress
Initilization message
E_FT_SEM_GET_FAILURE
E_DRONE_NOT_FOUND
E_INTERNAL_ERROR
E_BPM_PWR_SUPPLY_NOT_PRESENT
E_NEM_INTERNAL_FAILURE
E_WP_CMM_RESET
E_UPDATE_INPROGRESS
E_MSGQ_START
Note: Error codes 100 and 101 will never be returned by the CMM when using RPC. If you receive these
error codes, they are most likely being returned by the RPC client. Consult your RPC client
documentation or code to find the description of these errors.
20.2.3
ChassisManagementApi() Threshold Response Format
The following table documents the format of ChassisManagementApi() queries that return data of
type DATA_TYPE_ALL_THRESHOLDS.
Technical Product Specification
109
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 46. Threshold Response Formats
Dataitem
Return format
Example
Data is returned in the
THRESHOLDS_ALL structure as defined
in cli_client.h. All structure fields are valid.
5.400 Volts
5.200 Volts
5.100 Volts
4.600 Volts
4.800 Volts
4.900 Volts
If a particular threshold is not supported,
the structure field will contain an empty
string.
thresholdsall
Each supported and valid field is a
null-terminated string.
Syntax:
[Value] [Units] /n /0
Data is returned in the
THRESHOLDS_ALL structure defined in
cli_client.h. Only the structure field
corresponding to the dataitem requested
is valid.
uppernonrecoverable
uppercritical
uppernoncritical
lowernonrecoverable
lowercritical
If a particular threshold is not supported,
the structure field will contain an empty
string.
5.160 Volts
A valid field is a null-terminated string.
Syntax:
lowernoncritical
[Value] [Units] /n /0
20.2.4
ChassisManagementApi() String Response Format
The following table documents the format of ChassisManagementApi() queries that return data of
type DATA_TYPE_STRING.
Table 47. String Response Formats (Sheet 1 of 4)
Dataitem
Return format
Example
Null-terminated string showing the current
value of a sensor.
current
23.000 Celsius
Syntax:
Value [Units] /0
Null-terminated string showing the
orientation of the eth0 Ethernet port:
Ethernet
fanspeed
front
80
Syntax:
[front/back] /0
Null-terminated string giving the current
CMM fan speed setting:
Syntax:
[0 or 80 or 100] /0
110
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 47. String Response Formats (Sheet 2 of 4)
Dataitem
Return format
Example
Major Event: Fan Tray 3 Pres Fan
Tray Removed
List of human-readable health events. Lines
are separated by line feeds with a
null-terminator at the end.
Major Event: FANTK9 Lower critical
going low asserted
"(null)” or "" if there are no healthevents
Major Event: FANTK8 Lower critical
going low asserted
healthevents
Refer to Section 11.0, “Health Event Strings”
Major Event: FANTK7 Lower critical
going low asserted
Syntax:
[Critical/Major/Minor] Event: [Health String]
/n /0
Minor Event: BP +12V Upper
non-critical going high asserted
presence
listtargets
listdataitems
health
healthevents
sel
List of available dataitems. Lines are
separated by line feeds and a null-terminator snmpenable
at the end.
ListDataItems
snmptrapcommunity
Syntax:
snmptrapaddress1
snmptrapaddress2
snmptrapaddress3
snmptrapaddress4
snmptrapaddress5
redundancy
[Dataitem] /n /0
powerstate
List of available targets. Targets represent
the sensor data records (SDRs) for a
particular component. Lines are separated
by line feeds with a null-terminator at the
end.
Brd Temp
+1.5 V
+2.5 V
+3.3 V
+5 V
ListTargets
location
Syntax:
[Sensor Name] /n /0
Null-terminated string containing the
user-specified physical location of the CMM,
16 characters maximum.
Server room 3
Syntax:
[Location String] /0
Human readable powerstate information
containing the target blade powerstate
information. Lines are separated by line
feeds with a null-terminator at the end.
Board is present
Syntax:
Board HEALTHY# signal is asserted
Board is [present or not present] /n
powerstate
Board has been powered up by the
CMM
Board HEALTHY# signal is [asserted or not
asserted /n
Board is in active mode.
Board has [not] been powered up by the
CMM /n
Board is in [active or offline] mode. /n /0
Technical Product Specification
111
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 47. String Response Formats (Sheet 3 of 4)
Dataitem
Return format
Example
Human-readable redundancy information
containing the current CMM redundancy
status. Lines are separated by line feeds with
a null-terminator at the end.
Top CMM (CMM 1): Present (active) *
Bottom CMM (CMM 2): Not Present
Syntax:
redundancy
Top CMM (CMM 1): [Present or Not Present] (standby)
([active or standby]) [* or no star] /n
* = The CMM you are currently
Bottom CMM (CMM 2): [Present or Not
logged into.
Present] ([active or standby) [* or no star] /n
* = The CMM you are currently logged into.
/n /0
Human-readable slot information, containing
a list of System slots, Peripheral slots,
Busless slots, and Occupied slots. If there
are no slots in a particular category, "None”
is reported.
Lines are separated by line feeds with a
null-terminator at the end. Each colon is
followed by one tab (for Peripheral and
Busless slots) or two tabs (for System and
System Slot(s): None
Peripheral Slot(s): 2 3 4 5 6 7 8 13 14
Occupied slots) and a space-delimited list of 15 16 17 18 19 20 21
slot numbers.
slotinfo
Busless (Switch) Slot(s): 2 19 20 21
Syntax:
Occupied Slot(s): 2 5 21
System Slot(s): [None or slot numbers] /n
Peripheral Slot(s): [None or slot numbers] /n
Busless (Switch) Slot(s): [None or slot
numbers] /n
Occupied Slot(s): [None or slot numbers] /n
/0
Null-terminated string containing a
dotted-quad IP address
snmptrapaddress[1..5]
snmptrapcommunity
snmptrapport
10.10.240.81
publiccmm
161
Syntax:
XXX.XXX.XXX.XXX /0
Null-terminated string containing the
snmptrapcommunity name
Syntax:
[SNMP Trap Community Name String] /0
Null-terminated string showing the SNMP
trap port.
Syntax:
[port number] /0
Null-terminated string showing the version of
SNMP traps the CMM is currently set for.
snmptrapversion
v3
Syntax:
[v1 or v3] /0
112
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 47. String Response Formats (Sheet 4 of 4)
Dataitem
Return format
Example
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.
Lines are separated by line feeds with a
null-terminator at the end. Each colon is
followed by one space and a space-delimited
Critical: None
unhealthylocations
list of blade numbers and the word "chassis” Major: None
for chassis health conditions.
Minor: 8 chassis
Syntax:
Critical: [None or Blade# and/or chassis
and/or cmm] /n
Major: [None or Blade# and/or chassis
and/or cmm] /n
Minor: [None or Blade# and/or chassis
and/or cmm] /n /0
Null-terminated string containing the version
of the CMM firmware.
version
V03.00a
Syntax:
VXX.XXX /0
20.2.5
ChassisManagementApi() Integer Response Format
The following table documents the format of ChassisManagementApi() queries that return data of
type DATA_TYPE_INT.
Table 48. Integer Response Formats (Sheet 1 of 2)
Dataitem
Return format
Example
Integer value indicating alarm cutoff
status:
alarmcutoff
0
5
0 = alarm not cut off
1 = alarm cut off
Integer value indicating the alarm cutoff
timeout in minutes.
alarmtimeout
health
Integer value corresponding to the
health of the location queried:
0 = OK
2
1 = Minor
2 = Major
3 = Critical
Integer value corresponding to the
absence or presence of the location
queried:
0 = Not present
presence
1
1 = Present
NOTE: If a blade is not present,
ChassisManagementApi()
returns
E_BLADE_NOT_PRESENT.
Technical Product Specification
113
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 48. Integer Response Formats (Sheet 2 of 2)
Dataitem
Return format
Example
Integer returned is a 1 or 0.
1 = Power supply is not inhibited
0 = Power supply is inhibited
psinhibit
1
0
Integer value indicating SNMP status:
0 = disabled
snmpenable
1 = enabled
20.2.6
FRU String Response Format
Querying an individual FRU field returns a null terminated string with a single line feed.
Querying individual FRU areas returns a null terminated string with the following:
Board Area:
Product Area:
Chassis Area:
3 Linefeeds
2 Linefeeds
2 Linefeeds
Querying the entire FRU (all) will return all of the above areas present in the FRU with the line
feeds listed above.
Table 49. FRU Data Items String Response Format (Sheet 1 of 2)
Data Item
Description
all
Null-terminated string containing all FRU information for the location
Null-terminated string containing all board area FRU information for the
location
boardall
Null-terminated string containing the description field in the FRU board area
for the location
boarddescription
boardmanufacturer
boardpartnumber
boardserialnumber
boardmanufacturedatetime
productall
Null-terminated string containing the manufacturer field in the FRU board
area for the location
Null-terminated string containing the part number field in the FRU board area
for the location
Null-terminated string containing the serial number field in the FRU board
area for the location
Null-terminated string containing the manufacture date and time field in the
FRU board area for the location
Null-terminated string containing the product area FRU information for the
location
Null-terminated string containing the description field in the FRU product area
for the location
productdescription
productmanufacturer
productmodel
Null-terminated string containing the manufacturer field in the FRU product
area for the location
Null-terminated string containing the model field in the FRU product area for
the location
Null-terminated string containing the part number field in the FRU product
area for the location
productpartnumber
114
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 49. FRU Data Items String Response Format (Sheet 2 of 2)
Data Item
Description
Null-terminated string containing the serial number field in the FRU product
area for the location
productserialnumber
Null-terminated string containing the revision field in the FRU product area
for the location
productrevision
productmanufacturedatetime
chassisall
Null-terminated string containing the manufacturer date and time field in the
FRU product area for the location
Null-terminated string containing all chassis area FRU information for the
location
Null-terminated string containing the part number field in the FRU chassis
area for the location
chassispartnumber
chassisserialnumber
chassislocation
chassistype
Null-terminated string containing the serial number field in the FRU chassis
area for the location
Null-terminated string containing the location field in the FRU chassis area
for the location
Null-terminated string containing the type field in the FRU chassis area for
the location.
Null-terminated string containing the list of all of the FRU dataitems that can
be queried for the FRU target
listdataitems
20.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(). When the
authentication is successful, the user’s command-line arguments (for Linux) or calling parameters
(for VxWorks) are passed to the CMM through ChassisManagementApi(). The return code is then
checked and the result is printed to the console.
20.4
RPC Usage Examples
Table 50 presents examples of using RPC calls to get and set fields on the CMM. Data returned by
RPC calls are returned in the ppvbuffer and uReturnType parameters to ChassisManagementApi().
Technical Product Specification
115
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 50. RPC Usage Examples (Sheet 1 of 3)
ChassisManagementApi() [in]
Example
ChassisManagementApi() [out] parameters
parameters
pszCMMHost: localhost
uCmdCode: CMD_GET
uReturnType: DATA_TYPE_STRING
Get the
chassis
temperature.
pszLocation: Chassis
ppvbuffer: A null-terminated string of the format:
Value [Units]
pszTarget: TempSensorName
pszDataItem: current
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: fantray1..3
pszTarget: NA
uReturnType: DATA_TYPE_INT
ppvbuffer: Integer value indicating presence
1 = Present
Get the fan
tray presence.
0 = Not Present
pszDataItem: presence
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: blade5
uReturnType: DATA_TYPE_STRING
Get the CPU
temperature
of blade 5.
ppvbuffer: A null-terminated string of the format:
Value [Units]
pszTarget: CPUTempSensorName
pszDataItem: current
uReturnType: DATA_TYPE_INT
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: blade[1-n]
pszDataItem: presence
ppvbuffer:
1 = Present
Determine if a
certain blade
is present.
The call to ChassisManagementApi() returns
E_BLADE_NOT_PRESENT if the selected blade
is not present.
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: blade2
Get all
uReturnType: DATA_TYPE_ALL_THRESHOLDS
thresholds for
the +3.3 V
sensor on
blade 2.
ppvbuffer: A THRESHOLDS_ALL structure as
defined in cli_client.h
pszTarget: 3.3vSensorName
pszDataItem: ThresholdsAll
uReturnType: DATA_TYPE_INT
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: system
pszDataItem: health
ppvbuffer: Integer value denoting health state
Get the
overall
system
health.
0 = OK
1 = Minor
2 = Major
3 = Critical
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: system
Get a list of
blades with
problems.
uReturnType: DATA_TYPE_STRING
ppvbuffer: List of all blades with problems
pszDataItem: unhealthylocations
uReturnType: DATA_TYPE_INT
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: blade5
ppvbuffer: Integer value denoting health state
Get the temp1
sensor’s
health on
blade 5.
0 = OK
1 = Minor
2 = Major
3 = Critical
pszTarget: Temp1SensorName
pszDataItem: health
116
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 50. RPC Usage Examples (Sheet 2 of 3)
ChassisManagementApi() [in]
parameters
Example
ChassisManagementApi() [out] parameters
uReturnType: DATA_TYPE_INT
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: CMM
ppvbuffer: Integer value denoting health state
Get the
CMM’s overall
health.
0 = OK
1 = Minor
2 = Major
3 = Critical
pszDataItem: health
uReturnType: DATA_TYPE_INT
pszCMMHost: localhost
uCmdCode CMD_GET
pszLocation: blade[1..n]
pszDataItem: health
ppvbuffer: Integer value denoting health state
0 = OK
Get a blade’s
overall health.
1 = Minor
2 = Major
3 = Critical
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: CMM
Get the
uReturnType: DATA_TYPE_STRING
version of
software on
the CMM.
ppvbuffer: A human-readable null-terminated
version string.
pszDataItem: version
pszCMMHost: localhost
uCmdCode: CMD_SET
pszLocation: blade[1-19]
pszDataItem: powerstate
pszSetData: poweroff
uReturnType: not used
ppvbuffer: not used
Power off one
of the blades.
The return code from ChassisManagementApi()
indicates success or failure.
pszCMMHost: localhost
uCmdCode: CMD_SET
pszLocation: blade[1-19]
pszDataItem: powerstate
pszSetData: poweron
uReturnType: not used
ppvbuffer: not used
Power on one
of the blades.
The return code from ChassisManagementApi()
indicates success or failure.
pszCMMHost: localhost
uCmdCode: CMD_SET
pszLocation: blade[1-19]
pszDataItem: powerstate
pszSetData: reset
uReturnType: not used
ppvbuffer: not used
Reset a
blade.
The return code from ChassisManagementApi()
indicates success or failure.
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: blade3
Determine
what sensors
are on blade
3.
uReturnType: DATA_TYPE_STRING
ppvbuffer: A list of sensor names as defined in the
SDR.
pszDataItem: ListTargets
pszCMMHost: localhost
uCmdCode: CMD_GET
pszLocation: blade3
Determine
uReturnType: DATA_TYPE_STRING
what may be
queried or set
on a blade.
ppvbuffer: A list of commands to be used as data
items.
pszDataItem: ListDataItems
pszCMMHost: localhost
uCmdCode: CMD_GET
Determine
what may be
uReturnType: DATA_TYPE_STRING
queried on the pszLocation: blade4
ppvbuffer: A list of commands to be used as data
items.
blade4 +3.3 V
pszTarget: +3.3SensorName
pszDataItem: ListDataItems
sensor.
Technical Product Specification
117
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
RPC
Table 50. RPC Usage Examples (Sheet 3 of 3)
ChassisManagementApi() [in]
Example
ChassisManagementApi() [out] parameters
parameters
pszCMMHost: localhost
uCmdCode: CMD_SET
uReturnType: not used
ppvbuffer: not used
Enable the
SNMP Traps.
pszLocation: chassis
The return code from ChassisManagementApi()
indicates success or failure.
pszDataItem: SNMPEnable
pszSetData: enable
pszCMMHost: localhost
uCmdCode: CMD_SET
uReturnType: not used
ppvbuffer: not used
Set the SNMP
pszLocation: chassis
Target.
The return code from ChassisManagementApi()
indicates success or failure.
pszDataItem: SNMPTrapAddress[1-5]
pszSetData: 134.134.100.34
pszCMMHost: localhost
uCmdCode: CMD_SET
uReturnType: not used
ppvbuffer: not used
Set the SNMP
Community.
pszLocation: chassis
The return code from ChassisManagementApi()
indicates success or failure.
pszDataItem: SNMPCommunity
pszSetData: public
pszCMMHost: localhost
uCmdCode: CMD_SET
uReturnType: not used
ppvbuffer: not used
Set the Telco
pszLocation: CMM
Alarm on.
The return code from ChassisManagementApi()
indicates success or failure.
pszDataItem: TelcoAlarm
pszSetData: 1
pszCMMHost: localhost
uReturnType: not used
ppvbuffer: not used
uCmdCode: CMD_SET
Light Major
LED on the
CMM.
pszLocation: CMM
pszDataItem: MajorLED
pszSetData: 1
The return code from ChassisManagementApi()
indicates success or failure.
118
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Logging
21.0 Command Logging
All CMMSET commands from all of the CMM interfaces (CLI, RPC, and SNMP) are logged by
the CMM under /var/log. The size of the log file is 8 kbytes. When the command log becomes full,
the log file is compressed and archived using gzip, then stored in /home/log. The filenames for the
log files will be user.log.N.gz, where N is the number of the log file from 1 to 4. The CMM will
keep up to four archives of log files. If the log file becomes full and there are already four existing
command log archives, the oldest archive will be deleted to make room for the newest archive.
Note: Archived files should NEVER be decompressed on the CMM as the resulting prolonged flash file
writing could disrupt normal CMM operation and behavior. The files should be transferred and
decompressed on a different machine. Files can be decompressed by any application that supports
the decompression of gzip (.gz) file types.
Note: The /home/log directory should not be deleted or change. the CMM requires that directory exist to
log errors.
Technical Product Specification
119
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Command Logging
120
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Telco Alarm Sensors
22.0 Telco Alarm Sensors
Alarm connector. By default, pins 1 through 4 are used by the CMM to clear major or minor
alarms. The current state of pins 1 and 3 inputs are mapped to a GPIO on the CMM and can
therefore be reconfigured as discrete sensor inputs.
22.1
Configuring the Telco Alarm Connector Pins
To configure the telco alarm sensors as discrete inputs or to clear events, the following CLI
command is used:
cmmset -l cmm -d TelcoInputs -v [sensors or clearEvents]
Where the value (-v) parameter is either:
sensors - Configures the telco alarm inputs as discrete input sensors. Or
clearEvents - Configures the telco alarm inputs to be used to clear telco alarms.
22.2
Obtaining the Configuration of the Telco Alarm Sensor
Connector Pins
To retrieve the configuration of the Telco Alarm Sensor pins, use the following CLI command:
cmmget -l cmm -d TelcoInputs
This command will return a value of:
“sensors” - If the telco alarm input pins are being used as discrete sensor inputs.
“clearEvents” - If the telco alarm input pins are being used to clear minor and major alarms.
22.3
Telco Alarm Connector Sensor Naming
The default name of the two telco alarm sensors is TAsensor1 and TAsensor2. These names are
used and reported by the various CMM interfaces for the Telco Alarm Sensors. The sensors can be
renamed using the following CLI command:
cmmset -l cmm -t TAsensorN -d sensorname -v [NewSensorName]
Where:
N - Is either “1” or “2” for TAsensor1 and TAsensor2, respectively.
NewSensorName - The new name that will be associated with the corresponding sensor.
Technical Product Specification
121
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Telco Alarm Sensors
22.3.1
Sensor Names using SNMP
The telco alarm sensor names that will be shown via SNMP will be those that are defined at CMM
startup. If a telco alarm sensor name has been changed after startup, the new name will not be
reflected via SNMP until the CMM is restarted.
22.4
Telco Alarm Sensors and Redundancy
In dual CMM systems, the telco alarm sensors are individual to each CMM in the system, and are
not synchronized between the two CMMs. SEL entries from sensors on the active CMM will not be
synched to the standby CMM.
If it is desired to monitor the same two inputs on both CMMs, the two inputs must be split into four
and connected to the telco alarm connectors on both CMMs.
Telco alarm sensor names are synched between the two CMMs. Changing the name of the sensors
on the active CMM will cause the same names to be assigned on the standby CMM.
122
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Application Hosting
23.0 Application Hosting
The ZT 7102 allows applications to be hosted locally. This is useful as a method for adding small
custom management utilities to the CMM.
23.1
23.2
System Details
The CMM runs a customized version of embedded BlueCat* Linux* 4.0 on an Intel® XScale®
microarchitecture 80200 processor. Development support for BlueCat Linux is available at:
Startup and Shutdown Scripts
The CMM is capable of running user created scripts automatically on boot up or shutdown.This
can be accomplished by editing the /etc/rc.d/init.d/userScripts file with a text editor. This is a
standard shell file just like /etc/rc.d/init.d/cmm. By default it just echos "Starting user services" and
"Shutting down user services". The user can add scripts or what they want to the file. The Ramdisk
version of /etc/inittab calls "/etc/rc.d/init.d/userScripts start" right after its starts the cmm software.
When you type reboot, it calls "/etc/rc.d/init.d/userScripts stop”.
23.3
System Resources Available to User Applications
Since the CMM has firmware of its own running at all times, user applications must adhere to
certain resource and directory constraints to avoid disrupting the CMMs operation. Specifically,
restrictions are placed on an application’s consumption of file system storage space, RAM, and
interrupts. Exceeding these guidelines may interfere with proper operation of the CMM.
23.3.1
File System Storage Constraints
The following file system locations are available for storage by user applications. Storing files in
locations other than those explicitly listed here is not supported.
23.3.1.1
Flash Storage Locations
Applications should not perform excessive amount of flash file I/O at runtime, because this will
impair performance of the CMM.
/etc - Useful for storing configuration files. Do not add more than 100 Kbytes to /etc.
/etc/rc.d/init.d - Useful for storing startup scripts. Do not add more than 100 Kbytes to /etc.
/home/scripts - Useful for storing user scripts. Do not add more than 3 Mbytes to /home.
/home - Useful for storing application binaries. Do not add more than 3 Mbytes to /home.
Technical Product Specification
123
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Application Hosting
23.3.1.2
RAM-Disk Storage Locations
Caution: Files in this location are stored in RAM, and will be lost during CMM reboots.
Due to the constraints of writing to flash memory, larger file operations such as decompressing an
archive should be performed on RAM-disk in the following directory:
/usr/local/cmm/temp - Useful for storing temporary files. Applications should make a subdirectory
for use with their temporary files. Do not add more than 5 Mbytes to this location.
23.3.2
RAM Constraints
Up to 32 Mbytes of RAM are available for use by user applications. RAM usage at runtime, on
average, should not exceed this quantity.
23.3.3
Interrupt Constraints
User applications should not make use of interrupts. All interrupts are reserved for use by the
CMM firmware.
23.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.
/lib - Shared library files and drivers
/bin – Linux binary files like ping, mount
/dev – Device driver files
/proc – Special linux area that contains info about memory, drivers, etc.
/root – Empty root user area.
/sbin – Binary files like ifconfig, route
/tmp – Empty
/var – Temp location for log files and other temp files.
124
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Busless Backplane Support
24.0 Busless Backplane Support
The ZT 7102 supports busless PICMG* 2.16 backplanes. Busless backplanes are PICMG 2.16
backplanes that do not have the CompactPCI* bus routed or enabled. When the CMM is inserted
into a busless backplane, the ZT7102 does not perform a check for system or peripheral slots, and
powers up the boards in any slot regardless. Boards used in this type of chassis should be system
master, or drone mode enabled boards. Special care should be taken to not use peripheral only
boards in such a chassis as these boards rely on a system master and CompactPCI bus to operate
properly.
Technical Product Specification
125
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Busless Backplane Support
126
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
25.0 Updating Software
When new CMM updates are available, they are packaged in a zip file and posted to the Intel web
site located at:
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. The update process allows these updates to occur over the wire
without losing the active cmm in a redundant configuration.
25.1
Key Features of the Firmware Update Process
• Updates can be done remotely over the front or back Ethernet ports on the CMM
• Current CMM configuration data is preserved across the update
• Critical CMM data such as the SEL and command history is preserved across an update
• Redundant CMMs can be updated without interrupting management of the chassis
• Update files are verified and checked for corruption
• Update components have associated version numbers
• Update events are logged to the SEL
• Updates can be triggered using the CLI
• Update packages can be located locally on the CMM, or pulled from a mounted NFS or remote
FTP server
25.2
Update Process Architecture
The update process consists of the following components:
• User Client - The client is used to trigger the update process, and can be located anywhere on
the network.
• Update Package - The update package contains the new software components and other files
necessary for the update. The update package can be pulled from a remote server or pushed
locally onto the CMM.
• CMM Update Request Handler - The update request handler is CMM software that processes
incoming update requests from and responses to the various interfaces provided by the CMM.
• CMM Update Script - The update script is stored on the CMM and is used to process the
contents of the update package and perform the update.
• Update Package Server (Optional) - The update package server can be used to store update
packages remotely from the CMM. This can be an FTP or NFS server.
Technical Product Specification
127
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
25.3
Critical Software Update Files and Directories
The following table is a list of files and directories important to the software update process.
Table 51. List of Critical Software Update Files and Directories
File or Directory Name:
Description:
/usr/local/cmm/temp
Mount point for ramdisk
Directory into which the update package is copied and unzipped.
The update process will delete and recreate this directory. If it is
desired to copy the update package to the CMM before updating,
then put the package in /usr/local/cmm/temp/update.
/usr/local/cmm/temp/update/package
NOTE: Do NOT place the update files into the
/usr/local/cmm/temp/update/package directory. The
update process uses this directory and will erase and
overwrite files placed here.
/usr/local/cmm/temp/update/etc
[package file].zip
Backup copy of /etc is located here
Zip file containing update package files
MD5 checksum of the [package file].zip file
[package file].md5
At the end of an update, this file contains a list of the package
version, and each component version
/etc/versions
The update process will move the "old" /etc/versions file by
appending a file extension to it which is the package version string
- i.e., .. /etc/versions.V00.30a
/etc/versions.<version>
These optional scripts are supplied by the user. The update
process will execute them just prior to shutting down the cmm
applications. The primary function of these scripts is to allow the
user a method of shutting down any user process which are using
the flash file systems.
/home/update/scripts/K*
/home/update/scripts/S*
These optional scripts are supplied by the user. The update
process will execute these scripts just before processing the save
list - which copies files and directories from
/usr/local/cmm/temp/update/etc to /etc
If the update direction is "backward", then files and directories that
are priority 2 will be copied here instead of /etc
/home/update/backup
Log file to which output is sent while the update process is
operating - this is on a ramdisk.
/usr/local/cmm/temp/update/update.log
/etc/cmm/update.log
The log file is copied when the update process completes
successfully
25.4
Update Package
The update package will be distributed by Intel and may contain the following components:
Table 52. Contents of the Update Package (Sheet 1 of 2)
File Name
Description
CMM_RB.bin
Redboot image to be stored in flash
FPGA image
CMM_FPGA.bin
CMM_FFS.bin
/etc image
128
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
Table 52. Contents of the Update Package (Sheet 2 of 2)
File Name
Description
CMM_OS.bin
README
OS image
Text file containing release notes for the update package
Update_Metadata
Utilities
File containing info on the update package and how it should be installed on the CMM
Sub-directory containing any utilities that might be required for the install
File containing MD5 check sums for the files and scripts present in the update package
List of configuration files in /etc to be preserved across software updates
Other components such as FRU files that may be necessary for the update
validationfile
saveList
Other
List of all versions of firmware available for the platform in sequential order, with the
newest versions at the end of the list.
version_history
ZT7102.MIB
MIB file for SNMP.
The update package can be placed locally on the CMM in the /usr/local/cmm/temp directory, or it
can reside on a server on the network.
The files and directories that make up the Update Package are packaged and delivered as a zip file.
Associated with the zip file is a file containing the md5 sum of the zip file. For example:
[PackageFileName].zip file containing all files and subdirectories of the update package
[PackageFileName].md5 file containing md5 checksum of PackageFileName.zip
Arguments for the location of the update package will be given in the CLI command. It is here that
you can point to a remote server, or to a local directory. The update script will then remove the
/usr/local/cmm/temp/update/package directory and recreate it with the new package files.
Note: If an NFS server is mounted to the CMM, the argument in the update script will be similar to a file
located locally on the CMM.
If the package fails to copy or transfer to /usr/local/cmm/temp/update/package, then the update
process will terminate.
25.4.1
Update Package File Validation
The first level of update package validation is checking that the md5sum of the zip file matches the
md5sum in the [PackageFileName].md5 file of the update package.
Update packages are validated during the update process by computing the md5sum of each file
and comparing against the check sums stored in the check sums stored in the validation_file
included with the update package.
The update package is also checked to ensure it is valid for the platform that it is being used on. For
example, an update package with firmware for a CPCI CMM will not work on an ATCA CMM.
25.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
Technical Product Specification
129
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
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.
25.4.3
Component Versioning
The components contained in the update package will contain versioning information which will
allow the update process to ensure the updated components installed on the CMM are all
compatible at the end of an update and match those contained in the update package.
If an update package contains a component version that is already installed on the CMM, then that
component will not be updated. A method is also provided to force all components to update
regardless of the version installed.
Version info for files currently installed on the CMM will be able to be obtained through the
various interfaces and is stored in the /etc/cmm/versions file. Version info for the files in the update
package will also be made available.
The CMM checks the md5sum of /etc/versions during boot. In the event that the checksum fails,
the CMM applications will fail to start and a message will appear on the console as follows
“Startup of CMM applications has terminated due to detection of an inconsistent software load.”
This functionality exists to prevent a CMM with an incorrect /etc/versions file, which may have
occurred during an incomplete update, from synchronizing incorrectly with the other CMM.
25.5
saveList and Data Preservation
The update process will preserve user configuration data as well as critical system configuration
information across updates. These files are located in the /etc directory. The list of files or
directories to be preserved across updates is contained in the software update package and is called
SaveList. Each entry in the saveList will contain a directory or file to be saved as well as a priority
assigned to it. Priority for the file can be either a 1 or a 2, and is used to determine if certain files or
directories should be saved when updating to an earlier firmware version.
Priority 1 is assigned to files or directories that should be saved in all cases of an update, including
going forward or backward in firmware version. Priority 1 files are considered files critical to the
CMM operation and access to the CMM, such as Ethernet configuration.
Priority 2 is assigned to files or directories which should not be saved if an update is being
performed to an earlier version of firmware.
During an update, the CMM will copy over the current files in /etc to ram disk in
/usr/local/cmm/temp/update/etc. The CMM then uses the saveList file to determine which
configuration files or directories to copy back into the new /etc partition. When updating to a
previous version of firmware, the CMM makes a backup of any files designated priority 2 in the
save list to flash in the /home/update/backup/etc directory.
Table 53. saveList Items and Their Priorities (Sheet 1 of 2)
File
Priority
/etc/*.cfg
2
2
2
/etc/*.ini
/etc/cmm/*.ent
130
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
Table 53. saveList Items and Their Priorities (Sheet 2 of 2)
File
Priority
/etc/passwd
1
1
1
1
1
1
1
1
1
1
1
/etc/shadow
/etc/cmm/sel_*
/etc/cmm/cmm_sel
/etc/snmp*.conf
/etc/ifcfg-eth*
/etc/HOSTNAME
/etc/ftp*
/etc/group
/etc/profile
/etc/versions*
25.6
Update Mode
To perform the update, the CMM will enter an update mode to prevent interference from other
processes that may write to the flash and to unmount the JFFS2 drives that may need to be
repartitioned.
In the update mode, all CMM applications will be stopped. Any user defined processes that are
running must also be stopped. Hooks in the update process will be provided to allow these
processes to be stopped by calling user scripts located in /home/update/scripts/ if they exist. The
update process will execute any scripts that match the following pattern: /home/update/scripts/K*.
Scripts will be execute in alpha-numeric sort order. Getting a directory listing using the “ls”
command will display the order the scripts will run. User scripts should follow the convention of
returning a “0” if successful and a non-zero for failure. The update process will not fail if a script
returns a failure, however, the update process will fail if the flash drives cannot be unmounted
when necessary.
Before unmounting the JFFS2 drives (/etc and /home), /etc will be copied to ram disk
/usr/local/cmm/temp/update/etc to retain user and system configuration information.
Because all CMM applications are stopped, systems running with redundant CMMs will lose
redundancy during the firmware update process.
25.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.
Technical Product Specification
131
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
25.8
Synchronization
Following a firmware update to the standby CMM in a redundant CMM, some level of
synchronization will occur. The firmware contains an internal synchronization version which is
used to determine what level of synchronization occurs following an update. The internal
synchronization number will increment each time a firmware package is released.
Following a firmware update, the CMM with the newest synchronization version will become or
remain the active CMM. If the synchronization version is the same after an update, a full
synchronization occurs.
Note: User scripts are only synchronized if the synch code versions remain the same.
The following table describes the behavior following an update to a different synch code version.
Table 54.
Synchronization Behavior for Differing Synch Versions
Local Synch Version > Other
Synch Version
Local Synch Version < Other Synch
Version
Synch to Standby: Board Power States, SEL,
SNMP trap addresses, Password
Synch to Standby: Board Power
States
Local CMM is Active
Local CMM is Standby
Note: /home/scripts is NOT synchronized.
Synch from Active: Board Power
States, SEL, SNMP trap
addresses, Password
Synch from Active: Board Power States.
Note: /home/scripts is NOT
synchronized.
Board power states are synchronized in all cases (synch versions equal or not equal).
The synchronization process does not synchronize the alarms (SEL) when the synch versions are
not equal. SEL files are saved by the update process. During an update to an earlier version of a
redundant setup, alarms received while the Standby is being updated won't be synchronized.
25.8.1
25.8.2
Updating to a Newer Synchronization Version
Following an update on the standby CMM to firmware that has a newer synchronization version
than the active CMM, the active CMM will synchronize critical information, such as board power
states, the SEL, SNMP trap addresses and configuration, and password files. Once synchronization
completes, the newly updated CMM will then become the active CMM because it has a newer
synchronization version.
Updating to an Older Synchronization Version
Following an update on the standby CMM to firmware that has an older synchronization version
than the active CMM, no synchronization will occur and the newly updated CMM will remain as
standby because it has an older synchronization version.
132
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
25.8.3
Updating to the Same Synchronization Version
Following an update on the standby CMM to firmware that has the same synchronization version
as the active CMM, a full synchronization will occur upon completion of the update (as if a new
CMM has been inserted into the chassis). The newly updated CMM will remain as the standby
CMM following synchronization.
25.9
Single CMM System
When updating CMMs in a system that only contains a single CMM, once the CMM enters the
update mode, any components in that system the CMM manages power to may power down
because the CMM applications are stopped. Consult your system and board documentation to
determine the effect of updating or removing the CMM from the system.
25.10
25.11
Redundant CMM Systems
In systems with redundant CMMs, the update should be triggered on the standby CMM. An update
cannot occur on the active CMM.
Once the CMM enters the update mode, the chassis will lose redundancy for the duration of the
update process.
CLI Support
The CLI will support a command for an update request. The syntax of the command is as follows:
cmmset -l cmm -d update -v “[Update Package path and filename] [force]
[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: “builds/build105b/CMM_P00.105b”
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. Also, data
restore user scripts will not be executed. This option cause the environment variable
FORCE_OVERWRITE to be set to TRUE.
The following arguments are used if the update package is located on a remote FTP server. If ftp is
supplied as an argument, server and user are also required. Password is optional. If password is not
supplied, then ftp will prompt for a password.
ftp - Optional argument used to indicate that the update package resides on a remote ftp server. If
this argument is given, the arguments for server, user, and password must also be given.
server - Optional argument that is the name or IP address of a remote ftp server containing the
firmware update package.
Technical Product Specification
133
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
user and password - Optional argument that is the username and password for the FTP server.
Note: The -v argument can be up to 64 characters long.
The command returns a 0 if the update request is successful, and non-zero if an error occurs.
25.12
Hooks for User Scripts
The update process provides hooks for user scripts in two places during the update process. User
scripts should follow the convention of returning a "0" if successful and a non-zero for failure. The
user scripts will be invoked as a forked sub-shell.
25.12.1
Update Mode User Scripts
Entering update mode requires that all JFFS2 drives be unmounted, which requires that all
processes using these drives be stopped. Prior to entering update mode, the update process will call
user scripts located in /home/update/scripts/ if they exist. The update process will execute any
scripts that match the following pattern: /home/update/scripts/K*. No arguments are passed to
these scripts. The update process will not fail if a script returns a failure, however, the update
process will fail if the flash drives cannot be unmounted when necessary. A message indicating if
the script was successful or failed will be output to the terminal. See Section 25.6, “Update Mode”
on page 131 for more information on the Update Mode.
25.12.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".
arg2 = Update Direction: ["forward", "backward", "same"]
Note: "forward" means that the Update Package version is newer than the installed version. "same"
means they are the same, and "backward" means the Update Package version is older then the
installed version.
arg3 = Installed Package Version: i.e., "P00.105b". This is the version of the software that is
currently installed on the cmm.
arg4 = Update Package Version: i.e., "P00.111a". This is the version of the update package
software.
The update script will print a message to the terminal indicating whether the script was successful
or failed. Currently, the failure of one of these scripts does not cause the overall update process to
fail.
These scripts can be used to perform any user updates that need to coincide with the newly
installed version.
134
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
Note: In prior versions of this document, the following examples showed how to use the user scripts to
replace a script in the /etc/scripts directory. Going forward, all user scripts should be stored in
/home/scripts. The directory /etc/scripts will be a link to /home/scripts. As a general rule, users
should only put scripts and files under the /home directory.
25.12.3
Example Task - Replace /home/scripts/myScript with a newer version
if updating forward or an older version if updating backward
Example update scenario:
• There are three CMM builds - call them A, B, and C. The CMM is currently installed with
build B. Build A is older than B and C is newer.
• If the CMM is updated to build C, then the user script /home/scripts/myScript needs to be
updated to a newer version.
• Similarly, if the CMM is reverted to build A, then the user script /home/scripts/myScript needs
to be replaced with an older version.
• The old version of myScript is placed on the CMM as: /home/stagingarea/myScript.old
• The new version of myScript is placed on the CMM as: /home/stagingarea/myScript.new
• The Data Restore User Script written to manage /home/scripts/myScript is placed on the CMM
as: /home/update/scripts/S10updateMyScript
A simple example of the S10updateMyScript could look like the following:
#!/bin/bash
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.
Variation on the above example:
• In this case, the different versions of myScript are put on the CMM (by the user) as:
— /home/stagingarea/myScript.A
— /home/stagingarea/myScript.B
— /home/stagingarea/myScript.C
Note: If the CMM has build A installed, the "cmmget -d version" command will return the string "A" -
and so on for builds B and C.
Another example of S10updateMyScript:
#!/bin/bash
Technical Product Specification
135
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
newversion=$4
cp /home/stagingarea/myScript.$newversion /home/scripts/myScript
exit $?
25.13
Update Process
1. Client initiates an update request via CLI command
2. CMM validates the update request
— CMM is not already doing an update
— In a redundant configuration, the CMM must be standby
— In a redundant configuration, redundancy must be "active"
— CMM is not currently synchronizing
— Enough space is present in ramdisk and flash for the update
3. If update request is valid then
— Continue
4. Else
— Exit
5. If FTP arguments supplied then
— Retrieve package files (.zip, .md5) from FTP server
— Exit if error occurs
6. Else
— Copy package files (.zip, .md5) to package directory on ramdisk
(/usr/local/cmm/temp/update/package)
— 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")
— a.Exit if mismatch
11. Transition to Update Mode
— Call any user supplied scripts in /home/update/scripts/K*
— Shutdown CMM apps (/etc/rc.d/init.d/cmm stop)
— Copy /etc to /usr/local/cmm/temp/update/etc
— Unmount /etc and /home
— Exit if any of these filesystems cannot be unmounted
136
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
12. Update Components (listed in UpdateMetadata file)
— If a component update fails
Stop updating components
Attempt to remount /etc and /home
Exit the update process, but do not reboot
— If the component is "etc_jffs" then
Remount /etc and /home
Call any user supplied scripts in /home/update/scripts/S*
Process saveList - copying files and directories from /usr/local/cmm/temp/update/etc to
/etc
13. If the process has been successful so far then
— Remount /etc and /home
— Update the /etc/versions file - backing up the old one as "/etc/versions.<version>"
— Copy the update.log file from ramdisk to /etc/cmm/update/update.log
— Reboot CMM
25.14
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]
25.15
25.16
DEBUG_UPDATE Variable
Setting the environment variable DEBUG_UPDATE prior to starting an update will print out
additional debug level output to the user including all files that are copied during the update
process. To set the DEBUG_UPDATE variable type the following in the CLI:
export DEBUG_UPDATE=1
Update Process Sensor and SEL Events
Once the CMM enters the update mode in which no CMM processes are active, events cannot be
entered into the SEL directly. While in this mode, the CMM will enter events into the eeprom.
Once the system reboots into the OS, the CMM will log the events from the eeprom into the SEL.
Note: Events that occur prior to entering the update mode are logged directly into the SEL.
Technical Product Specification
137
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Updating Software
25.17
RedBoot Update Process
The firmware can also be updated through Redboot. This update is done at a pre-OS level, meaning
that the update is executed before the OS loads. This method requires updating over TFTP through
the eth0 Ethernet port and must be done locally. A separate update package is needed if this method
is used. The following instructions are included with the update package.
25.17.1 Required Setup
To update the flash on the CMM using the Redboot method, the following setup is required:
1. A host computer running Microsoft* Windows XP, 2000 or NT4.0 operating systems
2. The above computer should be configured with a static IP address of 192.168.100.20 and a
subnet mask of 255.255.255.0
3. The above computer should be on the same subnet as the CMM or connected directly.
4. It is highly recommended that the subnet be isolated. The only two network entities on the
subnet should be the CMM and the Windows computer.
25.17.2 Update Procedure
Read through the following steps completely before starting the update.
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, the CMM needs to be reset using the reset button on the faceplate while
simultaneously executing 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 param-
eter. To find this out, use the command ifconfig eth0 on the CMM CLI to find out the MAC
address of eth0.
b. A second argument ,"FFS", must be used when upgrading/downgrading to a different
version. Note that this will reset the passwords, IP addresses and other custom Linux envi-
ronment settings to factory defaults and clear the event log entries.So far the command line
on the host should look like this:
update_cmm 00-a0-b7-d8-d8-5d FFS
c. By default, the update script assumes that the host computer and the CMM are on the network
192.168.100.x. If your host computer is on a different network, provide another command
line argument to the update_cmm batch file. This argument should be an unused IP address
on the same network the host computer is on. For example:
update_cmm 00-a0-b7-d8-d8-5d FFS 192.168.100.50
After executing the batch file, follow the instructions as prompted by the batch file for a successful
update.
138
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Example CLI Commands
Appendix D Example CLI Commands
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 55. Example CLI Commands (Sheet 1 of 2)
Use Case
CLI Command
Return
Get current chassis
temperature for “Temp
Snsr 1”.
cmmget –l chassis –t “Temp Snsr 1”
Current Temperature for “Temp
Sensr 1” on chassis.
–d current
Fantray1 is present.
Get fan tray 1
presence.
cmmget –l fantray1 –d presence
Fantray1 is not present.
Get the baseboard
temperature of blade
5 when the sensor is
named “ambient
temp”.
Current Temperature of “ambient
temp” on blade 15.
cmmget –l blade5 –t “ambient temp”–d current
cmmget –l blade15 –d presence
Blade15 is present.
Find out if blade 15 is
present.
Blade15 is not present.
Returns thresholds for upper
non-recoverable, upper critical,
upper non-critical, lower
non-critical, lower critical, and lower
non-recoverable.
Get all thresholds for
the +3.3 V sensor on
blade 2.
cmmget –l blade2 –t “+3.3V” –d thresholdsall
Get the overall system
health.
Indicates if the entire system is
healthy, or has health events.
cmmget –l system –d health
Get a list of blades
with problems
List of locations with active health
events.
cmmget –l system –d unhealthylocations
Indicates if the CMM is healthy or if
there are active health events on
the CMM.
Get the CMM’s overall
health.
cmmget –l cmm –d health
Display the SEL of the
CMM
Displays a list of SEL entries (if any)
for the CMM.
cmmget –l cmm –d sel
Display the SEL of
blade19.
Displays a list of SEL entries (if any)
for blade 19.
cmmget –l blade19 –d sel
Get the version of
firmware on the CMM
Displays the version of firmware
currently installed on the CMM.
cmmget –l cmm –d version
Displays a success or failure
message.
Power off blade 19.
Power on blade 20.
Reset blade 3.
cmmset -l blade19 –d powerstate –v poweroff
cmmset –l blade20 –d powerstate –v poweron
cmmset –l blade3–d powerstate -v reset
cmmget –l chassis -t fru -d all
Displays a success or failure
message.
Displays a success or failure
message.
Get all of the chassis
FRU information.
Displays a list of all of the FRU
information from the chassis.
Get all fantray2 FRU
information
Displays a list of all of the FRU
information from the CMM.
cmmget –l fantray2 –t fru –d all
Technical Product Specification
139
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Example CLI Commands
Table 55. Example CLI Commands (Sheet 2 of 2)
Use Case
CLI Command
Return
Get a blade’s FRU
information
cmmget –l blade[1-19] –d fru
A list of FRU information.
Find out what sensors
are on blade 3.
A list of sensor names as defined in
their SDRs on blade 3.
cmmget –l blade3 –d listtargets
List the data items that
can be queried or set
on blade 4.
cmmget –l blade4 –d listdataitems
A list of dataitems for blade 4.
Find out what can be
queried on blade4’s
+3. 3V sensor.
A list of commands to be used as
dataitems for the +3.3V.
cmmget –l blade4 –t “+3.3V” –d listdataitems
Enable SNMP Traps
cmmset –l cmm –d snmpenable –v enable
Success or failure
Success or failure
Set SNMP Trap
Address1
cmmset –l cmm –d snmptrapaddress1 –v
134.134.100.34
Set SNMP
Community
cmmset –l cmm –d snmpcommunity –v public
Success or failure
140
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Datasheet Reference
Appendix E Datasheet Reference
This appendix provides links to datasheets, standards, and specifications for the technology
designed into the CMM.
E.1
E.2
E.3
E.4
Intel® CompactPCI* Product Information
Information, collateral, and software updates for all CompactPCI-compatible Intel products can be
found at:
CompactPCI
Current CompactPCI Specifications can be purchased from PICMG* for a nominal fee. Short form
specifications in Adobe Acrobat format (PDF) are also available on PICMG's website at:
IPMI
The Intelligent Platform Management Initiative is described and current specifications can be
found at:
®
Intel IOP310 Processor Chipset
®
For more information about the Intel IOP310 Processor Chipset, see the following Web site:
Technical Product Specification
141
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Datasheet Reference
142
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Warranty Information
Appendix F Warranty Information
®
F.1
Intel NetStructure™ Compute Boards & Platform Products
Limited Warranty
Intel warrants to the original owner that the product delivered in this package will be free from
defects in material and workmanship for two (2) year(s) following the latter of: (i) the date of
purchase only if you register by returning the registration card as indicated thereon with proof of
purchase; or (ii) the date of manufacture; or (iii) the registration date if by electronic means
provided such registration occurs within 30 days from purchase. This warranty does not cover the
product if it is damaged in the process of being installed. Intel recommends that you have the
company from whom you purchased this product install the product.
THE ABOVE WARRANTY IS IN LIEU OF ANY OTHER WARRANTY, WHETHER
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY
WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ANY
WARRANTY OF INFRINGEMENT OF ANY OTHER PARTY'S INTELLECTUAL PROPERTY
RIGHTS, OR ANY WARRANTY ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR
SAMPLE.
This warranty does not cover replacement of products damaged by abuse, accident, misuse,
neglect, alteration, repair, disaster, improper installation or improper testing. If the product is found
to be otherwise defective, Intel, at its option, will replace or repair the product at no charge except
as set forth below, provided that you deliver the product along with a return material authorization
(RMA) number (see below) either to the company from whom you purchased it or to Intel. If you
ship the product, you must assume the risk of damage or loss in transit. You must use the original
container (or the equivalent) and pay the shipping charge. Intel may replace or repair the product
with either a new or reconditioned product, and the returned product becomes Intel's property. Intel
warrants the repaired or replaced product to be free from defects in material and workmanship for a
period of the greater of: (i) ninety (90) days from the return shipping date; or (ii) the period of time
remaining on the original two (2) year warranty.
This warranty gives you specific legal rights and you may have other rights which vary from state
to state. All parts or components contained in this product are covered by Intel's limited warranty
for this product. The product may contain fully tested, recycled parts, warranted as if new.
F.1.1
F.1.2
Returning a Defective Product (RMA)
Before returning any product, contact an Intel Customer Support Group to obtain either a Direct
Return Authorization (DRA) or Return Material Authorization (RMA). Return Material
Authorizations are only available for products purchased within 30 days.
Return contact information by geography:
For the Americas
Return Material Authorization (RMA) credit requests e-mail address: [email protected]
Direct Return Authorization (DRA) repair requests e-mail address: [email protected]
Technical Product Specification
143
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Warranty Information
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
F.1.3
For EMEA
Return Material Authorization (RMA) e-mail address - [email protected]
Direct Return Authorization (DRA) for repair requests e-mail address: [email protected]
Intel Business Link (IBL): http://www.intel.com/ibl
Telephone No.: 00 44 1793 403063
Fax No.: 00 44 1793 403109
Office Hours: Monday - Friday 0900-1700 UK time
F.1.4
For APAC
RMA/DRA requests email address: [email protected]
Telephone No.: 604-859-3111 or 604-859-3325
Fax No.: 604-859-3324
Office Hours: Monday - Friday 0800-1700 Malaysia time
Return Material Authorization (RMA) requests e-mail address: [email protected]
Telephone No.: 81-298-47-0993 or 81-298-47-5417
Fax No.: 81-298-47-4264
Direct Return Authorization (DRA) for repair requests, contact the JPSS Repair center.
E-mail address: [email protected]
Telephone No.: 81-298-47-8920
Fax No.: 81-298-47-5468
Office Hours: Monday - Friday 0830-1730 Japan time
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. Limitation of Liability and Remedies
INTEL SHALL HAVE NO LIABILITY FOR ANY INDIRECT OR SPECULATIVE DAMAGES
(INCLUDING, WITHOUT LIMITING THE FOREGOING, CONSEQUENTIAL, INCIDENTAL
AND SPECIAL DAMAGES) ARISING FROM THE USE OF OR INABILITY TO USE THIS
144
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Warranty Information
PRODUCT, WHETHER ARISING OUT OF CONTRACT, NEGLIGENCE, TORT, OR UNDER
ANY WARRANTY, OR FOR INFRINGEMENT OF ANY OTHER PARTY'S INTELLECTUAL
PROPERTY RIGHTS, IRRESPECTIVE OF WHETHER INTEL HAS ADVANCE NOTICE OF
THE POSSIBILITY OF ANY SUCH DAMAGES, INCLUDING, BUT NOT LIMITED TO LOSS
OF USE, BUSINESS INTERRUPTIONS, AND LOSS OF PROFITS. NOTWITHSTANDING
THE FOREGOING, INTEL'S TOTAL LIABILITY FOR ALL CLAIMS UNDER THIS
AGREEMENT SHALL NOT EXCEED THE PRICE PAID FOR THE PRODUCT. THESE
LIMITATIONS ON POTENTIAL LIABILITIES WERE AN ESSENTIAL ELEMENT IN
SETTING THE PRODUCT PRICE. INTEL NEITHER ASSUMES NOR AUTHORIZES
ANYONE TO ASSUME FOR IT ANY OTHER LIABILITIES.
Some states do not allow the exclusion or limitation of incidental or consequential damages, so the
above limitations or exclusions may not apply to you.
Technical Product Specification
145
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Warranty Information
146
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Customer Support
Appendix G Customer Support
This appendix offers technical and sales assistance information for this product, and information on
returning an Intel NetStructure product for service.
G.2
G.3
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.
Sales Assistance
If you have a sales question, please contact your local Intel ® NetStructureTM Sales Representative
or the Regional Sales Office for your area. Address, telephone and FAX numbers, and additional
information is available at Intel's website, located at:
Intel Corporation
Telephone (in U.S.) 1-800-755-4444
Telephone (Outside U.S.) 1-973-993-3030
Technical Product Specification
147
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Customer Support
148
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Agency Approvals
Appendix H Agency Approvals
H.1
CE Certification
The ZT 7102 meets the intent of Directive 89/336/EEC for Electromagnetic Compatibility and
Low-Voltage Directive 73/23/EEC for Product Safety. The ZT 7102 has been designed for
NEBS/ETSI compliance.
H.2
Safety
UL/cUL 60950
EN/IEC 60950
Safety for Information Technology Equipment (UL File # E179737)
Safety for Information Technology Equipment
CB certificate and Report
CB Report Scheme
H.3
Emissions Test Regulations
FCC Part 15, Subpart B
EN 55022
CISPR 22
Bellcore GR-1089
H.3.5
EN 50081-1 Emissions
GR-1089-CORE Sections 2 and 3
EN 55022
EN 55022
Class A Radiated
Power Line Conducted Emissions
EN 61000-3-2 Power Line Harmonic Emissions
EN 61000-3-3 Power Line Fluctuation and Flicker
H.3.6
EN 55024 Immunity
GR-1089-CORE Sections 2 and 3
EN 61000 4-2
EN 61000 4-3
EN 61000 4-4
EN 61000 4-5
Electro-Static Discharge (ESD)
Radiated Susceptibility
Electrical Fast Transient Burst
Power Line Surge
Technical Product Specification
149
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Agency Approvals
EN 61000 4-6
Frequency Magnetic Fields
EN 61000 4-11 Voltage Dips, Variations, and Short Interruptions
H.4
Regulatory Information
H.4.7
FCC (USA)
This product has been tested and found to comply with the limits for a Class A digital device
pursuant to Part 15 of the FCC rules. These limits are designed to provide reasonable protection
against harmful interference when the equipment is operated in a commercial environment.
This product generates, uses, and can radiate radio frequency energy and, if not installed and used
in accordance with the instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful
interference in which case the user will be required to correct the interference at his own expense.
Note: This device complies with Part 15 of the FCC Rules.
Caution: If you make any modification to the equipment not expressly approved by Intel, you could void
your authority to operate the equipment.
H.4.8
Industry Canada (Canada)
Cet appareil numérique respecte les limites bruits radioélectriques applicables aux appareils
numériques de Classe A prescrites dans la norme sur le matériel brouilleur: “Appareils
Numériques”, NMB-003 édictée par le Ministre Canadien des Communications.
This digital apparatus does not exceed the Class A limits for radio noise emissions from digital
apparatus set out in the interference-causing equipment standard entitled: “Digital Apparatus,”
ICES-003 of the Canadian Department of Communications.
H.5
Product Safety Information
H.5.8.1
Safety Precautions
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.
150
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Agency Approvals
Warning: To Avoid Electric Overload: To avoid electrical hazards (heat shock and/or fire hazard), do not
make connections to terminals outside the range specified for that terminal. See the product user
manual for correct connections.
Warning: To Avoid the Risk of Electric Shock: When supplying power to the system, always make
connections to a grounded main. Always use a power cable with a grounded plug (third grounding
pin). Do not operate in wet, damp, or condensing conditions.
Caution: System environmental requirements: Components such as Processor Boards, Ethernet Switches,
etc., are designed to operate with external airflow. Components can be destroyed if they are
operated without external airflow. External airflow is normally provided by chassis fans when
components are installed in compatible chassis. Never restrict the airflow through the unit's fan or
vents. Filler panels or air management boards must be installed in unused chassis slots.
Environmental specifications for specific products may differ. Refer to product user manuals for
airflow requirements and other environmental specifications.
Warning: Device heatsinks may be hot during normal operation: To avoid burns, do not allow anything to
touch heatsinks.
Warning: Do Not Operate Without Covers: To avoid electric shock or fire hazard, do not operate this
product with any removed enclosure covers or panels.
Warning: To Avoid the Risk of 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 injury, fire hazard, or explosion: Do not operate this product in an explosive atmosphere.
Warning: If Your System Has Multiple Power Supply Sources: disconnect all external power connections
before servicing.
Warning: Power supplies must be replaced by qualified service personnel only.
Caution: Lithium batteries are not field-replaceable units. There is a danger of explosion if a battery is
incorrectly replaced or handled. Do not disassemble or recharge the battery. Do not dispose of the
battery in fire. When the battery is replaced, the same type or an equivalent type recommended by
the manufacturer must be used. Used batteries must be disposed of according to the manufacturer's
instructions. Return the unit to Intel for battery service.
Warning: Avoid injury: This product may contain one or more laser devices that are visually accessible
depending on the plug-in modules installed. Products equipped with a laser device must comply
with International Electrotechnical Commission (IEC) 60825.
Technical Product Specification
151
Download from Www.Somanuals.com. All Manuals Search And Download.
®
Intel NetStructureTMZT 7102 Chassis Management Module
Agency Approvals
152
Technical Product Specification
Download from Www.Somanuals.com. All Manuals Search And Download.
|