|
@@ -293,6 +293,38 @@
|
|
|
# or on some systems:
|
|
|
#POST_INSTALL = ssh user@target /sbin/dracut -f /boot/initramfs-test.img $KERNEL_VERSION
|
|
|
|
|
|
+# If there is a script that you require to run before the build is done
|
|
|
+# you can specify it with PRE_BUILD.
|
|
|
+#
|
|
|
+# One example may be if you must add a temporary patch to the build to
|
|
|
+# fix a unrelated bug to perform a patchcheck test. This will apply the
|
|
|
+# patch before each build that is made. Use the POST_BUILD to do a git reset --hard
|
|
|
+# to remove the patch.
|
|
|
+#
|
|
|
+# (default undef)
|
|
|
+#PRE_BUILD = cd ${BUILD_DIR} && patch -p1 < /tmp/temp.patch
|
|
|
+
|
|
|
+# To specify if the test should fail if the PRE_BUILD fails,
|
|
|
+# PRE_BUILD_DIE needs to be set to 1. Otherwise the PRE_BUILD
|
|
|
+# result is ignored.
|
|
|
+# (default 0)
|
|
|
+# PRE_BUILD_DIE = 1
|
|
|
+
|
|
|
+# If there is a script that should run after the build is done
|
|
|
+# you can specify it with POST_BUILD.
|
|
|
+#
|
|
|
+# As the example in PRE_BUILD, POST_BUILD can be used to reset modifications
|
|
|
+# made by the PRE_BUILD.
|
|
|
+#
|
|
|
+# (default undef)
|
|
|
+#POST_BUILD = cd ${BUILD_DIR} && git reset --hard
|
|
|
+
|
|
|
+# To specify if the test should fail if the POST_BUILD fails,
|
|
|
+# POST_BUILD_DIE needs to be set to 1. Otherwise the POST_BUILD
|
|
|
+# result is ignored.
|
|
|
+# (default 0)
|
|
|
+#POST_BUILD_DIE = 1
|
|
|
+
|
|
|
# Way to reboot the box to the test kernel.
|
|
|
# Only valid options so far are "grub" and "script"
|
|
|
# (default grub)
|
|
@@ -360,8 +392,8 @@
|
|
|
#ADD_CONFIG = /home/test/config-broken
|
|
|
|
|
|
# The location on the host where to write temp files
|
|
|
-# (default /tmp/ktest)
|
|
|
-#TMP_DIR = /tmp/ktest
|
|
|
+# (default /tmp/ktest/${MACHINE})
|
|
|
+#TMP_DIR = /tmp/ktest/${MACHINE}
|
|
|
|
|
|
# Optional log file to write the status (recommended)
|
|
|
# Note, this is a DEFAULT section only option.
|
|
@@ -518,6 +550,16 @@
|
|
|
# The variables SSH_USER and MACHINE are defined.
|
|
|
#REBOOT = ssh $SSH_USER@$MACHINE reboot
|
|
|
|
|
|
+# The way triple faults are detected is by testing the kernel
|
|
|
+# banner. If the kernel banner for the kernel we are testing is
|
|
|
+# found, and then later a kernel banner for another kernel version
|
|
|
+# is found, it is considered that we encountered a triple fault,
|
|
|
+# and there is no panic or callback, but simply a reboot.
|
|
|
+# To disable this (because it did a false positive) set the following
|
|
|
+# to 0.
|
|
|
+# (default 1)
|
|
|
+#DETECT_TRIPLE_FAULT = 0
|
|
|
+
|
|
|
#### Per test run options ####
|
|
|
# The following options are only allowed in TEST_START sections.
|
|
|
# They are ignored in the DEFAULTS sections.
|
|
@@ -535,6 +577,12 @@
|
|
|
# all preceding tests until a new CHECKOUT is set.
|
|
|
#
|
|
|
#
|
|
|
+# TEST_NAME = name
|
|
|
+#
|
|
|
+# If you want the test to have a name that is displayed in
|
|
|
+# the test result banner at the end of the test, then use this
|
|
|
+# option. This is useful to search for the RESULT keyword and
|
|
|
+# not have to translate a test number to a test in the config.
|
|
|
#
|
|
|
# For TEST_TYPE = patchcheck
|
|
|
#
|
|
@@ -556,7 +604,12 @@
|
|
|
# build, boot, test.
|
|
|
#
|
|
|
# Note, the build test will look for warnings, if a warning occurred
|
|
|
-# in a file that a commit touches, the build will fail.
|
|
|
+# in a file that a commit touches, the build will fail, unless
|
|
|
+# IGNORE_WARNINGS is set for the given commit's sha1
|
|
|
+#
|
|
|
+# IGNORE_WARNINGS can be used to disable the failure of patchcheck
|
|
|
+# on a particuler commit (SHA1). You can add more than one commit
|
|
|
+# by adding a list of SHA1s that are space delimited.
|
|
|
#
|
|
|
# If BUILD_NOCLEAN is set, then make mrproper will not be run on
|
|
|
# any of the builds, just like all other TEST_TYPE tests. But
|
|
@@ -571,6 +624,7 @@
|
|
|
# PATCHCHECK_TYPE = boot
|
|
|
# PATCHCHECK_START = 747e94ae3d1b4c9bf5380e569f614eb9040b79e7
|
|
|
# PATCHCHECK_END = HEAD~2
|
|
|
+# IGNORE_WARNINGS = 42f9c6b69b54946ffc0515f57d01dc7f5c0e4712 0c17ca2c7187f431d8ffc79e81addc730f33d128
|
|
|
#
|
|
|
#
|
|
|
#
|
|
@@ -739,13 +793,18 @@
|
|
|
# boot - bad builds but fails to boot
|
|
|
# test - bad boots but fails a test
|
|
|
#
|
|
|
-# CONFIG_BISECT is the config that failed to boot
|
|
|
+# CONFIG_BISECT is the config that failed to boot
|
|
|
#
|
|
|
-# If BISECT_MANUAL is set, it will pause between iterations.
|
|
|
-# This is useful to use just ktest.pl just for the config bisect.
|
|
|
-# If you set it to build, it will run the bisect and you can
|
|
|
-# control what happens in between iterations. It will ask you if
|
|
|
-# the test succeeded or not and continue the config bisect.
|
|
|
+# If BISECT_MANUAL is set, it will pause between iterations.
|
|
|
+# This is useful to use just ktest.pl just for the config bisect.
|
|
|
+# If you set it to build, it will run the bisect and you can
|
|
|
+# control what happens in between iterations. It will ask you if
|
|
|
+# the test succeeded or not and continue the config bisect.
|
|
|
+#
|
|
|
+# CONFIG_BISECT_GOOD (optional)
|
|
|
+# If you have a good config to start with, then you
|
|
|
+# can specify it with CONFIG_BISECT_GOOD. Otherwise
|
|
|
+# the MIN_CONFIG is the base.
|
|
|
#
|
|
|
# Example:
|
|
|
# TEST_START
|
|
@@ -755,3 +814,68 @@
|
|
|
# MIN_CONFIG = /home/test/config-min
|
|
|
# BISECT_MANUAL = 1
|
|
|
#
|
|
|
+#
|
|
|
+#
|
|
|
+# For TEST_TYPE = make_min_config
|
|
|
+#
|
|
|
+# After doing a make localyesconfig, your kernel configuration may
|
|
|
+# not be the most useful minimum configuration. Having a true minimum
|
|
|
+# config that you can use against other configs is very useful if
|
|
|
+# someone else has a config that breaks on your code. By only forcing
|
|
|
+# those configurations that are truly required to boot your machine
|
|
|
+# will give you less of a chance that one of your set configurations
|
|
|
+# will make the bug go away. This will give you a better chance to
|
|
|
+# be able to reproduce the reported bug matching the broken config.
|
|
|
+#
|
|
|
+# Note, this does take some time, and may require you to run the
|
|
|
+# test over night, or perhaps over the weekend. But it also allows
|
|
|
+# you to interrupt it, and gives you the current minimum config
|
|
|
+# that was found till that time.
|
|
|
+#
|
|
|
+# Note, this test automatically assumes a BUILD_TYPE of oldconfig
|
|
|
+# and its test type acts like boot.
|
|
|
+# TODO: add a test version that makes the config do more than just
|
|
|
+# boot, like having network access.
|
|
|
+#
|
|
|
+# To save time, the test does not just grab any option and test
|
|
|
+# it. The Kconfig files are examined to determine the dependencies
|
|
|
+# of the configs. If a config is chosen that depends on another
|
|
|
+# config, that config will be checked first. By checking the
|
|
|
+# parents first, we can eliminate whole groups of configs that
|
|
|
+# may have been enabled.
|
|
|
+#
|
|
|
+# For example, if a USB device config is chosen and depends on CONFIG_USB,
|
|
|
+# the CONFIG_USB will be tested before the device. If CONFIG_USB is
|
|
|
+# found not to be needed, it, as well as all configs that depend on
|
|
|
+# it, will be disabled and removed from the current min_config.
|
|
|
+#
|
|
|
+# OUTPUT_MIN_CONFIG is the path and filename of the file that will
|
|
|
+# be created from the MIN_CONFIG. If you interrupt the test, set
|
|
|
+# this file as your new min config, and use it to continue the test.
|
|
|
+# This file does not need to exist on start of test.
|
|
|
+# This file is not created until a config is found that can be removed.
|
|
|
+# If this file exists, you will be prompted if you want to use it
|
|
|
+# as the min_config (overriding MIN_CONFIG) if START_MIN_CONFIG
|
|
|
+# is not defined.
|
|
|
+# (required field)
|
|
|
+#
|
|
|
+# START_MIN_CONFIG is the config to use to start the test with.
|
|
|
+# you can set this as the same OUTPUT_MIN_CONFIG, but if you do
|
|
|
+# the OUTPUT_MIN_CONFIG file must exist.
|
|
|
+# (default MIN_CONFIG)
|
|
|
+#
|
|
|
+# IGNORE_CONFIG is used to specify a config file that has configs that
|
|
|
+# you already know must be set. Configs are written here that have
|
|
|
+# been tested and proved to be required. It is best to define this
|
|
|
+# file if you intend on interrupting the test and running it where
|
|
|
+# it left off. New configs that it finds will be written to this file
|
|
|
+# and will not be tested again in later runs.
|
|
|
+# (optional)
|
|
|
+#
|
|
|
+# Example:
|
|
|
+#
|
|
|
+# TEST_TYPE = make_min_config
|
|
|
+# OUTPUT_MIN_CONFIG = /path/to/config-new-min
|
|
|
+# START_MIN_CONFIG = /path/to/config-min
|
|
|
+# IGNORE_CONFIG = /path/to/config-tested
|
|
|
+#
|