Login

About

The Linutronix Test Environment (CI) automatically tests changes of the
PREEMPT_RT patch on different hardware platforms with a defined test
procedure. Following is a description of the defined test procedure and
the hardware infrastructure.

Test Procedure

The test environment monitors the branches of the two git repositories
hosting the PREEMPT_RT patches with the corresponding Linux mainline
kernel. A new commit in a single branch triggers a test run for this
branch. In a single test run, a defined set of kernel configurations are
tested. The test procedure for a kernel configuration goes through up to
three phases, depending on the specification:

Build test: The kernel configuration (with a defined overlay, such
as debug overlay) is compiled on a build server with the source of the
updated branch. There is no need for an assigned target for every kernel
configuration of this phase.

Boot test: The built kernel and device tree are booted on the
specified target. For this, kexec is used. This test is successful only
if there is no warning output during boot.

Cyclictest: After a successful boot, the latency measurement tool
cyclictest is used to detect system latency under a defined load. If the
latency exceeds a defined threshold, cyclictest aborts and this test
phase fails.

The state of the entire test run is a combination of all interim test
phase results.

Infrastructure

The figure shows the structure of the CI-RT
infrastructure. There is a single control instance, the Jenkins master,
monitoring the branches of the PREEMPT_RT git repository. This instance
starts the three different test phases on the Jenkins slaves. The first
test phase is processed on the Jenkins slave "build server". The second
and third test phases are processed on the test targets, which are also
registered Jenkins slaves. The test targets are located in a test
rack. This rack is similar to those in the well
known OSADL QA farm. For abstract communication with the targets
a tool called r4d (Remote For Dut) is used. In order to use a
generic API, libvirt was adapted to communicate with r4d. The test
results are stored in the database of the web interface. The web interface
displays the test results. For setting up the infrastructure, please
visit CI-RT github
project.

The standardized elbe based root file systems for the test targets can be
downloaded
here.
The test targets need to fulfil several requirements to be placed into the
test rack
(see "System
Requirements" for more details).