IBM POWER9 Systems LC Server Firmware
Applies to: AC922 (8335-GTH) and AC922 (8335-GTX)
This document provides information about the installation of Licensed Machine or Licensed Internal Code, which is sometimes referred to generically as microcode or firmware.
This package provides firmware for the Power System AC922 (8335-GTH) and AC922 (8335-GTX) servers only.
These systems, if updating from OP920, will have P9 DD2.2 processors. New systems manufactured at the OP930 level will have either P9 DD2.2 or P9 DD2.3 processors.
OP930 supports only DD2.2 and DD2.3 processor versions.
The firmware level in this package is:
•OP930.00 / PNOR OP9_v2.3-rc2-3.23 and openBMC ibm-v2.3-476-r39
This section specifies the "Minimum ipmitool Code Level" required by the System Firmware for managing the system. OpenPOWER requires ipmitool level v1.8.15 or later to execute correctly on the OP910 and later firmware. It must be capable of establishing a IPMI v2 session with the ipmi support on the BMC.
Verify your ipmitool level on your Linux workstation using the following command:
bash-4.1$ ipmitool -V
ipmitool version 1.8.15
If you are need to update or add impitool to your Linux workstation , you can compile ipmitools (current level 1.8.15) for Linux as follows from Sourceforge:
1.1.1 Download impitool tar from http://sourceforge.net/projects/ipmitool/ to your linux system
1.1.2 Extract tarball on Linux system
1.1.3 cd to top-level directory
1.1.4 ./configure
1.1.5 make
1.1.6 ipmitool will be under src/ipmitool
You may also get the ipmitool package directly from your workstation Linux packages.
For specific fix level information on key components of IBM Power Systems LC and Linux operating systems, please refer to the documentation in the IBM Knowledge Center for the AC922 (8335-GTH) and AC922(8335-GTX):
https://www.ibm.com/support/knowledgecenter/en/POWER9/p9hdx/8335_gth_landing.htm
https://www.ibm.com/support/knowledgecenter/en/POWER9/p9hdx/8335_gtx_landing.htm
If using xCAT on the host OS to do firmware updates, the minimum xCAT level that should be used is 2.13.4 because it has stability improvements for the firmware update process. See the xCAT 2.13.4 release notes below for more information.
https://github.com/xcat2/xcat-core/wiki/XCAT_2.13.4_Release_Notes
The Linux OS has a NVIDIA CUDA driver that must be at recommended level 396.44 or later, or minimum level 396.26 to be compatible with OP920.00 and later levels. Without this driver, a GPU which has faulted and gone through a GPU reset can cause a Terminate Immediate (TI) for the system. The recommended level for the NVIDIA CUDA driver is level 396.44 to get ATS performance improvements.
The Power AC922 server delivers four Tesla V100 with NVLink GPUs supported in two processor sockets.
The Tesla CUDA driver can be obtained at the download NVIDIA link of “https://www.nvidia.com/content/DriverDownload-March2009/confirmation.php?url=/tesla/396.44/nvidia-driver-local-repo-rhel7-396.44-1.0-1.ppc64le.rpm&lang=us&type=Tesla”
The NVIDIA "http://www.nvidia.com/Download/index.aspx?lang=en-us" link using the following information can be used to do a manual search for the driver:
Manually find drivers for my NVIDIA products.
Product Type: Tesla
Product Series: V-Series
Product: Tesla V100
Operating System: Linux POWER LE RHEL 7
CUDA Toolkit: 9.2
Language: English(US)
Search results:
Version: 396.44
Release Date: 2018.8.6
Operating System: Linux POWER LE RHEL 7
CUDA Toolkit: 9.2
Language: English (US)
File Size: 47.28 MB
On Red Hat Enterprise Linux (RHEL) for PPC, RHEL-Alt 7.5, The Trusted Platform Module (TPM) device driver is not loaded automatically at boot time. Without this driver, the TPM device will not be accessible.
This affects any user-space application needing to access the TPM, as well as kernel security functions, such as the Integrity Measurement Architecture subsystem (IMA) in the Linux kernel. Without the TPM driver loaded, IMA will be unable to record trusted measurements to the TPM.
To load the driver manually, as root:
# modprobe tpm_i2c_nuvoton
To load the driver automatically at boot time:
# echo "tpm_i2c_nuvoton" > /etc/modules-load.d/tpm.conf"
The TPM device driver will be integrated as a built-in kernel module in a future release 7 of RHEL-Alt. Once this is done, it will be loaded automatically and this procedure will no longer be necessary.
Downgrading firmware from any given release level to an earlier release level is not recommended.
If you feel that it is necessary to downgrade the firmware on your system to an earlier release level, please contact your next level of support.
Concurrent Firmware Updates not available for LC servers.
Concurrent system firmware update is not supported on LC servers.
During one of the first IPLs of the system, in rare cases, the system may either kernel panic or crash due to a HMI and reboot. The BMC console signatures are as follows:
[ 170.281625] Faulting instruction address: 0xc00000000822a0c0
[ 170.281698] Thread overran stack, or stack corrupted
[ 170.281767] Oops: Kernel access of bad area, sig: 11 [#443]
[ 170.281834] LE SMP NR_CPUS=2048 NUMA PowerNV
[ 170.281890] Modules linked in:
[ 170.281892] Unable to handle kernel paging request for data at address 0xfffffffffffffff8
[285402.253760069,7] HMI: Received HMI interrupt: HMER = 0x8040000000000000
[285402.267399301,3] HMI: _________________________
[285402.267438236,3] HMI: < It's Driver Debug time! >
[285402.267469320,3] HMI: -------------------------
[285402.267510142,3] HMI: \ ,__,
[285402.267542350,3] HMI: \ (oo)____
[285402.267578707,3] HMI: (__) )\
[285402.267612119,3] HMI: ||--|| *
[285402.267796791,3] HMI: NPU2: [Loc: UOPWR.787081A-Node0-Proc1] P:8 FIR#0 FIR 0x0000100008000000 mask 0x009a48180f03ffff
[285249[285402.267899526,3] HMI: NPU2: [Loc: UOPWR.787081A-Node0-Proc1] P:8 ACTION0 0x7f60b04500ae0000, ACTION1 0xff65b04700fe0000
.644496] Hypervisor Maintenance interrupt [Recovered]
[285249.644928] Error detail: Malfunction Alert
[285249.644988] HMER: 8040000000000000
[285249.645032] Unknown Malfunc[285402.268002011,3] HMI:
In this console output, if any of the following register addresses have the first nibble set to 0x2 then it is the error of concern.
[2019-06-06T13:46:28-04:00] [4135415.111242179,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011017=0x0000000000000000
[2019-06-06T13:46:28-04:00] [4135415.111244973,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011047=0x0000000000800000
[2019-06-06T13:46:28-04:00] [4135415.111247753,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011077=0x0000000000000000
[2019-06-06T13:46:28-04:00] [4135415.111250499,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x050110a7=0x0000000000000000
[2019-06-06T13:46:28-04:00] [4135415.111253198,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011217=0x0000000000000000
[2019-06-06T13:46:28-04:00] [4135415.111255899,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011247=0x0000000000800000
[2019-06-06T13:46:28-04:00] [4135415.111258642,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011277=0x2000010000000000
[2019-06-06T13:46:28-04:00] [4135415.111261405,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x050112a7=0x2000010000000000
[2019-06-06T13:46:28-04:00] [4135415.111264176,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011417=0x2000020000000000
[2019-06-06T13:46:28-04:00] [4135415.111266962,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011447=0x2000020000800000
[2019-06-06T13:46:28-04:00] [4135415.111269712,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x05011477=0x0000000000000000
[2019-06-06T13:46:28-04:00] [4135415.111272427,3] HMI: NPU2: [Loc: UOPWR.789938A-Node0-Proc0] P:0 0x050114a7=0x0000000000000000
In the case above, registers 0x05011277, 0x050112a7, 0x05011417, 0x05011447 are examples of this.
NOTE: This will not result with any hardware being deconfigured and the system should simply reboot back into a working state. In the SEL logs, events "FQPSPAA0007G - A system checkstop occurred" and "FQPSPAA0001M - An unknown problem occurred" can be seen.
If the system has rebooted, no action is needed for recovery. Otherwise, reboot the system. This failure is rare and is not expected to recur after a reboot of the system.
The 8335-GTG model is not supported for the OP920.xx release or OP930 release. However, the 8335-GTG may be upgraded to a 8335-GTH model by a SSR. These steps involve replacing the hardware processor features in the 8335-GTG and then updating to the alternative PNOR and BMC images, which can be found in Fix Central as part of the initial OP920.00 delivery. At the successful conclusion of the upgrade steps, the system model will be 8335-GTH with the OP920.00 release firmware. You may then update to this latest level of firmware.
The existing processors being replaced during a model or feature conversion become the property of IBM and must be returned. Feature conversions are always implemented on a "quantity of one for quantity of one" basis. Multiple existing features may not be converted to a single new feature. Single existing features may not be converted to multiple new features.
Feature conversions for 8335-GTG to 8335-GTH for processor features:
From FC | To FC | Return Parts? |
EP0K - 16-core 2.60 GHz (3.09 GHz Turbo) POWER9 Processor | EP0P - 16-core 2.7 GHz (3.3 GHz Turbo) POWER9 Processor | Yes |
EP0M - 20-core 2.0 GHz (2.87 GHz Turbo) POWER9 Processor | EP0R - 20-core 2.4 GHz (3.0 GHz Turbo) POWER9 Processor | Yes |
•witherspoon-IBM-OP9-v2.0-2.14-cfm_prod.pnor.squashfs.tar - alternative pnor image for use in the gtg to gth upgrade option.
•obmc-witherspoon-ibm-v2.1-cfm.ubi.mtd.tar - alternative bmc image for use in the GTG to GTH upgrade option.
(Note that these files exist only under the OP920.00 delivery in Fix Central)
Use the following examples as a reference to determine whether your installation will be concurrent or disruptive.
For the LC server systems, the installation of system firmware is always disruptive.
The BMC and PNOR image tar files are used to update the primary side of the PNOR and the primary side of the BMC only, leaving the golden sides unchanged.
Filename | Size | Checksum |
obmc-witherspoon-ibm-v2.3.ubi.mtd.tar | 24023040 | 5ff23b60c6cad376ce823b0237bfed11 |
witherspoon-IBM-OP9-v2.3-rc2-3.23_prod.pnor.squashfs.tar | 27095040 | 9ef7af7730c740feedfd984a1ab2d8aa |
|
|
|
Note: The Checksum can be found by running the Linux/Unix/AIX md5sum command against the Hardware Platform Management (hpm) file (all 32 characters of the checksum are listed), ie: md5sum <filename>
After a successful update to this firmware level, the PNOR components and BMC should be at the following levels.
To display the PNOR level, use the following BMC command:
"cat /var/lib/phosphor-software-manager/pnor/ro/VERSION | grep -A 12 IBM ".
The grep is needed to remove a security string at the start of the VERSION output for easier viewing of the PNOR level.
And the BMC command line command "cat" can be used to display the BMC level: "cat /etc/os-release".
Note: FRU information for the PNOR level does not show the updated levels via the fru command until the system has been booted once at the updated level.
PNOR firmware level: driver content
IBM-witherspoon-OP9-v2.3-rc2-3.23-prod
op-build-v2.3-rc2-68-g092f6b5
buildroot-2019.02.1-16-ge01dcd0
skiboot-v6.3.1-p5b160db
hostboot-d260b57
occ-58e422d
linux-5.0.7-openpower1-pd4a27b8
petitboot-v1.10.3
machine-xml-e3e9aef
hostboot-binaries-hw051119a.op930
capp-ucode-p9-dd2-v4
sbe-d531c59
hcode-hw060519a.op930
OpenBMC firmware level : driver content
display BMC FW level via ssh session on the BMC , using this cmd:
root@witherspoon:~# cat /etc/os-release
BMC Primary side version:
ID: openbmc-phosphor
NAME: Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)
VERSION: "ibm-v2.3"
VERSION_ID "ibm-v2.3-476-g2d622cb-r39-0-g720ff0e"
PRETTY_NAME "Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) ibm-v2.3"
BUILD_ID "ibm-v2.3-476-g2d622cb-r39"
OP930 | |
|
|
OP9_v2.3-rc2-3.23 / BMC ibm_v2.3-476-r39 / OP930.00
06/24/2019 | Impact: New Severity: New
GA Level
New features and functions for MTM 8335-GTH and 8335-GTX:
Support was added for DD2.3 version P9 processors
Support for OpenCAPI (Coherent Accelerator Processor Interface) development using OpenCAPI 3.0, 3.1, and 4.0 transaction layers.
Support has been dropped for less secure ciphers for secure shell (ssh) connections. If your ssh client has been relying on these to be able to connect to the BMC, you might not be able to connect. This affects older clients such as RHEL 6 and Ubuntu 14.04.
Support NVLink 2.0 passthrough to the GPU from a virtual machine guest OS.
System firmware changes that affect all systems
A problem was fixed for NPU checkstops by disabling Probe-to-Invalid-Return-Modified-or-Owned snarfing by default. To enable snarfing, the user needs to run: "sudo nvram -p ibm,skiboot --update-config opal-npu2-snarf-cpm=enable". The snarfing feature is designed to to detect two GPU NPU probes in flight and combine them into one but in some cases it was triggering the NPU checkstops.
A problem was fixed for IPLs that may, on rare occasions, fail with a Hostboot timeout error with message like "Unrecoverable Hardware Failure, (Critical) Hostboot procedure callout." This failure will halt the IPL and a re-IPL should fully recover the system from the failure. The system will recover and re-IPL from the fault without user intervention if the Auto-Reboot policy is enabled (the factory default setting). If the user has set Auto-Reboot policy to disabled, then the server will remain in the halt state if it encounters such a failure and will require the user to power off/on/reboot to IPL again successfully. If the error persists, the user should follow any service procedures provided with the error log which may include an action to determine and apply the latest level of system firmware on the server. A final action would be to contact IBM Support for assistance. Here is an example what would be seen in the system SEL list for the problem: ----Active Alerts---- Entry | ID | Timestamp | Serviceable | Severity | Message | eSEL contents 1 | FQPSPCR0023M | 2019-02-08 20:14:39 | Yes | Critical | Hostboot has become unresponsive | None 2 | FQPSPCR0023M | 2019-02-08 23:04:40 | Yes | Critical | Hostboot has become unresponsive | None The IBM Knowledge Center document on this problem is titled " FQPSPCR0023M" and can be found at the following link: https://www.ibm.com/support/knowledgecenter/en/POWER9/p9ia7/FQPSPCR0023M.htm.
A problem was fixed for memory DIMMs becoming incorrectly deconfigured after a large number of system IPLs. This is a rare problem that happens intermittently after many IPLs of the system.
A problem was fixed for host OS crashes because of locked CPUs after the BMC is reset.
A problem was fixed for fans being disabled and not showing up on the GUI sensors, but on the physical system the fans are running very fast. Rebooting the BMC should recover the fan sensors.
|
OS levels supported by the LC 8335 servers:
- Red Hat Enterprise Linux 8 for POWER, or later, with all available maintenance updates
- Red Hat Enterprise Linux 7 for POWER9, version 7.6, or later, with all available maintenance updates
- NVIDIA Telsa CUDA recommended driver level 396.44 or later, or minimum driver level 396.26 from the CUDA 9.2 toolkit
Additional OS level supported by the AC922(8335-GTH) server:
- Ubuntu Server 18.04.1, with all available maintenance updates.
IBM Power LC 8335 servers supports Linux which provides a UNIX like implementation across many computer architectures. Linux supports almost all of the Power System I/O and the configurator verifies support on order. For more information about the software that is available on IBM Power Systems, see the Linux on IBM Power Systems website:
http://www.ibm.com/systems/power/software/linux/index.html
The Linux operating system is an open source, cross-platform OS. It is supported on every Power Systems server IBM sells. Linux on Power Systems is the only Linux infrastructure that offers both scale-out and scale-up choices.
A supported version of Linux on the Power LC 8335 is Red Hat Enterprise Linux 7.5 for IBM Power LE (POWER9) (RHEL 7.5-ALT LE).
For additional questions about the availability of this release and supported Power servers, consult the Red Hat Hardware Catalog at
https://access.redhat.com/products/red-hat-enterprise-linux/#addl-arch.
For the AC922 (8335-GTH) that is configured without GPUs, there is the option of using Linux Ubuntu 18.04 or later as the OS.
For more information about Linux on Power, see the Linux on Power developer center at https://developer.ibm.com/linuxonpower/
For information about the features and external devices that are supported by Linux, see this website:
http://www.ibm.com/systems/power/software/linux/index.html
Use one of the following commands at the Linux command prompt to determine the current Linux level:
•cat /proc/version
•uname -a
The output string from the command will provide the Linux version level.
The opal-prd package on the Linux system collects the OPAL Processor Recovery Diagnostics messages to log file /var/log/syslog. It is recommended that this package be installed if it is not already present as it will help with maintaining the system processors by alerting the users to processor maintenance when needed.
On Red Hat Linux, perform command "rpm -qa | grep -i opal-prd ". The command output indicates the package is installed on your system if the rpm for opal-prd is found and displayed. This package provides a daemon to load and run the OpenPOWER firmware's Processor Recovery Diagnostics binary. This is responsible for run-time maintenance of Power hardware. If the package is not installed on your system, the following command can be run on Red Hat to install it:
sudo yum update opal-prd
To display the PNOR level, use the following BMC command:
"cat /var/lib/phosphor-software-manager/pnor/ro/VERSION | grep -A 12 IBM ".
The grep is needed to remove a security string at the start of the VERSION output for easier viewing of the PNOR level.
And the BMC command line command "cat" can be used to display the BMC level: "cat /etc/os-release".
Note: the "cat" commands are run after ssh to the BMC as root and the default password is 0penBmc (where 0 is the zero character).
Follow the instructions on Fix Central. You must read and agree to the license agreement to obtain the firmware packages.
The updating and upgrading of system firmware depends on several factors, such as the current firmware that is installed, and what operating systems is running on the system.
These scenarios and the associated installation instructions are comprehensively outlined in the firmware section of Fix Central, found at the following website:
http://www.ibm.com/support/fixcentral/
Any hardware failures should be resolved before proceeding with the firmware updates to help insure the system will not be running degraded after the updates.
The process of updating firmware on the OpenBMC managed servers is documented below.
The sequence of events that must happen is the following:
•Power off the Host
•Update and Activate BMC
•Update and Activate PNOR
•Reboot the BMC (applies new BMC image)
•Power on the Host (applies new PNOR image)
The OpenBMC firmware updates (BMC and PNOR) for the LC 8335 servers can be managed via the command line with the openbmctool.
The openbmctool is obtained using the IBM Support Portal.
1.Go to the IBM Support Portal.
2.In the search field, enter your machine type and model. Then click the correct product support entry for your system.
3.From the Downloads list, click the openbmctool for your machine type and model.
4.Follow the instructions to install and run the openbmctool. You will need to provide the file locations of the BMC firmware image tar and PNOR firmware image tar that must be downloaded from Fix Central for the update level needed.
Information on the openbmctool and the firmware update process can be found in the IBM Knowledge Center:
https://www.ibm.com/support/knowledgecenter/POWER9/p9ei8/p9ei8_update_firmware_openbmctool.htm .
The service processor, or baseboard management controller (BMC), provides a hypervisor and operating system-independent layer that uses the robust error detection and self-healing functions that are built into the POWER processor and memory buffer modules. OpenPOWER application layer (OPAL) is the system firmware in the stack of POWER processor-based Linux-only servers.
The service processor, or baseboard management controller (BMC), is the primary control for autonomous sensor monitoring and event logging features on the LC server.
The BMC supports the Intelligent Platform Management Interface (IPMI) for system monitoring and management. The BMC monitors the operation of the firmware during the boot process and also monitors the OPAL hypervisor for termination.
The OpenPOWER Abstraction Layer (OPAL) provides hardware abstraction and run time services to the running host Operating System.
For the 8335 servers, only the OPAL bare-metal installs can be used.
Find out more about OPAL skiboot here:
https://github.com/open-power/skiboot
The Intelligent Platform Management Interface (IPMI) is an open standard for monitoring, logging, recovery, inventory, and control of hardware that is implemented independent of the main CPU, BIOS, and OS. The LC 8335 servers provide one 10M/100M baseT IPMI port.
The ipmitool is a utility for managing and configuring devices that support IPMI. It provides a simple command-line interface to the service processor. You can install the ipmitool from the Linux distribution packages in your workstation, sourceforge.net, or another server (preferably on the same network as the installed server).
For installing ipmitool from sourceforge, please see section 1.1 "Minimum ipmitool Code Level".
For more information about ipmitool, there are several good references for ipmitool commands:
The man page
The built-in command line help provides a list of IPMItool commands:
# ipmitool help
You can also get help for many specific IPMItool commands by adding the word help after the command:
# ipmitool channel help
For a list of common ipmitool commands and help on each, you may use the following link:
www.ibm.com/support/knowledgecenter/linuxonibm/liabp/liabpcommonipmi.htm
To connect to your host system with IPMI, you need to know the IP address of the server and have
a valid password. To power on the server with the ipmitool, follow these steps:
1. Open a terminal program.
2. Power on your server with the ipmitool:
ipmitool -I lanplus -H bmc_ip_address -P ipmi_password power on
3. Activate your IPMI console:
ipmitool -I lanplus -H bmc_ip_address -P ipmi_password sol activate
Petitboot is a kexec based bootloader used by IBM POWER9 systems for doing the bare-metal installs on the 8335 servers.
After the POWER9 system powers on, the petitboot bootloader scans local boot devices and network interfaces to find boot options that are available to the system. Petitboot returns a list of boot options that are available to the system. If you are using a static IP or if you did not provide boot arguments in your network boot server, you must provide the details to petitboot. You can configure petitboot to find your boot with the following instructions:
https://www.ibm.com/support/knowledgecenter/linuxonibm/liabp/liabppetitbootadvanced.htm
You can edit petitboot configuration options, change the amount of time before Petitboot automatically boots, etc. with these instructions:
https://www.ibm.com/support/knowledgecenter/linuxonibm/liabp/liabppetitbootconfig.htm
After you select to boot the ISO media for the Linux distribution of your choice, the installer wizard for that Linux distribution walks you through the steps to set up disk options, your root password, time zones, and so on.
You can read more about the petitboot bootloader program here:
https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html
This guide helps you install Linux on Power Systems server.
Overview
Use the information found in http://www.ibm.com/support/knowledgecenter/linuxonibm/liabw/liabwkickoff.htm to install Linux on a non-virtualized (bare metal) IBM Power LC server.
Date | Description |
08/02/2019 | Update instructions for retrieving PNOR version |
06/24/2019 | New for AC922 LC servers for the OP930.00 release |