The Tests¶
OpTestAt24driver¶
At24(Atmel24) eeprom driver to support openpower platform
This driver has following functionalities:
‘at24’ is the i2c client driver that interface the EEPROMs on the system.
In P8 system, EEPROM devices contain the system VPDs information and this driver is capable of reading and programming the data to these devices.
-
class
testcases.AT24driver.
AT24driver
(methodName='runTest')[source]¶ -
host_hexdump
(i_dev)[source]¶ The hexdump utility is used to display the specified files. This function will display in both ASCII+hexadecimal format.
- Param
i_dev: this is the file used as a input to hexdump for display info
- Raises
-
runTest
()[source]¶ This function has following test steps
Getting the host infromation(OS and kernel information)
Loading the necessary modules to test at24 device driver functionalites (i2c_dev, i2c_opal and at24)
Getting the list of i2c buses and eeprom chip addresses
Accessing the registers visible through the i2cbus using i2cdump utility
Getting the eeprom device data using hexdump utility in hex + Ascii format
-
Basic IPL and reboot tests¶
These can be used as tests themselves to check all IPL and reboot types, or can be invoked on the command line to boot the machine a certain way or into a specific state.
-
class
testcases.BasicIPL.
BMCReset
(methodName='runTest')[source]¶ Reboot the BMC with the host off. This will check that the host is also powered off when the BMC comes back.
-
class
testcases.BasicIPL.
BMCResetThenRebootHost
(methodName='runTest')[source]¶ Reboot the BMC with the host on and once the BMC is back, reboot the host.
-
class
testcases.BasicIPL.
BootToOS
(methodName='runTest')[source]¶ Boot the default Operating System on the Host.
This will force and IPL and then look to get to a login prompt.
-
class
testcases.BasicIPL.
BootToPetitboot
(methodName='runTest')[source]¶ Boot to the Petitboot menu. It does not cancel any automatic boot countdown sequence.
It will force the machine off first, so it will do an IPL.
-
class
testcases.BasicIPL.
BootToPetitbootShell
(methodName='runTest')[source]¶ Boot to the Petitboot shell (i.e. pressing ‘x’ when the petitboot menu comes up).
It will force the machine off first, so it will do an IPL.
-
class
testcases.BasicIPL.
GotoPetitbootShell
(methodName='runTest')[source]¶ We goto petitboot shell rather than do the off/on-to-petitboot shell so that the skiroot test suite time to run each test is a bit more accurate, rather than hiding the first IPL in the first test that’s run.
-
class
testcases.BasicIPL.
HardPowerCycle
(methodName='runTest')[source]¶ Get to Petitboot, then issue a hard power cycle from the BMC, checking that we can get back to Petitboot.
-
class
testcases.BasicIPL.
OutOfBandWarmReset
(methodName='runTest')[source]¶ Does an IPL to petitboot, and then do a ‘warm reset’, checking that we can boot back up to Petitboot.
BMCResetTorture¶
This testcase does BMC reset torture in different scenarios.
-
class
testcases.BMCResetTorture.
BMCResetvsHostIPLTorture
(methodName='runTest')[source]¶ Repeatedly does the BMC Reset vs Host IPL Torture
-
class
testcases.BMCResetTorture.
RuntimeBMCResetTorture
(methodName='runTest')[source]¶ Repeatedly does the BMC Reset at runtime (i.e at both skiroot and host)
BootTorture:¶
Torture the machine with repeatedly trying to boot
Sample naming conventions below, see each test method for the applicable options per method.
- –run testcases.BootTorture.BootTorture
- ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^
module name subclass
- –run testcases.BootTorture.BootTorture10
- ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
module name subclass
-
class
testcases.BootTorture.
BootTorture
(methodName='runTest')[source]¶ BootTorture x1024
–run testcases.BootTorture.BootTorture
-
class
testcases.BootTorture.
BootTorture10
(methodName='runTest')[source]¶ Just boot 10 times. Just a little bit of peril.
–run testcases.BootTorture.BootTorture10
Console Bug 150765¶
A regresion test for a specific bug observed on FSP based systems.
Make sure ipmi sol console is connected before running this test Observe sol console messages while system IPL’s for two times For second IPL, Petitboot Kernel messages will not come on active SOL console.
Console tests¶
A bunch of really simple console tests that have managed to break every BMC implementation we’ve ever thrown it at. Since we’re highly reliant on the BMC providing a reliable host console, if these tests fail at all, then we’re likely going to get spurious failures elsewhere in the test suite.
-
class
testcases.Console.
Console16k
(methodName='runTest')[source]¶ hexdump 16kb of zeros and check we get all the lines of hexdump output on the console.
–run testcases.Console.Console16k
-
class
testcases.Console.
Console32k
(methodName='runTest')[source]¶ hexdump 32kb of zeros and check we get all the lines of hexdump output on the console. The idea is that console buffers on BMCs are likely to be less than 32kb, so we’ll be able to catch any silent wrapping of it.
–run testcases.Console.Console32k
-
class
testcases.Console.
Console8k
(methodName='runTest')[source]¶ hexdump 8kb of zeros and check we get all the lines of hexdump output on the console.
–run testcases.Console.Console8k
CPU Hotplug Testcase¶
This test case is likely to catch bugs either in the kernel or in stop states we put cores/threads into when we hot unplug them.
-
class
testcases.CpuHotPlug.
CpuHotPlug
(methodName='runTest')[source]¶ Use the
ppc64_cpu
utility to turn SMT on/off and set to each possible SMT mode, which is effectively a CPU hotplug operation. Then start hotplugging CPU cores by using theppc64_cpu
utility to turn only a specific number of cores on.
DeviceTreeValidation¶
Check a bunch of device tree properties and structure for validity, and compare device tree in host and skiroot environments.
DeviceTreeWarnings¶
Check for any warnings from tools such as dtc
in our device tree.
Delayed Power Off (DPO)¶
Delayed Power off testcase is to test OS graceful shutdown request to be notified from OPAL and OS should process the request. We will use “ipmitool power soft” command to issue DPO.
EnergyScale_BaseLine¶
This test is somewhat re-implementing the EnergyScale_BaseLine plugin for DVT except it’s not perfect, and don’t bet that it is the same as it’s only based on a log of a test run rather than the source code for that test.
EPOW (Emergency POWer off)¶
This module tests the EPOW feature incase of FSP systems.
EPOW3Random.
Simulate random EPOW3 temperature to check whether OPAL notify EPOW notification to Host OS. Once Host gets notified Host should do a graceful shutdown.
EPOW3LOW
Simualate temperatures less than EPOW3 threshold and check whether Host OS is alive or not.
-
class
testcases.EPOW.
EPOW3LOW
(methodName='runTest')[source]¶ This test case will follow below procedure:
Based on Nebsenabled will get EPOW limits from FSP using def file present in /opt/fips/components/engd/. Different systems have different EPOW limits.
Test EPOW3_LOW—> Will test temperatures lower than EPOW3 temperature, a. From FSP it simulate to lesser ambient temperatures than EPOW3 temperature b. In this case system should be alive and it should not cause system shut-down.
If user faces any problem in bringing the system UP please run below command “smgr toolReset” in fsp console
-
class
testcases.EPOW.
EPOW3Random
(methodName='runTest')[source]¶ This testcase tests the EPOW feature of the FSP. Thus, it is only applicable to FSP based systems and will be skipped on other BMC types.
This test will:
It will gather EPOW limits
We will choose some random EPOW temp(test_temp) in b/w those limits
Simulate that temperature(test_temp)
Verify graceful shutdown happened or not
Once system reaches standby, simulate the ambient temp to EPOW3_RESET temperature(reset_temp) to bring back the system.
Bring back the system again to runtime.
If user faces any problem in bringing the system UP please run below command “smgr toolReset”
fspresetReload¶
FSP initiated reset
Host initiated reset
Once reset is done, verify host-fsp firmware interfaces
FSP TOD Corruption¶
Corrupt TOD and check host boot and runtime behaviours
FWTS¶
Run the Canonical FirmWare Test Suite (FWTS, see https://wiki.ubuntu.com/FirmwareTestSuite for details).
Largely, if we can implement a test as part of FWTS, we should do it there as it’s easy to run and packaged.
gcov¶
A “Test Case” for extracting GCOV code coverage data from skiboot. The real use of this test case and code is to help construct code coverage reports for skiboot.
-
class
testcases.gcov.
Skiroot
(methodName='runTest')[source]¶ Extract GCOV code coverage in skiroot environment.
-
class
testcases.gcov.
gcov
[source]¶ Base “test case” for extracting skiboot GCOV code coverage data from the host (use the Skiroot and Host TestCases for running this code).
This requires a GCOV build of skiboot.
We (rather convolutedly) do a HTTP POST operation (through shell!) back to the op-test process as since we may be running in skiroot, we don’t have all the nice usual ways of transferring files around. The good news is that implementing a simple HTTP POST request in shell isn’t that hard.
HelloWorld¶
A really simple Hello World test, just to check that we can run a test case.
Only useful as a unittest of op-test itself.
I2C tests¶
This class will test functionality of following drivers: I2C Driver(Inter-Integrated Circuit) driver
-
class
testcases.I2C.
FullI2C
(methodName='runTest')[source]¶ This test has following test steps:
Getting host information(OS and kernel info)
Checking the required utilites are present on host or not
Loading the necessary modules to test I2C device driver functionalites (i2c_dev, i2c_opal and at24)
Getting the list of i2c buses
Querying the i2c bus for devices
Getting the list of i2c buses and eeprom chip addresses
Accessing the registers visible through the i2cbus using i2cdump utility
Listing the i2c adapter conetents and i2c bus entries to make sure sysfs entries created for each bus.
Testing i2cget functionality for limited samples
Avoiding i2cset functionality, it may damage the system.
-
class
testcases.I2C.
I2C
[source]¶ Base class for I2C tests
-
host_get_info_of_eeprom_chips
()[source]¶ This function will get information of EEPROM chips attached to the i2c buses
- Returns
str EEPROM chips information
- Raises
-
host_get_list_of_eeprom_chips
()[source]¶ It will return list with elements having pairs of eeprom chip addresses and corresponding i2c bus where the chip is attached. This information is getting through sysfs interface. format is
["0 0x50","0 0x51","1 0x51","1 0x52"....]
- Returns
list – list having pairs of i2c bus number and eeprom chip address.
- Raises
-
host_get_list_of_i2c_buses
()[source]¶ This function will return the list of installed i2c buses on host in two formats:
list-by number, e.g.
["0","1","2",....]
list-by-name, eg
["i2c-0","i2c-1","i2c-2"....]
- Returns
(l_list, l_list1) : list of i2c buses by number, list of i2c buses by name
- Raises
-
host_hexdump
(i_dev)[source]¶ The hexdump utility is used to display the specified files. This function will display in both ASCII+hexadecimal format.
- Param
i_dev: this is the file used as a input to hexdump for display info
- Raises
-
i2c_dump
(i_args)[source]¶ This i2cdump function takes arguments in pair of a string like “i2cbus address”. i2cbus indicates the number or name of the I2C bus to be scanned. This number should correspond to one of the busses listed by i2cdetect -l. address indicates the address to be scanned on that bus, and is an integer between 0x03 and 0x77 i2cdump is a program to examine registers visible through the I2C bus.
The command may fail due to problems with the device, hardware, or firmware.
- Parameters
i_args (str) – this is the argument to i2cdump utility. Arguments are in the form of “i2c-bus-number eeprom-chip-address” e.g.
0 0x51
,3 0x52
-
i2c_get
(i_args, i_addr)[source]¶ This function i2cget read from I2C/SMBus chip registers.
command usage:
i2cget [-f] [-y] i2cbus chip-address [data-address [mode]]
- Parameters
i_args (str) – this is the argument to i2cget utility. Arguments are in the form of “i2c-bus-number eeprom-chip-address” e.g.
0 0x51
,3 0x52
i_addr – this is the data-address on chip, from where data will be read. e.g. “0x00”,”0x10”,”0x20”…
- Returns
data present on data-address
-
i2c_set
(i_args, i_addr, i_val)[source]¶ This function i2cset will be used for setting I2C registers.
command usage:
i2cset [-f] [-y] [-m mask] [-r] i2cbus chip-address data-address [value] ... [mode]
- Parameters
i_args (str) – this is the argument to i2cset utility. Arguments are in the form of “i2c-bus-number eeprom-chip-address” e.g.
0 0x51
,3 0x52
….etci_addr (str) – this is the data-address on chip, where data will be set e.g. 0x00”,”0x10”,”0x20”…
i_val (str) – this is the value which will be set into data-address i_addr
-
Install HostOS¶
Installs HostOS on the host.
Install RHEL¶
Installs RedHat Enterprise Linux (RHEL) on the host.
Install Ubuntu¶
Installs Ubuntu on the host.
The idea behind this test is to both set up an OS suitable to run op-test against and check our backwards compatibility with installation media.
IPL Params¶
This test verifies certain fw features are enabled/disabled during IPL time as per expectation. These features will control run time enablement of certain components.
IPMI Torture¶
Use several threads in op-test to poke IPMI concurrently in a number of “safe” ways, and see when the BMC explodes.
-
class
testcases.IpmiTorture.
InbandIpmiThread
(threadID, name, ipmi_method, cmd, execution_time)[source]¶ -
run
()[source]¶ Method representing the thread’s activity.
You may override this method in a subclass. The standard run() method invokes the callable object passed to the object’s constructor as the target argument, if any, with sequential and keyword arguments taken from the args and kwargs arguments, respectively.
-
-
class
testcases.IpmiTorture.
OobIpmiThread
(threadID, name, cmd, execution_time)[source]¶ -
run
()[source]¶ Method representing the thread’s activity.
You may override this method in a subclass. The standard run() method invokes the callable object passed to the object’s constructor as the target argument, if any, with sequential and keyword arguments taken from the args and kwargs arguments, respectively.
-
-
class
testcases.IpmiTorture.
SolConsoleThread
(threadID, name, test, execution_time)[source]¶ -
run
()[source]¶ Method representing the thread’s activity.
You may override this method in a subclass. The standard run() method invokes the callable object passed to the object’s constructor as the target argument, if any, with sequential and keyword arguments taken from the args and kwargs arguments, respectively.
-
Kernel Log¶
Check the Linux kernel log in skiroot and the OS for warnings and errors, filtering for known benign problems (or problems that are just a Linux issue rather than a firmware issue).
LightPathDiagnostics¶
Currently runs only in FSP platforms.
-
class
testcases.LightPathDiagnostics.
UsysAttnFSPTest
(methodName='runTest')[source]¶ This function tests system attention indicator LED
-
class
testcases.LightPathDiagnostics.
UsysAttnHostTest
(methodName='runTest')[source]¶ This function tests system attention indicator LED
OpalErrorLog¶
Tests the OPAL error log functionality (as in PELs, not OPAL’s log).
Currently runs only in FSP platforms
opal-gard¶
Test different OPAL GARD Related functionality
OPAL log test¶
Look for boot and runtime warnings and errors from OPAL (skiboot).
We filter out any “known errors”, such as how PRD can do invalid SCOMs but that it’s not an error error.
OPAL sysfs Tests¶
This pokes a few bits of functionality accessible through sysfs that OPAL provides.
It includes:
System powercaps, i.e. /sys/firmware/opal/powercap/
Power Shift Ratio, i.e. /sys/firmware/opal/psr
Sensor Groups, i.e. /sys/firmware/opal/sensor_groups/
The OPAL symbol map, i.e. /sys/firmware/opal/symbol_map
Exporting of random bits of memory, i.e. /sys/firmware/opal/exports/
OpalUtils¶
Test different OPAL Utilities:
getscom
putscom
gard
pflash
OpTestCAPI¶
CAPI tests for OpenPower testing.
This class will test the functionality of CAPI
Prerequisites:
Host must have a CAPI FPGA card
CAPI card must have been flashed with memcpy AFU
Extra timebase sync tests prerequisite:
PSL must support timebase sync
-
class
testcases.OpTestCAPI.
CxlDeviceFileTest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then this test load the cxl module if required and check that the cxl device files afu0.0m and afu0.0s exist
-
class
testcases.OpTestCAPI.
CxlResetTest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then load the cxl module if required, and test reset with cxl_eeh_tests.sh and memcpy_afu_ctx.
-
class
testcases.OpTestCAPI.
KernelAPITest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then this test load the cxl and the cxl_memcpy modules if required, and test the kernel API of memcpy with memcpy_afu_ctx -K.
-
class
testcases.OpTestCAPI.
MemCpyAFUIrqTest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then this test load the cxl module if required and test the memcpy AFU with memcpy_afu_ctx -i
-
class
testcases.OpTestCAPI.
MemCpyAFUReallocTest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then this test load the cxl module if required and test the memcpy AFU with memcpy_afu_ctx -r
-
class
testcases.OpTestCAPI.
MemCpyAFUTest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then this test load the cxl module if required and test the memcpy AFU with memcpy_afu_ctx
-
class
testcases.OpTestCAPI.
SysfsABITest
(methodName='runTest')[source]¶ If a given system has a CAPI FPGA card, then this test load the cxl module if required and run the sysfs ABI tests from libcxl_tests
OpTestDumps¶
Different dumps for fsp platforms:
fipsdump
system dump
- host_dump_boottime
Trigger dump when kernel boots(either Petitboot or OS kernel)
- host_dump_runtime
Trigger dump when system is in OS or already booted to OS
- nmi_dump
Trigger system dump by sending NMI interrupts to processors
OpTestEEH¶
This testcase basically tests all OPAL EEH Error injection tests.
fenced PHB
frozen PE
-
exception
testcases.OpTestEEH.
EEHLocCodeFailed
(thing, dev, log=None)[source]¶ Failed to log location code along with failure.
-
exception
testcases.OpTestEEH.
EEHRecoveryFailed
(thing, dev, log=None)[source]¶ EEH Recovery failed on thing for reason.
-
exception
testcases.OpTestEEH.
EEHRemoveFailed
(thing, dev, log=None)[source]¶ EEH Remove failed on thing for reason.
-
class
testcases.OpTestEEH.
OpTestEEH
(methodName='runTest')[source]¶ -
check_eeh_pe_recovery
(pe)[source]¶ return True if PE is available in the system else return False. Which will be useful for checking the PE after injecting the EEH error
-
check_eeh_phb_recovery
(i_domain)[source]¶ This function is used to actually check the PHB recovery after an EEH Fenced PHB Error Injection.
We scrape the kernel log for the correct strings.
-
check_eeh_slot_resets
()[source]¶ Check for EEH Slot Reset count. i.e.
$ cat /proc/powerpc/eeh | tail -n 1 eeh_slot_resets=10
Returns integer (in above example ‘10’).
-
gather_logs
()[source]¶ This function is used to gather opal and kernel logs for each EEH iteration instead of full logs.
This should make it easier to debug problems as you’ll have the specific log messages that occured for each test.
-
get_dic_of_pe_vs_addr
()[source]¶ Get dictionary of pe vs config addr. e.g.
{'0001:0c:00.2': '2', '0001:0b:00.0': 'fb', '0001:0c:00.0': '2'}
-
get_list_of_pci_devices
()[source]¶ This function is used to get list of PCI devices available at that instant of time.
-
inject_error
(addr, e, f, phb, pe)[source]¶ Inject error:
- addr
PE address
- e
- 0
32 bit errors
- 1
64 bit errors
- f (Function)
- 0
MMIO read
- 4
CFG read
- 6
MMIO write
- 10
CFG write
- phb
PHB Index
- pe
PE BDF address
-
prepare_logs
()[source]¶ This function is used to prepare opal and kernel logs to a reference point, so that we can compare logs for each EEH iteration easily.
Basically, we throw logs in a temp file and diff them afterwards.
-
run_pe_4
(addr, e, f, phb, pe, con)[source]¶ Inject error and check for recovery, finally gather logs.
Returns True if PE recovers, False if failed to recover.
-
classmethod
setUpClass
()[source]¶ Hook method for setting up class fixture before running tests in the class.
-
set_con_log_lev_crit
()[source]¶ EEH verbose is enabled in P9. Until we have a capable of setting console log level in runtime, or EEH verbose is disabled in P9, we need to disable the console logging to make tests run. (But at the cost of one additional IPL execution overhead)
TODO: Remove this once we have a way of disabling console log level in runtime without having an additional IPL.
-
-
class
testcases.OpTestEEH.
OpTestEEHbasic_fenced_phb
(methodName='runTest')[source]¶ This testcase has below steps:
Get the list of pci PHB domains
Get the root PHB domain where the root file system is installed(We need to skip this as EEH recovery will fail on root PHB).
Start injecting the fenced PHB errors in a for loop Only one time basic check whether PHB recovered or not
-
class
testcases.OpTestEEH.
OpTestEEHbasic_frozen_pe
(methodName='runTest')[source]¶ This testcase has below steps
Get the list of pci PHB domains
Get the root PHB domain where the root file system is installed(We need to skip this as EEH recovery will fail on root PHB).
get dictionary of pe vs config addr.
Ex:
{'0001:0c:00.2': '2', '0001:0b:00.0': 'fb', '0001:0c:00.0': '2'}
Prepare below command & Start inject frozenPE errors on all PE’s
echo "PE_number:<0,1>:<function>:0:0" > /sys/kernel/debug/powerpc/PCIxxxx/err_injct
Gather necssary logs(dmesg & OPAL) and check the device(PE) got recovered or not.
-
class
testcases.OpTestEEH.
OpTestEEHmax_fenced_phb
(methodName='runTest')[source]¶ This testcase has below steps:
Get the list of pci PHB domains
Get the root PHB domain where the root file system is installed(We need to skip this as EEH recovery will fail on root PHB).
Set the MAX EEH Freeze count to 1 so that we can test max EEH Recovery capacity within less for loop executions By default it is 6,
Start injecting the fenced PHB errors two times across all PHB domains except root PHB.( As we set max EEH Freeze count to 1). So expectation is first time it should recover and second time EEH should properly remove the device and OS should not crash.
-
class
testcases.OpTestEEH.
OpTestEEHmax_frozen_pe
(methodName='runTest')[source]¶ This testcase has below steps
Get the list of pci PHB domains
Get the root PHB domain where the root file system is installed(We need to skip this as EEH recovery will fail on root PHB).
get dictionary of pe vs config addr. Ex:
{'0001:0c:00.2': '2', '0001:0b:00.0': 'fb', '0001:0c:00.0': '2'}
Prepare below command & Start inject frozenPE errors on all PE’s
echo "PE_number:<0,1>:<function>:0:0" > /sys/kernel/debug/powerpc/PCIxxxx/err_injct
Gather necssary logs(dmesg & OPAL) and check the device(PE) got recovered or not.
OpTestEM¶
Energy Management package for OpenPower testing.
This class will test the functionality of following drivers:
powernv cpuidle driver
powernv cpufreq driver
-
class
testcases.OpTestEM.
cpu_freq_states_host
(methodName='runTest')[source]¶ This test will cover following test steps:
Check the cpupower utility is available in host.
Get available cpu scaling frequencies
Set the userspace governer for all cpu’s
test the cpufreq driver by set/verify cpu frequency
-
class
testcases.OpTestEM.
cpu_idle_states_host
(methodName='runTest')[source]¶ This test will cover following test steps:
It will get the OS and kernel versions.
Check the cpupower utility is available in host.
Set the userspace governer for all cpu’s
test the cpuidle driver by enable/disable/verify the idle states
OpTestEnergyScale¶
While OpTestEM is concerned with runtime energy management such as CPU frequency scaling and stop states, OpTestEnergyScale is concerned with system level power consumption limits.
-
class
testcases.OpTestEnergyScale.
OpTestEnergyScale
(methodName='runTest')[source]¶
-
class
testcases.OpTestEnergyScale.
OpTestEnergyScaleDCMIstandby
(methodName='runTest')[source]¶ Test below dcmi commands at both standby and runtime states
ipmitool dcmi discover # This command is used to discover supported capabilities in DCMI. ipmitool dcmi power reading # Get power related readings from the system. ipmitool dcmi power get_limit # Get the configured power limits. ipmitool dcmi power sensors # Prints the available DCMI sensors. ipmitool dcmi get_temp_reading # Get Temperature Sensor Readings. ipmitool dcmi get_mc_id_string # Get management controller identifier string. ipmitool dcmi get_conf_param # Get DCMI Configuration Parameters. ipmitool dcmi oob_discover # Ping/Pong Message for DCMI Discovery.
-
class
testcases.OpTestEnergyScale.
OpTestEnergyScaleRuntime
(methodName='runTest')[source]¶ Test Energy scale features at runtime:
Power OFF the system.
Power On the system to boot to host OS
Validate below Energy scale features at runtime state
ipmitool dcmi power get_limit # Get the configured power limits. ipmitool dcmi power set_limit limit <value> # Power Limit Requested in Watts. ipmitool dcmi power activate # Activate the set power limit. ipmitool dcmi power deactivate # Deactivate the set power limit.
Once platform power limit activated execute below dcmi commands at runtime state.
ipmitool dcmi discover # This command is used to discover supported capabilities in DCMI. ipmitool dcmi power reading # Get power related readings from the system. ipmitool dcmi power get_limit # Get the configured power limits. ipmitool dcmi power sensors # Prints the available DCMI sensors. ipmitool dcmi get_temp_reading # Get Temperature Sensor Readings.
Issue Power OFF/ON to check whether system boots after setting platform power limit at runtime.
Again in runtime execute all dcmi commands to check the functionality.
-
class
testcases.OpTestEnergyScale.
OpTestEnergyScaleStandby
(methodName='runTest')[source]¶ This test will test Energy scale features at standby state:
Power OFF the system.
Validate below Energy scale features at standby state
ipmitool dcmi power get_limit # Get the configured power limits. ipmitool dcmi power set_limit limit <value> # Power Limit Requested in Watts. ipmitool dcmi power activate # Activate the set power limit. ipmitool dcmi power deactivate # Deactivate the set power limit.
Once platform power limit activated execute below dcmi commands at standby state.
ipmitool dcmi discover # This command is used to discover supported capabilities in DCMI. ipmitool dcmi power reading # Get power related readings from the system. ipmitool dcmi power get_limit # Get the configured power limits. ipmitool dcmi power sensors # Prints the available DCMI sensors. ipmitool dcmi get_temp_reading # Get Temperature Sensor Readings.
Power ON the system.
Check after system booted to runtime, whether occ’s are active or not.
Again in runtime execute all dcmi commands to check the functionality.
OpTestExample: An example test case¶
This test case is meant to show a few best practices for writing a test case for op-test.
-
class
testcases.OpTestExample.
HostBasicCheck
(methodName='runTest')[source]¶ Class for Host based tests This class allows –run testcases.OpTestExample.HostBasicCheck
-
class
testcases.OpTestExample.
OpTestExample
(methodName='runTest')[source]¶ This class is a demo to illustrate framework.
-
class
testcases.OpTestExample.
SkirootBasicCheck
(methodName='runTest')[source]¶ Class for Skiroot based tests This class allows –run testcases.OpTestExample.SkirootBasicCheck
-
testcases.OpTestExample.
host_full_suite
()[source]¶ Function used to prepare a test suite (see op-test) This allows –run-suite example Tests run in order
-
testcases.OpTestExample.
host_suite
()[source]¶ Function used to prepare a test suite (see op-test) This allows –run-suite example Tests run in order
OpTestFastReboot¶
Issue fast reboot in petitboot and host OS, on a system having skiboot 5.4 rc1(which has fast-reset feature). Any further tests on fast-reset system will be added here.
OpTestHeartbeat¶
Heartbeat tests for OpenPower testing.
This class will test the functionality of ipmi heartbeat
kopald service should be running by defaulut since host should poll OPAL at time interval requested by OPAL
OpTestHMIHandling¶
HMI Handling package for OpenPower testing.
This class will test the functionality of following.
HMI Non-recoverable errors - Core checkstop and Hypervisor resource error
HMI Recoverable errors- proc_recv_done, proc_recv_error_masked and proc_recv_again
TFMR error injections
chip TOD error injections
OpTestInbandIPMI¶
Test the inband ipmi{OPEN Interface} fucntionality package for OpenPower platform.
This class will test the functionality of following commands
bmc, channel, chassis, dcmi, echo, event, exec, firewall, fru, lan mc, pef, power, raw, sdr, sel, sensor, session, user
-
class
testcases.OpTestInbandIPMI.
BasicInbandIPMI
(methodName='runTest')[source]¶
-
class
testcases.OpTestInbandIPMI.
ExperimentalInbandIPMI
(methodName='runTest')[source]¶ -
setUp
(ipmi_method='ipmitool ')[source]¶ Hook method for setting up the test fixture before exercising it.
-
-
class
testcases.OpTestInbandIPMI.
OpTestInbandIPMI
(methodName='runTest')[source]¶ A more complete test of inband IPMI functionality.
-
sensor_byid
(i_sensor='Host Status')[source]¶ It will execute and test the ipmi sensor get <id> functionality
- Parameters
i_sensor (str) – sensor ID to retrieve data from
-
setUp
(ipmi_method='ipmitool ')[source]¶ Hook method for setting up the test fixture before exercising it.
-
test_chassis_bootdev
()[source]¶ It will execute and test the functionality of ipmi chassis bootdev <dev> where dev is none,pxe,cdrom,disk,bios,safe,diag,floppy, and none.
See the implementation for how nothing is as simple as it seems and we need weird exceptions.
-
test_dcmi
()[source]¶ It will execute and test the dcmi related ipmi commands.
- discover
This command is used to discover supported capabilities in DCMI
- Power reading
Get power related readings from the system.
- get_limit
Get the configured power limits.
- sensors
Prints the available DCMI sensors.
- get_mc_id_string
Get management controller identifier string
- get_temp_reading
Get Temperature Sensor Readings.
- get_conf_param
Get DCMI Configuration Parameters.
- oob_discover
Ping/Pong Message for DCMI Discovery
-
test_event
()[source]¶ It will execute and test event related commands to test sel functionality.
Send a pre-defined test event to the System Event Log. The following events are included as a means to test the functionality of the System Event Log component of the BMC (an entry will be added each time the event N command is executed)
Currently supported values for N are:
Temperature: Upper Critical: Going High
Voltage Threshold: Lower Critical: Going Low
Memory: Correctable ECC
-
test_fru_read
()[source]¶ It will execute and test the ipmi fru read command. then the output file is displayed by hexdump
A FIXME is to check the content of the FRU for sanity.
-
test_mc
()[source]¶ It will execute and test the management controller(mc) commands functionality.
- info
Displays information about the BMC hardware, including device revision, firmware revision, IPMI version supported, manufacturer ID, and information on additional device support.
- watchdog get
Show current Watchdog Timer settings and countdown state.
- watchdog off
Turn off a currently running Watchdog countdown timer.
- watchdog reset
Reset the Watchdog Timer to its most recent state and restart the countdown timer.
- selftest
Check on the basic health of the BMC by executing the Get Self Test results command and report the results.
- setenables
Enables or disables the given option
- getenables
Displays a list of the currently enabled options for the BMC.
- getsysinfo
Retrieves system info from bmc for given argument
-
test_pef
()[source]¶ It will execute and test pef related commands:
- info
This command will query the BMC and print information about the PEF supported features.
- status
This command prints the current PEF status
- policy
This command lists the PEF policy table entries
- list
This command lists the PEF table entries.
-
test_raw
()[source]¶ This will test raw IPMI commands. For example to query the POH counter with a raw command.
Practically speaking, this tests ipmitool itself more than any firmware or OS functionality (when compared to the non-raw test).
-
test_sdr_elist_by_type
()[source]¶ It will execute and test the commands: ipmi sdr elist <all/fru/event/mcloc/compact/full/generic>
-
test_sdr_list_by_type
()[source]¶ It will execute and test the ipmi sdr list <all/fru/event/mcloc/compact/full/generic>
-
test_sdr_type_list
()[source]¶ It will execute and test the ipmi sdr type <Temp/fan/Powersupply> commands
-
test_sel_clear
()[source]¶ It will execute the ipmi sel clear command.
Not all BMCs support this (notably simulators such as Qemu). In that case, we try anyway and skip the test rather than fail.
-
test_sel_elist
()[source]¶ It will execute and test the ipmi sel elist functionality If invoked as elist (extended list) it will also use the Sensor Data Record entries to display the sensor ID for the sensor that caused each event.
-
test_sel_list
()[source]¶ It will execute and test ipmi sel list functionality. the entire contents of the System Event Log are displayed.
-
test_sel_list_first_3_entries
()[source]¶ It will execute and test the ipmi sel list first <3 entries>
-
test_sel_list_first_n_entries
(i_num=1)[source]¶ It will execute and test the ipmi sel list first <n entries>
- Parameters
i_num (int) – The number of SELs to list
-
test_sel_list_last_n_entries
(i_num=1)[source]¶ It will execute and test the ipmi sel list last <n entries>
- Parameters
i_num (int) – The number of last SEL entries to list.
-
test_sel_set_time
()[source]¶ It will execute and test the ipmi sel set <time string> functionality Sets the SEL clock. Future SEL entries will use the time set by this command.
-
test_sel_time_get
()[source]¶ It will execute and test the ipmi sel time get functionality Displays the SEL clock’s current time.
-
test_sensor_get_host_status
()[source]¶ It will execute and test the ipmi sensor get “Host Status” functionality.
Not all BMCs support this sensor, so if we think a BMC doesn’t, and it fails, we skip the test rather than failing it.
-
OpTestInbandUsbInterface¶
Test the inband ipmi{USB Interface} fucntionality package for OpenPower platform.
This class will test the functionality of following commands
bmc, channel, chassis, dcmi, echo, event, exec, firewall, fru, lan mc, pef, power, raw, sdr, sel, sensor, session, user
It is all the same tests as testcases.OpTestInbandIPMI
but using the
USB interface rather than BT.
OpTestIPMILockMode¶
It will test in-band ipmi white-listed commands when ipmi is in locked mode
IPMI whitelist These are the commands that will be available over an unauthenticated interface when the BMC is in IPMI lockdown mode.
Generally one can access all in-band ipmi commands, But if we issue ipmi lock command then one can access only specific whitelisted in-band ipmi commands.
-
class
testcases.OpTestIPMILockMode.
OpTestIPMILockMode
(methodName='runTest')[source]¶ This test case will cover following test steps:
It will get the OS level installed on power platform
It will check for kernel version installed on the Open Power Machine
It will check for ipmitool command existence and ipmitool package
Load the necessary ipmi modules based on config values
Issue a ipmi lock command through out-of-band authenticated interface
Now BMC IPMI is in locked mode, at this point only white listed in-band ipmi commands sholud work(No other in-band ipmi command should work)
Execute and test the functionality of whitelisted in-band ipmi commands in locked mode
At the end of test issue a ipmi unlock command to revert the availablity of all in-band ipmi commands in unlocked mode.
OpTestIPMIReprovision¶
ResetReprovision to default package for OpenPower testing.
This class will test the functionality of following ResetReprovision to default tests.
NVRAM Partition - IPMI Reprovision.
GARD Partition - IPMI Reprovision.
-
class
testcases.OpTestIPMIReprovision.
GARD
(methodName='runTest')[source]¶ This function will cover following test steps
Testcase: GARD Partition-IPMI Reprovision
Inject core checkstop using existed function from OpTestHMIHandling.py
Do a Hard reboot(IPMI Power OFF/ON)
Issue an IPMI PNOR Reprovision request command, to reset GUARD partition to default.
Wait for IPMI PNOR Reprovision progress to complete(00).
Check for GUARD parition whether the existing gard records erased or not.
Reboot the system back to see system is booting fine or not.
-
class
testcases.OpTestIPMIReprovision.
NVRAM
(methodName='runTest')[source]¶ This function will cover following test steps
Testcase: NVRAM Partition-IPMI Reprovision
Update NVRAM config data with test config data i.e nvram –update-config test-name=test-value
Issue an IPMI PNOR Reprovision request command, to reset NVRAM partition to default.
Wait for PNOR Reprovision progress to complete(00).
Do a Hard reboot(Power OFF/ON) to avoid nvram cache data.
Once system booted, check for NVRAM parition whether the test config data got erased or not.
OpTestMtdPnorDriver¶
Test MTD PNOR Driver package for OpenPower testing.
Warning
This has been migrated along with other tests but never used in earnest. It is likely we could accomplish all of this on the host itself. I severely doubt this test case currently works as intended.
-
class
testcases.OpTestMtdPnorDriver.
OpTestMtdPnorDriver
(methodName='runTest')[source]¶ This function has following test steps
Get host information(OS and Kernel information)
Load the mtd module based on config value
Check /dev/mtd0 character device file existence on host
Copying the contents of the flash in a file /tmp/pnor
Getting the /tmp/pnor file into local x86 machine using scp utility
Remove existing /tmp/ffs directory and Clone latest ffs git repository in local x86 working machine
Compile ffs repository to get fcp utility
Check existence of fcp utility in ffs repository, after compiling
Get the PNOR flash contents on an x86 machine using fcp utility
OpTestNVRAM¶
This testcase will deal with testing nvram partition access functions like getting the list of partitions print/update config data in all the supported partitions
-
class
testcases.OpTestNVRAM.
HostNVRAM
(methodName='runTest')[source]¶ This function tests nvram partition access, print/update the config data and dumping the partition’s data. All these operations are done on supported partitions in both host OS and Petitboot.
OpTestOCC¶
OCC Control package for OpenPower testing.
This class will test the functionality of following.
OCC ResetEnableDisable
-
class
testcases.OpTestOCC.
OpTestOCCFull
(methodName='runTest')[source]¶ This function is used to test OCC Reset funtionality in BMC based systems. OCC Reset reload is limited to 3 times per full power cycle.
OpTestOpenCAPI¶
OpenCAPI tests for OpenPower testing.
This class will test the functionality of OpenCAPI
Prerequisites:
Host must have a OpenCAPI FPGA card
OpenCAPI card must have been flashed with memcpy3 AFU
-
class
testcases.OpTestOpenCAPI.
MemCpy3AFUAtomicCasTest
(methodName='runTest')[source]¶ If the system has a OpenCAPI FPGA card, then load the ocxl module if required and test the memcpy3 AFU with ocxl_memcpy -A
-
class
testcases.OpTestOpenCAPI.
MemCpy3AFUIncrementTest
(methodName='runTest')[source]¶ If the system has a OpenCAPI FPGA card, then load the ocxl module if required and test the memcpy3 AFU with ocxl_memcpy -a
-
class
testcases.OpTestOpenCAPI.
MemCpy3AFUIrqTest
(methodName='runTest')[source]¶ If the system has a OpenCAPI FPGA card, then load the ocxl module if required and test the memcpy3 AFU with ocxl_memcpy -i
-
class
testcases.OpTestOpenCAPI.
MemCpy3AFUReallocTest
(methodName='runTest')[source]¶ If the system has a OpenCAPI FPGA card, then load the ocxl module if required and test the memcpy3 AFU with ocxl_memcpy -r
-
class
testcases.OpTestOpenCAPI.
MemCpy3AFUTest
(methodName='runTest')[source]¶ If the system has a OpenCAPI FPGA card, then this test load the ocxl module if required and test the memcpy3 AFU with ocxl_memcpy
OpTestOOBIPMI¶
Test the out-of-band ipmi fucntionality package for OpenPower platform.
This class will test the functionality of following ipmi commands
bmc, channel, chassis, dcmi, echo, event, exec, firewall, fru, lan mc, pef, power, raw, sdr, sel, sensor, session, user
-
class
testcases.OpTestOOBIPMI.
OOBIPMIRuntime
(methodName='runTest')[source]¶
-
class
testcases.OpTestOOBIPMI.
OOBIPMIStandby
(methodName='runTest')[source]¶
-
class
testcases.OpTestOOBIPMI.
OpTestOOBIPMI
(methodName='runTest')[source]¶ -
-
test_bmc_boot_completed_cmd
()[source]¶ This function is used to check whether BMC Completed Booting.
Note
AMI BMC Specific
Note
This same functionality is provided elsewhere in op-test. This code is a candidate for removal.
-
test_bmc_golden_side_version
()[source]¶ This function is used to get the bmc golden image version.
Note
AMI BMC Specific
-
test_channel
()[source]¶ It will check basic channel functionalities: info and authentication capabilities.
-
test_chassis
()[source]¶ It will execute and test the ipmi chassis <cmd> commands cmd: status, poh, restart_cause, policy list and policy set
-
test_chassisBootdev
()[source]¶ It will execute and test the functionality of ipmi chassis bootdev <dev> dev: none,pxe,cdrom,disk,bios,safe,diag,floppy and none.
-
test_fan_control_algorithm_1
()[source]¶ Step 1: Stop Fan Control Thread:
ipmitool ... raw 0x3a 0x12 0x00
Step 2: Fan Control STOPPED OEM SEL created:ipmitool ... sel list |grep OEM 7b | 04/20/2015 | 03:03:14 | OEM record c0 | 000000 | 3a1100ffffff
Step 3: #Run IsFanRunning OEM Command
ipmitool ... raw 0x3a 0x13 00
Note
AMI BMC Specific
-
test_fan_control_algorithm_2
()[source]¶ Step 1: Start Fan Control Thread:
ipmitool -I lanplus -U admin -P admin -H <BMC IP> raw 0x3a 0x12 0x01
Step 2: Fan Control STOPPED OEM SEL created
ipmitool -I lanplus -U admin -P admin -H <BMC IP> sel list |grep OEM 7b | 04/20/2015 | 03:03:14 | OEM record c0 | 000000 | 3a1100ffffff
Step 3: #Run IsFanRunning OEM Command
ipmitool -I lanplus -U admin -P admin -H <BMC IP> raw 0x3a 0x13 01
Note
AMI BMC Specific
-
test_get_led_state_cmd
()[source]¶ This command is used to get the State of below Supported LED.
LED Number Table:
Fault RollUP LED
0x00
Power ON LED
0x01
Host Status LED
0x02
Chassis Identify LED
0x03
Note
AMI BMC Specific
-
test_get_pnor_partition_size_cmd
()[source]¶ This function is used to get partition size of given PNOR Partition. Currently added NVRAM,GUARD and BOOTKERNEL partitions. TODO: Add all the necessary partitions to get the size.
Note
AMI BMC specific.
-
test_oem_specific
()[source]¶ It will execute and test all Out-of-band ipmi commands. bmc, channel, chassis, dcmi, echo, event, exec, firewall, fru, lan mc, pef, power, raw, sdr, sel, sensor, session, user
FIXME: this may not be AMI specific.
-
test_pef
()[source]¶ It will execute and test pef related commands:
- info
This command will query the BMC and print information about the PEF supported features.
- status
This command prints the current PEF status
- policy
This command lists the PEF policy table entries
- list
This command lists the PEF table entries.
-
test_raw
()[source]¶ This will test raw IPMI commands. For example to query the POH counter with a raw command
-
test_read_pnor_partition_data
()[source]¶ This function is used to test reading of pnor partition data via ipmitool command. Here it will currently read NVRAM and FIRDATA partition’s data of size 254 bytes.
Note
AMI BMC Specific.
-
test_sel_list_first_3_entries
()[source]¶ It will execute and test the ipmi sel list first <3 entries>
-
test_sensor_get_host_status
()[source]¶ It will execute and test the ipmi sensor get “Host Status” functionality
Note
AMI BMC Specific.
-
test_sensor_get_os_boot
()[source]¶ It will execute and test the ipmi sensor get “OS Boot” functionality
Note
AMI BMC Specific.
-
test_set_led_state_cmd
()[source]¶ This function is used to test set LED state feature.
LED Number Table:
Fault RollUP LED
0x00
Power ON LED
0x01
Host Status LED
0x02
Chassis Identify LED
0x03
LED State Table:
0x0
LED OFF
0x1
LED ON
0x2
LED Standby Blink Rate
0x3
LED Slow Blink rate.
Note
AMI BMC Specific
-
OpTestPCI: PCI checks¶
Perform various PCI validations and checks
–run-suite BasicPCI (includes skiroot_suite and host_suite) –run-suite pci-regression
Sample naming conventions below, see each test method for the applicable options per method.
- –run testcases.OpTestPCI.PCISkiroot.pcie_link_errors
- ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^^^^^^^
module name subclass test method
- –run testcases.OpTestPCI.PCIHost.pcie_link_errors
- ^^^^^^^^^^^^^^^^^^^ ^^^^^^^ ^^^^^^^^^^^^^^^^
module name subclass test method
-
class
testcases.OpTestPCI.
OpClassPCI
(methodName='runTest')[source]¶ Main Parent class
We cannot guarantee a soft boot entry, so need to force to PS or OS
-
check_commands
()[source]¶ Checks for general capability to run commands
Case A –run testcases.OpTestPCI.PCISkiroot.check_commands Case B –run testcases.OpTestPCI.PCISkirootSoftboot.check_commands Case C –run testcases.OpTestPCI.PCISkirootHardboot.check_commands Case D –run testcases.OpTestPCI.PCIHost.check_commands Case E –run testcases.OpTestPCI.PCIHostSoftboot.check_commands Case F –run testcases.OpTestPCI.PCIHostHardboot.check_commands
-
compare_boot_devices
()[source]¶ This is best leveraged in the suite pci-regression, where both the skiroot/host softboot and the skiroot/host hardboot get done in the same wave, so that the global variables carry over to compare.
If both skiroot and host lspci completed, will compare lspci results.
If you want to compare against an input file, use compare_live_devices.
Case A –run testcases.OpTestPCI.PCISkiroot.compare_boot_devices Case B –run testcases.OpTestPCI.PCISkirootSoftboot.compare_boot_devices Case C –run testcases.OpTestPCI.PCISkirootHardboot.compare_boot_devices Case D –run testcases.OpTestPCI.PCIHost.compare_boot_devices Case E –run testcases.OpTestPCI.PCIHostSoftboot.compare_boot_devices Case F –run testcases.OpTestPCI.PCIHostHardboot.compare_boot_devices
-
compare_live_devices
()[source]¶ Compares the live system lspci against an input file, host-lspci provided either in conf file or via command line.
“ssh user@host lspci -mm -n > host-lspci.txt”
- –host-lspci host-lspci.txt on command line
or
host_lspci=host-lspci.txt in conf file
Case A –run testcases.OpTestPCI.PCISkiroot.compare_live_devices Case B –run testcases.OpTestPCI.PCISkirootSoftboot.compare_live_devices Case C –run testcases.OpTestPCI.PCISkirootHardboot.compare_live_devices Case D –run testcases.OpTestPCI.PCIHost.compare_live_devices Case E –run testcases.OpTestPCI.PCIHostSoftboot.compare_live_devices Case F –run testcases.OpTestPCI.PCIHostHardboot.compare_live_devices
-
driver_bind
()[source]¶ Unbind and then bind the devices
Case A –run testcases.OpTestPCI.PCISkiroot.driver_bind Case B –run testcases.OpTestPCI.PCISkirootSoftboot.driver_bind Case C –run testcases.OpTestPCI.PCISkirootHardboot.driver_bind Case D –run testcases.OpTestPCI.PCIHost.driver_bind Case E –run testcases.OpTestPCI.PCIHostSoftboot.driver_bind Case F –run testcases.OpTestPCI.PCIHostHardboot.driver_bind
Special note on unbinding shared bmc ethernet ports, caution.
-
get_lspci
()[source]¶ Usually used internally, can be run for query of system
Case A –run testcases.OpTestPCI.PCISkiroot.get_lspci Case B –run testcases.OpTestPCI.PCISkirootSoftboot.get_lspci Case C –run testcases.OpTestPCI.PCISkirootHardboot.get_lspci Case D –run testcases.OpTestPCI.PCIHost.get_lspci Case E –run testcases.OpTestPCI.PCIHostSoftboot.get_lspci Case F –run testcases.OpTestPCI.PCIHostHardboot.get_lspci
-
get_lspci_file
()[source]¶ Usually used internally, can be run for query of system
Case A –run testcases.OpTestPCI.PCISkiroot.get_lspci_file Case B –run testcases.OpTestPCI.PCISkirootSoftboot.get_lspci_file Case C –run testcases.OpTestPCI.PCISkirootHardboot.get_lspci_file Case D –run testcases.OpTestPCI.PCIHost.get_lspci_file Case E –run testcases.OpTestPCI.PCIHostSoftboot.get_lspci_file Case F –run testcases.OpTestPCI.PCIHostHardboot.get_lspci_file
-
hot_plug_host
()[source]¶ NEEDS TESTING Case A –run testcases.OpTestPCI.PCIHost.hot_plug_host Case B –run testcases.OpTestPCI.PCIHostSoftboot.hot_plug_host Case C –run testcases.OpTestPCI.PCIHostHardboot.hot_plug_host
-
pci_link_check
()[source]¶ PCI link checks
Case A –run testcases.OpTestPCI.PCISkiroot.pci_link_check Case B –run testcases.OpTestPCI.PCISkirootSoftboot.pci_link_check Case C –run testcases.OpTestPCI.PCISkirootHardboot.pci_link_check Case D –run testcases.OpTestPCI.PCIHost.pci_link_check Case E –run testcases.OpTestPCI.PCIHostSoftboot.pci_link_check Case F –run testcases.OpTestPCI.PCIHostHardboot.pci_link_check
-
pcie_link_errors
()[source]¶ Checks for link errors
Case A –run testcases.OpTestPCI.PCISkiroot.pcie_link_errors Case B –run testcases.OpTestPCI.PCISkirootSoftboot.pcie_link_errors Case C –run testcases.OpTestPCI.PCISkirootHardboot.pcie_link_errors Case D –run testcases.OpTestPCI.PCIHost.pcie_link_errors Case E –run testcases.OpTestPCI.PCIHostSoftboot.pcie_link_errors Case F –run testcases.OpTestPCI.PCIHostHardboot.pcie_link_errors
-
classmethod
refresh_console
()[source]¶ This method is used to set the shared class console back to the proper object (this gets set to the real console when we unbind the ethernet) in the driver_bind test as an example.
-
setUp
()[source]¶ All variables common to a subclass need to be defined here since this method gets called before each subclass test
-
classmethod
setUpClass
(desired=None, power_cycle=0)[source]¶ Main setUpClass, this is shared across all subclasses. This is called once when the subclass is instantiated.
-
-
class
testcases.OpTestPCI.
PCIHost
(methodName='runTest')[source]¶ Class allows to run parent classes with unique setup
-
class
testcases.OpTestPCI.
PCIHostHardboot
(methodName='runTest')[source]¶ Class allows to run parent classes with unique setup
-
setUp
()[source]¶ All variables common to a subclass need to be defined here since this method gets called before each subclass test
-
-
class
testcases.OpTestPCI.
PCIHostSoftboot
(methodName='runTest')[source]¶ Class allows to run parent classes with unique setup
-
setUp
()[source]¶ All variables common to a subclass need to be defined here since this method gets called before each subclass test
-
-
class
testcases.OpTestPCI.
PCISkiroot
(methodName='runTest')[source]¶ Class allows to run parent classes with unique setup
-
class
testcases.OpTestPCI.
PCISkirootHardboot
(methodName='runTest')[source]¶ Class allows to run parent classes with unique setup
-
setUp
()[source]¶ All variables common to a subclass need to be defined here since this method gets called before each subclass test
-
-
class
testcases.OpTestPCI.
PCISkirootSoftboot
(methodName='runTest')[source]¶ Class allows to run parent classes with unique setup
-
setUp
()[source]¶ All variables common to a subclass need to be defined here since this method gets called before each subclass test
-
-
testcases.OpTestPCI.
host_full_suite
()[source]¶ Function used to prepare a test suite (see op-test) –run testcases.OpTestPCI.host_full_suite
This suite does not care on soft vs hard boot
-
testcases.OpTestPCI.
host_hardboot_suite
()[source]¶ Function used to prepare a test suite (see op-test) –run-suite pci-regression –run testcases.OpTestPCI.host_hardboot_suite
-
testcases.OpTestPCI.
host_softboot_suite
()[source]¶ Function used to prepare a test suite (see op-test) –run-suite pci-regression –run testcases.OpTestPCI.host_softboot_suite
-
testcases.OpTestPCI.
host_suite
()[source]¶ Function used to prepare a test suite (see op-test) –run-suite BasicPCI –run testcases.OpTestPCI.host_suite
This suite does not care on soft vs hard boot
-
testcases.OpTestPCI.
skiroot_full_suite
()[source]¶ Function used to prepare a test suite (see op-test) –run testcases.OpTestPCI.skiroot_full_suite
This suite does not care on soft vs hard boot
-
testcases.OpTestPCI.
skiroot_hardboot_suite
()[source]¶ Function used to prepare a test suite (see op-test) –run-suite pci-regression –run testcases.OpTestPCI.skiroot_hardboot_suite
OpTestPNOR¶
This testcase will deal with testing access to the host pnor from petitboot through the pflash program
OpTestPrdDaemon¶
PRD daemon for OpenPower testing.
This class will test the functionality of following.
PRD (Processor Runtime Diagnostic) daemon should always be running in HOST OS.
For testing out this feature, we require to kill the opal-prd daemon and make sure that the daemon spawns back always.
-
class
testcases.OpTestPrdDaemon.
OpTestPrdDaemon
(methodName='runTest')[source]¶ This function performs below steps
Initially connecting to host console for execution.
Check for whether opal-prd daemon is running or not if it is, get the PID of the opal-prd daemon
Kill the opal-prd daemon using its PID
Again check if opal-prd daemon spawns back
OpTestPrdDriver¶
PRD driver package for OpenPower testing.
This class will test the functionality of following:
PRD (Processor Runtime Diagnostic) enables the support for handing certain RAS events by the userspace application.
For testing out this feature, we require the userspace xscom-utils, part of the ‘skiboot’ tree.
skiboot tree is cloning in /tmp directory.
Using the xscom utility, we need to inject errors through FIR (Fault Isolation Register) and observe them getting cleared if PRD handles them successfully.
0x01020013 IPOLL mask register
0x02010840 PBA Local Fault isolation register
0x02010843 PBA Local fault isolation mask register
-
class
testcases.OpTestPrdDriver.
OpTestPrdDriver
(methodName='runTest')[source]¶ -
prd_init
()[source]¶ This is a common function for all the PRD test cases. This will be executed before any test case starts. Basically this provides below requirements.
Validates all required host commands
Get the list Of Chips (Using getscom binary). e.g.
['00000000', '00000001', '00000010']
generate a random chip.
-
prd_test_core_fir
(FIR, FIMR, ERROR)[source]¶ This function injects some core FIR errors and verifies whether opal-prd clears the errors. and also this function injects errors on random chip.
-
runTest
()[source]¶ This function performs below steps:
Initially connecting to host for execution.
check for IPOLL mask register value to see whether opal-prd is running or not if it is 0–>opal-prd is running–>continue else start opal-prd service again
call test_prd_for_fir() function for each core FIR error and this function can be used for any number of errors, like it is a generic function
-
OpTestRebootTimeout¶
Test it doesn’t take until the heat death of the universe to reboot.
OpTestRTCdriver¶
RTC (Real Time Clock) package for OpenPower testing.
This class will test the functionality of following drivers
RTC driver: Real time clock
-
class
testcases.OpTestRTCdriver.
FullRTC
(methodName='runTest')[source]¶ -
RunFullRTC
()[source]¶ This function will cover following test steps
Getting host information(OS and Kernel info)
Loading rtc_opal module based on config option
Testing the rtc driver functions:
Display the current time,
set the Hardware Clock to a specified time,
set the Hardware Clock from the System Time, or
set the System Time from the Hardware Clock
keep the Hardware clock in UTC or local time format
Hardware clock compare, predict and adjust functions
Hardware clock debug and test modes
Reading the Hardware clock from special file instead of default
After executing above each function reading the Hardware clock in b/w functions.
-
hwclock_debug_mode
()[source]¶ This function tests hwclock debug mode. In this mode setting hwclock from system time and setting system time from hwclock
-
hwclock_predict
(i_time)[source]¶ This function predict RTC reading at time given with –date
- Parameters
i_time – time at which predict hwclock reading
-
hwclock_test_mode
(i_time)[source]¶ This function tests the hwclock test mode. In this mode setting the hwclock time using
--set
option. Here it just execute but should not set hwclock time.- Parameters
i_time (str) – time to set hwclock in test mode
-
read_hwclock_from_file
(i_file)[source]¶ This function reads hwclock from special /dev/… file instead of default
-
classmethod
setUpClass
()[source]¶ Hook method for setting up class fixture before running tests in the class.
-
set_hwclock_in_localtime
(i_time)[source]¶ This function sets hwclock in local time format
- Parameters
i_time – Time to set hwclock
-
set_hwclock_in_utc
(i_time)[source]¶ This function sets hwclock in UTC format
- Parameters
i_time (str) – time to set hwclock e.g. “2016-01-01 12:12:12”
-
OpTestSensors¶
Sensors package for OpenPower testing.
This class will test the functionality of following drivers
Hardware monitoring sensors(hwmon driver) using sensors utility
-
class
testcases.OpTestSensors.
OpTestSensors
(methodName='runTest')[source]¶ This test will cover following test steps:
It will check for kernel config option CONFIG_SENSORS_IBMPOWERNV
It will load ibmpowernv driver only on powernv platform
It will check for sensors command existence and lm_sensors package
start the lm_sensors service and detect any sensor chips using sensors-detect.
At the end it will test sensors command functionality with different options
OpTestSwitchEndianSyscall¶
Switch endian system call package for OpenPower testing.
This class will test the functionality of following.
It will test switch_endian() system call by executing the registers changes in other endian. By calling switch_endian sys call, should not effect register and memory space.
This functionality is implemented in linux git repository /linux/tools/testing/selftests/powerpc/switch_endian
In this test, will clone latest linux git repository and make required files. At the end will execute switch_endian_test executable file.
-
class
testcases.OpTestSwitchEndianSyscall.
OpTestSwitchEndianSyscall
(methodName='runTest')[source]¶ If git and gcc commands are availble on host, this function will clone linux git repository and check for switch_endian_test directory and make the required files. And finally execute bin file switch_endian_test.
-
check_dir_exists
(i_dir)[source]¶ It will check for existence of switch_endian directory in the cloned repository
- Parameters
i_dir – linux source directory
-
make_test
(i_dir)[source]¶ It will prepare for executable bin files using make command At the end it will check for bin file switch_endian_test and will throw an exception in case of missing bin file after make
- Parameters
i_dir – linux source directory
-
OpTestSystemBootSequence¶
It will test below system boot sequence operations
Mc cold reset boot sequence.
Power off state (and auto reboot policy should be off)
Make sure BMC is pinging
Issue Cold reset to BMC => ipmitool <…> mc reset cold
Ensure BMC stops pinging, wait until BMC fully boots
Open network sol console => ipmitool <…> sol activate
Power on system => ipmitool <…> chassis power on
Make sure boots to Host OS, SOL fine
Mc warm reset boot sequence
Power off state (and auto reboot policy should be off)
Make sure BMC is pinging
Issue warm reset to BMC => ipmitool <…> mc reset warm
Ensure BMC stops pinging, wait until BMC fully boots
Open network sol console => ipmitool <…> sol activate
Power on system => ipmitool <…> chassis power on
Make sure boots to Host OS, SOL fine
-
class
testcases.OpTestSystemBootSequence.
ColdReset_IPL
(methodName='runTest')[source]¶ This function will test mc cold reset boot sequence, It has below steps
Do a system Power OFF(Host should go down)
Set auto reboot policy to off(chassis policy always-off)
Issue a BMC Cold reset.
After BMC comes up, Issue a Power ON of the system
Check for system status and gather OPAL msg log.
-
class
testcases.OpTestSystemBootSequence.
PowerPolicyOFF_IPL
(methodName='runTest')[source]¶ This function will test system auto reboot policy always-off. It has below steps
Do a system Power OFF(Host should go down)
Set auto reboot policy to off(chassis policy always-off)
Issue a BMC Cold reset.
After BMC comes up, expect the system to not boot.
Issue a Power ON of the system
Check for system status and gather OPAL msg log.
-
class
testcases.OpTestSystemBootSequence.
PowerPolicyON_IPL
(methodName='runTest')[source]¶ This function will test system auto reboot policy always-on. It has below steps
Do a system Power OFF(Host should go down)
Set auto reboot policy to on(chassis policy always-on)
Issue a BMC Cold reset.
After BMC comes up, Here expect the system to boot, If not power policy is not working as expected
Check for system status and gather OPAL msg log.
-
class
testcases.OpTestSystemBootSequence.
PowerPolicyPrevious_IPL
(methodName='runTest')[source]¶ This function will test system auto reboot policy previous It has below steps
Do a system Power OFF(Host should go down)
Set auto reboot policy to previous(chassis policy previous)
Issue a BMC Cold reset.
After BMC comes up, system power status will change based on previous power status before issuing cold reset.
Check for system status and gather OPAL msg log.
-
class
testcases.OpTestSystemBootSequence.
WarmReset_IPL
(methodName='runTest')[source]¶ This function will test mc warm reset boot sequence, It has below steps
Do a system Power OFF(Host should go down)
Set auto reboot policy to off(chassis policy always-off)
Issue a BMC Warm reset.
After BMC comes up, Issue a Power ON of the system
Check for system status and gather OPAL msg log.
PCI Slot/Location Codes¶
This test will use the device tree to determine if the pciex is a root/switch fabric with one or more switch devices.
Slot labels and loc codes are retrieved and if missing or empty the test will identify for investigation. Not all test results reporting missing or empty slot labels or loc codes are problems, it is the system owner to make that determination.
-
class
testcases.PciSlotLocCodes.
HostDT
(methodName='runTest')[source]¶ HostDT Class performs PCI DT checks in the Host OS –run testcases.PciSlotLocCodes.HostDT
-
class
testcases.PciSlotLocCodes.
PciDT
(methodName='runTest')[source]¶ PciDT Class –run testcases.PciSlotLocCodes
Petitboot Dropbear Server¶
Test Dropbear SSH Serevr is not present in skiroot
The skiroot (pettiboot environment) firmware contains dropbear for it’s ssh client functioanlity. We do not want to enable network accessable system in the environemnt for security reasons.
This test ensures that the ssh server is not running at boot
Petitboot Internationalization (i8n)¶
Test that Petitboot can correctly display languages other than English.
RunHostTest¶
Runs a bunch of commands from a file on the op-test running system on the host.
SbePassThrough¶
Test case for SBE passthrough
Secureboot IPL Tests¶
-
class
testcases.SecureBoot.
KeyTransitionPNOR
(methodName='runTest')[source]¶ Secure boot key transition test: Ensure successful key transition in SEEPROM Types of Key Transition PNOR images:
dev to dev
dev to prod
prod to dev
prod to prod
-
class
testcases.SecureBoot.
OPALContainerTest
(methodName='runTest')[source]¶ System having Signed PNOR(either production or developement mode) Flash signed containers with wrong keys Secureboot verify should fail and boot should abort
-
class
testcases.SecureBoot.
SignedPNOR
(methodName='runTest')[source]¶ Secure boot IPL test: Ensure successful boot with properly signed PNOR.
SB Mode
sign mode
Boot result
ON
Signed
Pass
OFF
Signed
Pass
-
class
testcases.SecureBoot.
SignedToPNOR
(methodName='runTest')[source]¶ Secure boot IPL test: Ensure successful boot with properly signed to PNOR(To match the keys which are got replaced after KeyTransitionPNOR flash test).
SB Mode
sign mode
Boot result
ON
Signed
Pass
OFF
Signed
Pass
System Login¶
Really simple tests to ensure we can simply log into a booted host.
-
class
testcases.SystemLogin.
BMCLogin
(methodName='runTest')[source]¶ Log into the BMC via SSH and run different commands
Test OpenBMC REST API¶
Tests a bunch of functionality only available through OpenBMC REST API
Generally takes about 10 minutes to run rest-api suite
Note
The OpenBMC REST API is not a long term nor stable API. It’s just as likely that OpenBMC changes their API as anything.
-
class
testcases.testRestAPI.
HostBounces
(methodName='runTest')[source]¶ Performs Reboots and Power On/Off variety Purpose is to exercise the REST API’s –run testcases.testRestAPI.HostBounces
-
classmethod
setUpClass
()[source]¶ Hook method for setting up class fixture before running tests in the class.
-
test_hard_reboot
()[source]¶ REST Hard Reboot –run testcases.testRestAPI.HostBounces.test_hard_reboot
-
classmethod
-
class
testcases.testRestAPI.
HostOff
(methodName='runTest')[source]¶ Runtime Class performs tests with Host On HostOff Class will turn the Host Off –run testcases.testRestAPI.Runtime –run testcases.testRestAPI.HostOff
-
class
testcases.testRestAPI.
RestAPI
(methodName='runTest')[source]¶ RestAPI Class - Execution order independent –run-suite rest-api –run testcases.testRestAPI.Runtime –run testcases.testRestAPI.HostOff or run the individual tests
-
class
testcases.testRestAPI.
Runtime
(methodName='runTest')[source]¶ Runtime Class performs tests with Host On HostOff Class will turn the Host Off –run testcases.testRestAPI.Runtime –run testcases.testRestAPI.HostOff
-
classmethod
setUpClass
()[source]¶ Hook method for setting up class fixture before running tests in the class.
-
test_clear_gard_record
()[source]¶ REST Clear ALL Gard Records –run testcases.testRestAPI.Runtime.test_clear_gard_record –run testcases.testRestAPI.HostOff.test_clear_gard_record
-
test_clear_sel
()[source]¶ REST Clear SELs –run testcases.testRestAPI.Runtime.test_clear_sel –run testcases.testRestAPI.HostOff.test_clear_sel
-
test_dump_sels
()[source]¶ REST Dump SELs –run testcases.testRestAPI.Runtime.test_dump_sels –run testcases.testRestAPI.HostOff.test_dump_sels
-
test_factory_reset_network
()[source]¶ REST Factory Reset Network USE AT YOUR OWN RISK –run testcases.testRestAPI.Runtime.test_factory_reset_network –run testcases.testRestAPI.HostOff.test_factory_reset_network
-
test_factory_reset_software
()[source]¶ REST Factory Reset Software USE AT YOUR OWN RISK –run testcases.testRestAPI.Runtime.test_factory_reset_software –run testcases.testRestAPI.HostOff.test_factory_reset_software
-
test_field_mode_enable_disable
()[source]¶ REST Field Mode Enable and Disable –run testcases.testRestAPI.Runtime.test_field_mode_enable_disable –run testcases.testRestAPI.HostOff.test_field_mode_enable_disable
-
test_get_boot_progress
()[source]¶ REST Get Boot Progress –run testcases.testRestAPI.Runtime.test_get_boot_progress –run testcases.testRestAPI.HostOff.test_get_boot_progress
-
test_image_lists
()[source]¶ REST Image Interfaces –run testcases.testRestAPI.Runtime.test_image_lists –run testcases.testRestAPI.HostOff.test_image_lists
-
test_inventory
()[source]¶ REST Get Inventory –run testcases.testRestAPI.Runtime.test_inventory –run testcases.testRestAPI.HostOff.test_inventory
-
test_list_sel
()[source]¶ REST List SELs –run testcases.testRestAPI.Runtime.test_list_sel –run testcases.testRestAPI.HostOff.test_list_sel
-
test_obmc_create_dump
()[source]¶ REST OBMC Create Dump –run testcases.testRestAPI.Runtime.test_obmc_create_dump –run testcases.testRestAPI.HostOff.test_obmc_create_dump
-
test_obmc_delete_dumps
()[source]¶ REST OBMC Delete ALL Dumps –run testcases.testRestAPI.Runtime.test_obmc_delete_dumps –run testcases.testRestAPI.HostOff.test_obmc_delete_dumps
-
test_obmc_download_dumps
()[source]¶ REST OBMC Download ALL Dumps –run testcases.testRestAPI.Runtime.test_obmc_download_dumps –run testcases.testRestAPI.HostOff.test_obmc_download_dumps
-
test_obmc_dump
()[source]¶ REST OBMC List, Create and Download a Dump –run testcases.testRestAPI.Runtime.test_obmc_dump –run testcases.testRestAPI.HostOff.test_obmc_dump
-
test_obmc_states
()[source]¶ REST OBMC States –run testcases.testRestAPI.Runtime.test_obmc_states –run testcases.testRestAPI.HostOff.test_obmc_states
-
test_occ_active
()[source]¶ REST OCC Active –run testcases.testRestAPI.Runtime.test_occ_active –run testcases.testRestAPI.HostOff.test_occ_active
-
test_sensors
()[source]¶ REST Sensors –run testcases.testRestAPI.Runtime.test_sensors –run testcases.testRestAPI.HostOff.test_sensors
-
test_set_bootdevs
()[source]¶ REST Set Boot Device to Setup then Regular, this leaves the boot device as we found it –run testcases.testRestAPI.Runtime.test_set_bootdevs –run testcases.testRestAPI.HostOff.test_set_bootdevs
-
test_software_enumerate
()[source]¶ REST Software Enumerate –run testcases.testRestAPI.Runtime.test_software_enumerate –run testcases.testRestAPI.HostOff.test_software_enumerate
-
test_system_power_cap
()[source]¶ REST System Power Cap –run testcases.testRestAPI.Runtime.test_system_power_cap –run testcases.testRestAPI.HostOff.test_system_power_cap
-
test_tpm_policy_setting
()[source]¶ REST TPM Policy Settings –run testcases.testRestAPI.Runtime.test_tpm_policy_setting –run testcases.testRestAPI.HostOff.test_tpm_policy_setting
-
test_update_root_password
()[source]¶ REST Update Root Password Caution if OpTestConfiguration bmc_password is modified util_bmc_server does automatic login with stored credentials –run testcases.testRestAPI.Runtime.test_update_root_password –run testcases.testRestAPI.HostOff.test_update_root_password
-
classmethod
Trustedboot IPL Tests¶
This tests expect a TPM chip to be installed/removed on the system and also a secureboot mode enabled/disabled accordingly.
If TPM chip is installed –> provide –trusted-mode in command line If secureboot is enabled –> provide –secure-mode in command line
The “TPM Required” policy means:
- enabled:
Node must have at least 1 functional TPM to boot, otherwise system will terminate
- disabled:
Node can boot without a functional TPM
If system has a working TPM, the policy is a don’t care. If secure mode is not enabled, the policy is a don’t care. if you set policy to “enabled” and remove/inject error on TPM -and- system is in secure mode, system boot will terminate if you set policy to disable and remove/inject error on the TPM -and- system is in secure mode, system will still boot
-
class
testcases.TrustedBoot.
FunctionalTPM_PolicyOFF
(methodName='runTest')[source]¶ - Functional TPM, TPM Required(cleared)
Test IPL, Measurements & event logs(Secure Mode Override jumper(s) ON or OFF)
-
class
testcases.TrustedBoot.
FunctionalTPM_PolicyON
(methodName='runTest')[source]¶ - Functional TPM, TPM Required(set)
Test IPL, Measurements & event logs(Secure Mode Override jumper(s) can be ON or OFF)
-
class
testcases.TrustedBoot.
NoFunctionalTPM_PolicyOFF
(methodName='runTest')[source]¶ - No Functional TPM, TPM Required(cleared)
Test IPL, Measurements & event logs(Secure Mode Override jumper(s) can be ON or OFF)
-
class
testcases.TrustedBoot.
NoFunctionalTPM_PolicyON
(methodName='runTest')[source]¶ - No Functional TPM, TPM Required(set)
Test IPL, Measurements & event logs(Secure Mode Override jumper(s) can be ON or OFF)