sample.conf 41.1 KB
Newer Older
1
#
2
# Config file for ktest.pl
3 4 5 6
#
# Note, all paths must be absolute
#

7 8 9
# Options set in the beginning of the file are considered to be
# default options. These options can be overriden by test specific
# options, with the following exceptions:
10 11 12 13 14 15
#
#  LOG_FILE
#  CLEAR_LOG
#  POWEROFF_ON_SUCCESS
#  REBOOT_ON_SUCCESS
#
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
# Test specific options are set after the label:
#
# TEST_START
#
# The options after a TEST_START label are specific to that test.
# Each TEST_START label will set up a new test. If you want to
# perform a test more than once, you can add the ITERATE label
# to it followed by the number of times you want that test
# to iterate. If the ITERATE is left off, the test will only
# be performed once.
#
# TEST_START ITERATE 10
#
# You can skip a test by adding SKIP (before or after the ITERATE
# and number)
#
# TEST_START SKIP
#
# TEST_START SKIP ITERATE 10
#
# TEST_START ITERATE 10 SKIP
#
# The SKIP label causes the options and the test itself to be ignored.
# This is useful to set up several different tests in one config file, and
# only enabling the ones you want to use for a current test run.
#
# You can add default options anywhere in the file as well
# with the DEFAULTS tag. This allows you to have default options
# after the test options to keep the test options at the top
# of the file. You can even place the DEFAULTS tag between
# test cases (but not in the middle of a single test case)
#
# TEST_START
# MIN_CONFIG = /home/test/config-test1
#
# DEFAULTS
# MIN_CONFIG = /home/test/config-default
#
# TEST_START ITERATE 10
#
# The above will run the first test with MIN_CONFIG set to
# /home/test/config-test-1. Then 10 tests will be executed
# with MIN_CONFIG with /home/test/config-default.
#
# You can also disable defaults with the SKIP option
#
# DEFAULTS SKIP
# MIN_CONFIG = /home/test/config-use-sometimes
#
# DEFAULTS
# MIN_CONFIG = /home/test/config-most-times
#
# The above will ignore the first MIN_CONFIG. If you want to
# use the first MIN_CONFIG, remove the SKIP from the first
# DEFAULTS tag and add it to the second. Be careful, options
# may only be declared once per test or default. If you have
# the same option name under the same test or as default
# ktest will fail to execute, and no tests will run.
#
75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
# DEFAULTS OVERRIDE
#
# Options defined in the DEFAULTS section can not be duplicated
# even if they are defined in two different DEFAULT sections.
# This is done to catch mistakes where an option is added but
# the previous option was forgotten about and not commented.
#
# The OVERRIDE keyword can be added to a section to allow this
# section to override other DEFAULT sections values that have
# been defined previously. It will only override options that
# have been defined before its use. Options defined later
# in a non override section will still error. The same option
# can not be defined in the same section even if that section
# is marked OVERRIDE.
#
90 91
#
#
92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
# Both TEST_START and DEFAULTS sections can also have the IF keyword
# The value after the IF must evaluate into a 0 or non 0 positive
# integer, and can use the config variables (explained below).
#
# DEFAULTS IF ${IS_X86_32}
#
# The above will process the DEFAULTS section if the config
# variable IS_X86_32 evaluates to a non zero positive integer
# otherwise if it evaluates to zero, it will act the same
# as if the SKIP keyword was used.
#
# The ELSE keyword can be used directly after a section with
# a IF statement.
#
# TEST_START IF ${RUN_NET_TESTS}
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-network
#
# ELSE
#
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-normal
#
#
# The ELSE keyword can also contain an IF statement to allow multiple
# if then else sections. But all the sections must be either
# DEFAULT or TEST_START, they can not be a mixture.
#
# TEST_START IF ${RUN_NET_TESTS}
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-network
#
# ELSE IF ${RUN_DISK_TESTS}
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-tests
#
# ELSE IF ${RUN_CPU_TESTS}
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-cpu
#
# ELSE
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-network
#
130 131 132 133 134 135 136 137 138 139
# The if statement may also have comparisons that will and for
# == and !=, strings may be used for both sides.
#
# BOX_TYPE := x86_32
#
# DEFAULTS IF ${BOX_TYPE} == x86_32
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-32
# ELSE
# BUILD_TYPE = useconfig:${CONFIG_DIR}/config-64
#
140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156
# The DEFINED keyword can be used by the IF statements too.
# It returns true if the given config variable or option has been defined
# or false otherwise.
#
# 
# DEFAULTS IF DEFINED USE_CC
# CC := ${USE_CC}
# ELSE
# CC := gcc
#
#
# As well as NOT DEFINED.
#
# DEFAULTS IF NOT DEFINED MAKE_CMD
# MAKE_CMD := make ARCH=x86
#
#
157 158 159 160
# And/or ops (&&,||) may also be used to make complex conditionals.
#
# TEST_START IF (DEFINED ALL_TESTS || ${MYTEST} == boottest) && ${MACHINE} == gandalf
#
161
# Notice the use of parentheses. Without any parentheses the above would be
162 163 164 165 166
# processed the same as:
#
# TEST_START IF DEFINED ALL_TESTS || (${MYTEST} == boottest && ${MACHINE} == gandalf)
#
#
167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196
#
# INCLUDE file
#
# The INCLUDE keyword may be used in DEFAULT sections. This will
# read another config file and process that file as well. The included
# file can include other files, add new test cases or default
# statements. Config variables will be passed to these files and changes
# to config variables will be seen by top level config files. Including
# a file is processed just like the contents of the file was cut and pasted
# into the top level file, except, that include files that end with
# TEST_START sections will have that section ended at the end of
# the include file. That is, an included file is included followed
# by another DEFAULT keyword.
#
# Unlike other files referenced in this config, the file path does not need
# to be absolute. If the file does not start with '/', then the directory
# that the current config file was located in is used. If no config by the
# given name is found there, then the current directory is searched.
#
# INCLUDE myfile
# DEFAULT
#
# is the same as:
#
# INCLUDE myfile
#
# Note, if the include file does not contain a full path, the file is
# searched first by the location of the original include file, and then
# by the location that ktest.pl was executed in.
#
197

198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256
#### Config variables ####
#
# This config file can also contain "config variables".
# These are assigned with ":=" instead of the ktest option
# assigment "=".
#
# The difference between ktest options and config variables
# is that config variables can be used multiple times,
# where each instance will override the previous instance.
# And that they only live at time of processing this config.
#
# The advantage to config variables are that they can be used
# by any option or any other config variables to define thing
# that you may use over and over again in the options.
#
# For example:
#
# USER      := root
# TARGET    := mybox
# TEST_CASE := ssh ${USER}@${TARGET} /path/to/my/test
#
# TEST_START
# MIN_CONFIG = config1
# TEST = ${TEST_CASE}
#
# TEST_START
# MIN_CONFIG = config2
# TEST = ${TEST_CASE}
#
# TEST_CASE := ssh ${USER}@${TARGET} /path/to/my/test2
#
# TEST_START
# MIN_CONFIG = config1
# TEST = ${TEST_CASE}
#
# TEST_START
# MIN_CONFIG = config2
# TEST = ${TEST_CASE}
#
# TEST_DIR := /home/me/test
#
# BUILD_DIR = ${TEST_DIR}/linux.git
# OUTPUT_DIR = ${TEST_DIR}/test
#
# Note, the config variables are evaluated immediately, thus
# updating TARGET after TEST_CASE has been assigned does nothing
# to TEST_CASE.
#
# As shown in the example, to evaluate a config variable, you
# use the ${X} convention. Simple $X will not work.
#
# If the config variable does not exist, the ${X} will not
# be evaluated. Thus:
#
# MAKE_CMD = PATH=/mypath:${PATH} make
#
# If PATH is not a config variable, then the ${PATH} in
# the MAKE_CMD option will be evaluated by the shell when
# the MAKE_CMD option is passed into shell processing.
257

258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287
#### Using options in other options ####
#
# Options that are defined in the config file may also be used
# by other options. All options are evaulated at time of
# use (except that config variables are evaluated at config
# processing time).
#
# If an ktest option is used within another option, instead of
# typing it again in that option you can simply use the option
# just like you can config variables.
#
# MACHINE = mybox
#
# TEST = ssh root@${MACHINE} /path/to/test
#
# The option will be used per test case. Thus:
#
# TEST_TYPE = test
# TEST = ssh root@{MACHINE}
#
# TEST_START
# MACHINE = box1
#
# TEST_START
# MACHINE = box2
#
# For both test cases, MACHINE will be evaluated at the time
# of the test case. The first test will run ssh root@box1
# and the second will run ssh root@box2.

288
#### Mandatory Default Options ####
289

290 291
# These options must be in the default section, although most
# may be overridden by test options.
292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314

# The machine hostname that you will test
#MACHINE = target

# The box is expected to have ssh on normal bootup, provide the user
#  (most likely root, since you need privileged operations)
#SSH_USER = root

# The directory that contains the Linux source code
#BUILD_DIR = /home/test/linux.git

# The directory that the objects will be built
# (can not be same as BUILD_DIR)
#OUTPUT_DIR = /home/test/build/target

# The location of the compiled file to copy to the target
# (relative to OUTPUT_DIR)
#BUILD_TARGET = arch/x86/boot/bzImage

# The place to put your image on the test machine
#TARGET_IMAGE = /boot/vmlinuz-test

# A script or command to reboot the box
315
#
316 317
# Here is a digital loggers power switch example
#POWER_CYCLE = wget --no-proxy -O /dev/null -q  --auth-no-challenge 'http://admin:admin@power/outlet?5=CCL'
318
#
319 320
# Here is an example to reboot a virtual box on the current host
# with the name "Guest".
321
#POWER_CYCLE = virsh destroy Guest; sleep 5; virsh start Guest
322 323

# The script or command that reads the console
324
#
325 326
#  If you use ttywatch server, something like the following would work.
#CONSOLE = nc -d localhost 3001
327
#
328
# For a virtual machine with guest name "Guest".
329
#CONSOLE =  virsh console Guest
330 331 332 333 334 335 336 337

# Required version ending to differentiate the test
# from other linux builds on the system.
#LOCALVERSION = -test

# The grub title name for the test kernel to boot
# (Only mandatory if REBOOT_TYPE = grub)
#
338 339 340 341 342
# Note, ktest.pl will not update the grub menu.lst, you need to
# manually add an option for the test. ktest.pl will search
# the grub menu.lst for this option to find what kernel to
# reboot into.
#
343 344
# For example, if in the /boot/grub/menu.lst the test kernel title has:
# title Test Kernel
345
# kernel vmlinuz-test
346 347 348
#GRUB_MENU = Test Kernel

# A script to reboot the target into the test kernel
349 350 351 352
# This and SWITCH_TO_TEST are about the same, except
# SWITCH_TO_TEST is run even for REBOOT_TYPE = grub.
# This may be left undefined.
# (default undefined)
353 354 355 356
#REBOOT_SCRIPT =

#### Optional Config Options (all have defaults) ####

357 358 359 360 361 362 363 364 365
# Start a test setup. If you leave this off, all options
# will be default and the test will run once.
# This is a label and not really an option (it takes no value).
# You can append ITERATE and a number after it to iterate the
# test a number of times, or SKIP to ignore this test.
#
#TEST_START
#TEST_START ITERATE 5
#TEST_START SKIP
366

367 368 369 370 371 372 373 374 375 376 377 378
# Have the following options as default again. Used after tests
# have already been defined by TEST_START. Optionally, you can
# just define all default options before the first TEST_START
# and you do not need this option.
#
# This is a label and not really an option (it takes no value).
# You can append SKIP to this label and the options within this
# section will be ignored.
#
# DEFAULTS
# DEFAULTS SKIP

379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396
# If you want to execute some command before the first test runs
# you can set this option. Note, it can be set as a default option
# or an option in the first test case. All other test cases will
# ignore it. If both the default and first test have this option
# set, then the first test will take precedence.
#
# default (undefined)
#PRE_KTEST = ${SSH} ~/set_up_test

# If you want to execute some command after all the tests have
# completed, you can set this option. Note, it can be set as a
# default or any test case can override it. If multiple test cases
# set this option, then the last test case that set it will take
# precedence
#
# default (undefined)
#POST_KTEST = ${SSH} ~/dismantle_test

397 398
# The default test type (default test)
# The test types may be:
399 400 401 402
#   build   - only build the kernel, do nothing else
#   install - build and install, but do nothing else (does not reboot)
#   boot    - build, install, and boot the kernel
#   test    - build, boot and if TEST is set, run the test script
403
#          (If TEST is not set, it defaults back to boot)
404 405 406 407
#   bisect - Perform a bisect on the kernel (see BISECT_TYPE below)
#   patchcheck - Do a test on a series of commits in git (see PATCHCHECK below)
#TEST_TYPE = test

408 409 410 411 412 413
# Test to run if there is a successful boot and TEST_TYPE is test.
# Must exit with 0 on success and non zero on error
# default (undefined)
#TEST = ssh user@machine /root/run_test

# The build type is any make config type or special command
414 415
#  (default randconfig)
#   nobuild - skip the clean and build step
416 417 418
#   useconfig:/path/to/config - use the given config and run
#              oldconfig on it.
# This option is ignored if TEST_TYPE is patchcheck or bisect
419 420 421 422 423 424
#BUILD_TYPE = randconfig

# The make command (default make)
# If you are building a 32bit x86 on a 64 bit host
#MAKE_CMD = CC=i386-gcc AS=i386-as make ARCH=i386

425 426 427 428
# Any build options for the make of the kernel (not for other makes, like configs)
# (default "")
#BUILD_OPTIONS = -j20

S
Steven Rostedt 已提交
429 430 431 432 433 434 435 436
# If you need to do some special handling before installing
# you can add a script with this option.
# The environment variable KERNEL_VERSION will be set to the
# kernel version that is used.
#
# default (undefined)
#PRE_INSTALL = ssh user@target rm -rf '/lib/modules/*-test*'

437 438
# If you need an initrd, you can add a script or code here to install
# it. The environment variable KERNEL_VERSION will be set to the
439 440 441 442
# kernel version that is used. Remember to add the initrd line
# to your grub menu.lst file.
#
# Here's a couple of examples to use:
443
#POST_INSTALL = ssh user@target /sbin/mkinitrd --allow-missing -f /boot/initramfs-test.img $KERNEL_VERSION
444 445 446
#
# or on some systems:
#POST_INSTALL = ssh user@target /sbin/dracut -f /boot/initramfs-test.img $KERNEL_VERSION
447

448 449 450 451 452 453 454
# If for some reason you just want to boot the kernel and you do not
# want the test to install anything new. For example, you may just want
# to boot test the same kernel over and over and do not want to go through
# the hassle of installing anything, you can set this option to 1
# (default 0)
#NO_INSTALL = 1

455 456 457 458 459 460 461 462 463 464 465 466
# If there is a command that you want to run before the individual test
# case executes, then you can set this option
#
# default (undefined)
#PRE_TEST = ${SSH} reboot_to_special_kernel

# If there is a command you want to run after the individual test case
# completes, then you can set this option.
#
# default (undefined)
#POST_TEST = cd ${BUILD_DIR}; git reset --hard

467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498
# 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

499 500 501 502 503 504 505 506
# Way to reboot the box to the test kernel.
# Only valid options so far are "grub" and "script"
# (default grub)
# If you specify grub, it will assume grub version 1
# and will search in /boot/grub/menu.lst for the title $GRUB_MENU
# and select that target to reboot to the kernel. If this is not
# your setup, then specify "script" and have a command or script
# specified in REBOOT_SCRIPT to boot to the target.
507 508 509
#
# The entry in /boot/grub/menu.lst must be entered in manually.
# The test will not modify that file.
510 511
#REBOOT_TYPE = grub

512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532
# If you are using a machine that doesn't boot with grub, and
# perhaps gets its kernel from a remote server (tftp), then
# you can use this option to update the target image with the
# test image.
#
# You could also do the same with POST_INSTALL, but the difference
# between that option and this option is that POST_INSTALL runs
# after the install, where this one runs just before a reboot.
# (default undefined)
#SWITCH_TO_TEST = cp ${OUTPUT_DIR}/${BUILD_TARGET} ${TARGET_IMAGE}

# If you are using a machine that doesn't boot with grub, and
# perhaps gets its kernel from a remote server (tftp), then
# you can use this option to update the target image with the
# the known good image to reboot safely back into.
#
# This option holds a command that will execute before needing
# to reboot to a good known image.
# (default undefined)
#SWITCH_TO_GOOD = ssh ${SSH_USER}/${MACHINE} cp good_image ${TARGET_IMAGE}

533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586
# The min config that is needed to build for the machine
# A nice way to create this is with the following:
#
#   $ ssh target
#   $ lsmod > mymods
#   $ scp mymods host:/tmp
#   $ exit
#   $ cd linux.git
#   $ rm .config
#   $ make LSMOD=mymods localyesconfig
#   $ grep '^CONFIG' .config > /home/test/config-min
#
# If you want even less configs:
#
#   log in directly to target (do not ssh)
#
#   $ su
#   # lsmod | cut -d' ' -f1 | xargs rmmod
#
#   repeat the above several times
#
#   # lsmod > mymods
#   # reboot
#
# May need to reboot to get your network back to copy the mymods
# to the host, and then remove the previous .config and run the
# localyesconfig again. The CONFIG_MIN generated like this will
# not guarantee network activity to the box so the TEST_TYPE of
# test may fail.
#
# You might also want to set:
#   CONFIG_CMDLINE="<your options here>"
#  randconfig may set the above and override your real command
#  line options.
# (default undefined)
#MIN_CONFIG = /home/test/config-min

# Sometimes there's options that just break the boot and
# you do not care about. Here are a few:
#   # CONFIG_STAGING is not set
#  Staging drivers are horrible, and can break the build.
#   # CONFIG_SCSI_DEBUG is not set
#  SCSI_DEBUG may change your root partition
#   # CONFIG_KGDB_SERIAL_CONSOLE is not set
#  KGDB may cause oops waiting for a connection that's not there.
# This option points to the file containing config options that will be prepended
# to the MIN_CONFIG (or be the MIN_CONFIG if it is not set)
#
# Note, config options in MIN_CONFIG will override these options.
#
# (default undefined)
#ADD_CONFIG = /home/test/config-broken

# The location on the host where to write temp files
587 588
# (default /tmp/ktest/${MACHINE})
#TMP_DIR = /tmp/ktest/${MACHINE}
589 590 591 592 593 594 595 596 597 598 599

# Optional log file to write the status (recommended)
#  Note, this is a DEFAULT section only option.
# (default undefined)
#LOG_FILE = /home/test/logfiles/target.log

# Remove old logfile if it exists before starting all tests.
#  Note, this is a DEFAULT section only option.
# (default 0)
#CLEAR_LOG = 0

600
# Line to define a successful boot up in console output.
601
# This is what the line contains, not the entire line. If you need
602 603 604 605 606 607
# the entire line to match, then use regural expression syntax like:
#  (do not add any quotes around it)
#
#  SUCCESS_LINE = ^MyBox Login:$
#
# (default "login:")
608 609
#SUCCESS_LINE = login:

610 611 612 613 614 615 616 617
# To speed up between reboots, defining a line that the
# default kernel produces that represents that the default
# kernel has successfully booted and can be used to pass
# a new test kernel to it. Otherwise ktest.pl will wait till
# SLEEP_TIME to continue.
# (default undefined)
#REBOOT_SUCCESS_LINE = login:

618 619 620 621 622 623 624 625 626 627 628 629
# In case the console constantly fills the screen, having
# a specified time to stop the test after success is recommended.
# (in seconds)
# (default 10)
#STOP_AFTER_SUCCESS = 10

# In case the console constantly fills the screen, having
# a specified time to stop the test after failure is recommended.
# (in seconds)
# (default 60)
#STOP_AFTER_FAILURE = 60

630 631 632 633 634 635 636 637
# In case the console constantly fills the screen, having
# a specified time to stop the test if it never succeeds nor fails
# is recommended.
# Note: this is ignored if a success or failure is detected.
# (in seconds)
# (default 600, -1 is to never stop)
#STOP_TEST_AFTER = 600

638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653
# Stop testing if a build fails. If set, the script will end if
# a failure is detected, otherwise it will save off the .config,
# dmesg and bootlog in a directory called
# MACHINE-TEST_TYPE_BUILD_TYPE-fail-yyyymmddhhmmss
# if the STORE_FAILURES directory is set.
# (default 1)
# Note, even if this is set to zero, there are some errors that still
# stop the tests.
#DIE_ON_FAILURE = 1

# Directory to store failure directories on failure. If this is not
# set, DIE_ON_FAILURE=0 will not save off the .config, dmesg and
# bootlog. This option is ignored if DIE_ON_FAILURE is not set.
# (default undefined)
#STORE_FAILURES = /home/test/failures

654 655 656 657 658 659
# Directory to store success directories on success. If this is not
# set, the .config, dmesg and bootlog will not be saved if a
# test succeeds.
# (default undefined)
#STORE_SUCCESSES = /home/test/successes

660 661 662 663
# Build without doing a make mrproper, or removing .config
# (default 0)
#BUILD_NOCLEAN = 0

664 665 666 667 668 669 670
# As the test reads the console, after it hits the SUCCESS_LINE
# the time it waits for the monitor to settle down between reads
# can usually be lowered.
# (in seconds) (default 1)
#BOOTED_TIMEOUT = 1

# The timeout in seconds when we consider the box hung after
671 672 673 674 675
# the console stop producing output. Be sure to leave enough
# time here to get pass a reboot. Some machines may not produce
# any console output for a long time during a reboot. You do
# not want the test to fail just because the system was in
# the process of rebooting to the test kernel.
676 677 678 679 680 681 682
# (default 120)
#TIMEOUT = 120

# In between tests, a reboot of the box may occur, and this
# is the time to wait for the console after it stops producing
# output. Some machines may not produce a large lag on reboot
# so this should accommodate it.
683 684 685 686 687 688
# The difference between this and TIMEOUT, is that TIMEOUT happens
# when rebooting to the test kernel. This sleep time happens
# after a test has completed and we are about to start running
# another test. If a reboot to the reliable kernel happens,
# we wait SLEEP_TIME for the console to stop producing output
# before starting the next test.
689 690
#
# You can speed up reboot times even more by setting REBOOT_SUCCESS_LINE.
691 692 693 694
# (default 60)
#SLEEP_TIME = 60

# The time in between bisects to sleep (in seconds)
695
# (default 60)
696 697
#BISECT_SLEEP_TIME = 60

698 699 700 701
# The time in between patch checks to sleep (in seconds)
# (default 60)
#PATCHCHECK_SLEEP_TIME = 60

702 703 704 705
# Reboot the target box on error (default 0)
#REBOOT_ON_ERROR = 0

# Power off the target on error (ignored if REBOOT_ON_ERROR is set)
706
#  Note, this is a DEFAULT section only option.
707 708 709 710
# (default 0)
#POWEROFF_ON_ERROR = 0

# Power off the target after all tests have completed successfully
711
#  Note, this is a DEFAULT section only option.
712 713 714 715 716 717 718
# (default 0)
#POWEROFF_ON_SUCCESS = 0

# Reboot the target after all test completed successfully (default 1)
# (ignored if POWEROFF_ON_SUCCESS is set)
#REBOOT_ON_SUCCESS = 1

719
# In case there are isses with rebooting, you can specify this
720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736
# to always powercycle after this amount of time after calling
# reboot.
# Note, POWERCYCLE_AFTER_REBOOT = 0 does NOT disable it. It just
# makes it powercycle immediately after rebooting. Do not define
# it if you do not want it.
# (default undefined)
#POWERCYCLE_AFTER_REBOOT = 5

# In case there's isses with halting, you can specify this
# to always poweroff after this amount of time after calling
# halt.
# Note, POWEROFF_AFTER_HALT = 0 does NOT disable it. It just
# makes it poweroff immediately after halting. Do not define
# it if you do not want it.
# (default undefined)
#POWEROFF_AFTER_HALT = 20

737
# A script or command to power off the box (default undefined)
738
# Needed for POWEROFF_ON_ERROR and SUCCESS
739
#
740 741
# Example for digital loggers power switch:
#POWER_OFF = wget --no-proxy -O /dev/null -q  --auth-no-challenge 'http://admin:admin@power/outlet?5=OFF'
742
#
743
# Example for a virtual guest call "Guest".
744
#POWER_OFF = virsh destroy Guest
745

746 747 748 749 750
# The way to execute a command on the target
# (default ssh $SSH_USER@$MACHINE $SSH_COMMAND";)
# The variables SSH_USER, MACHINE and SSH_COMMAND are defined
#SSH_EXEC = ssh $SSH_USER@$MACHINE $SSH_COMMAND";

751
# The way to copy a file to the target (install and modules)
752
# (default scp $SRC_FILE $SSH_USER@$MACHINE:$DST_FILE)
753 754 755 756 757 758 759 760 761 762
# The variables SSH_USER, MACHINE are defined by the config
# SRC_FILE and DST_FILE are ktest internal variables and
# should only have '$' and not the '${}' notation.
# (default scp $SRC_FILE ${SSH_USER}@${MACHINE}:$DST_FILE)
#SCP_TO_TARGET = echo skip scp for $SRC_FILE $DST_FILE

# If install needs to be different than modules, then this
# option will override the SCP_TO_TARGET for installation.
# (default ${SCP_TO_TARGET} )
#SCP_TO_TARGET_INSTALL = scp $SRC_FILE tftp@tftpserver:$DST_FILE
763 764 765 766 767 768

# The nice way to reboot the target
# (default ssh $SSH_USER@$MACHINE reboot)
# The variables SSH_USER and MACHINE are defined.
#REBOOT = ssh $SSH_USER@$MACHINE reboot

769 770 771 772 773 774 775 776 777 778
# 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

779 780 781 782 783 784 785 786 787 788 789
# All options in the config file should be either used by ktest
# or could be used within a value of another option. If an option
# in the config file is not used, ktest will warn about it and ask
# if you want to continue.
#
# If you don't care if there are non-used options, enable this
# option. Be careful though, a non-used option is usually a sign
# of an option name being typed incorrectly.
# (default 0)
#IGNORE_UNUSED = 1

790 791 792 793 794 795 796 797
# When testing a kernel that happens to have WARNINGs, and call
# traces, ktest.pl will detect these and fail a boot or test run
# due to warnings. By setting this option, ktest will ignore
# call traces, and will not fail a test if the kernel produces
# an oops. Use this option with care.
# (default 0)
#IGNORE_ERRORS = 1

798
#### Per test run options ####
799 800
# The following options are only allowed in TEST_START sections.
# They are ignored in the DEFAULTS sections.
801
#
802 803 804
# All of these are optional and undefined by default, although
#  some of these options are required for TEST_TYPE of patchcheck
#  and bisect.
805
#
806 807
#
# CHECKOUT = branch
808 809 810 811
#
#  If the BUILD_DIR is a git repository, then you can set this option
#  to checkout the given branch before running the TEST. If you
#  specify this for the first run, that branch will be used for
812 813
#  all preceding tests until a new CHECKOUT is set.
#
814
#
S
Steven Rostedt 已提交
815 816 817 818 819 820
# 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.
821 822
#
# For TEST_TYPE = patchcheck
823 824
#
#  This expects the BUILD_DIR to be a git repository, and
825 826 827
#  will checkout the PATCHCHECK_START commit.
#
#  The option BUILD_TYPE will be ignored.
828
#
829 830
#  The MIN_CONFIG will be used for all builds of the patchcheck. The build type
#  used for patchcheck is oldconfig.
831
#
832 833 834
#  PATCHCHECK_START is required and is the first patch to
#   test (the SHA1 of the commit). You may also specify anything
#   that git checkout allows (branch name, tage, HEAD~3).
835
#
836 837 838
#  PATCHCHECK_END is the last patch to check (default HEAD)
#
#  PATCHCHECK_TYPE is required and is the type of test to run:
839 840 841
#      build, boot, test.
#
#   Note, the build test will look for warnings, if a warning occurred
842 843 844 845 846 847
#     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.
848 849 850 851 852 853 854 855
#
#   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
#   what makes patchcheck different from the other tests, is if
#   BUILD_NOCLEAN is not set, only the first and last patch run
#   make mrproper. This helps speed up the test.
#
# Example:
856 857 858 859 860
#   TEST_START
#   TEST_TYPE = patchcheck
#   CHECKOUT = mybranch
#   PATCHCHECK_TYPE = boot
#   PATCHCHECK_START = 747e94ae3d1b4c9bf5380e569f614eb9040b79e7
861
#   PATCHCHECK_END = HEAD~2
862
#   IGNORE_WARNINGS = 42f9c6b69b54946ffc0515f57d01dc7f5c0e4712 0c17ca2c7187f431d8ffc79e81addc730f33d128
863
#
864 865
#
#
866
# For TEST_TYPE = bisect
867
#
868 869 870
#  You can specify a git bisect if the BUILD_DIR is a git repository.
#  The MIN_CONFIG will be used for all builds of the bisect. The build type
#  used for bisecting is oldconfig.
871
#
872 873 874
#  The option BUILD_TYPE will be ignored.
#
#  BISECT_TYPE is the type of test to perform:
875 876 877 878
#	build	- bad fails to build
#	boot	- bad builds but fails to boot
#	test	- bad boots but fails a test
#
879 880
# BISECT_GOOD is the commit (SHA1) to label as good (accepts all git good commit types)
# BISECT_BAD is the commit to label as bad (accepts all git bad commit types)
881 882 883
#
# The above three options are required for a bisect operation.
#
884
# BISECT_REPLAY = /path/to/replay/file (optional, default undefined)
885 886 887
#
#   If an operation failed in the bisect that was not expected to
#   fail. Then the test ends. The state of the BUILD_DIR will be
888
#   left off at where the failure occurred. You can examine the
889 890 891 892 893
#   reason for the failure, and perhaps even find a git commit
#   that would work to continue with. You can run:
#
#   git bisect log > /path/to/replay/file
#
894
#   The adding:
895
#
896
#    BISECT_REPLAY= /path/to/replay/file
897
#
898 899 900 901
#   And running the test again. The test will perform the initial
#    git bisect start, git bisect good, and git bisect bad, and
#    then it will run git bisect replay on this file, before
#    continuing with the bisect.
902
#
903 904 905 906 907 908 909 910
# BISECT_START = commit (optional, default undefined)
#
#   As with BISECT_REPLAY, if the test failed on a commit that
#   just happen to have a bad commit in the middle of the bisect,
#   and you need to skip it. If BISECT_START is defined, it
#   will checkout that commit after doing the initial git bisect start,
#   git bisect good, git bisect bad, and running the git bisect replay
#   if the BISECT_REPLAY is set.
911
#
S
Steven Rostedt 已提交
912 913 914 915 916 917 918 919 920
# BISECT_SKIP = 1 (optional, default 0)
#
#   If BISECT_TYPE is set to test but the build fails, ktest will
#   simply fail the test and end their. You could use BISECT_REPLAY
#   and BISECT_START to resume after you found a new starting point,
#   or you could set BISECT_SKIP to 1. If BISECT_SKIP is set to 1,
#   when something other than the BISECT_TYPE fails, ktest.pl will
#   run "git bisect skip" and try again.
#
921 922 923 924 925 926 927 928 929
# BISECT_FILES = <path> (optional, default undefined)
#
#   To just run the git bisect on a specific path, set BISECT_FILES.
#   For example:
#
#     BISECT_FILES = arch/x86 kernel/time
#
#   Will run the bisect with "git bisect start -- arch/x86 kernel/time"
#
930
# BISECT_REVERSE = 1 (optional, default 0)
931 932 933
#
#   In those strange instances where it was broken forever
#   and you are trying to find where it started to work!
934 935 936 937
#   Set BISECT_GOOD to the commit that was last known to fail
#   Set BISECT_BAD to the commit that is known to start working.
#   With BISECT_REVERSE = 1, The test will consider failures as
#   good, and success as bad.
938
#
S
Steven Rostedt 已提交
939 940 941 942 943 944 945 946 947
# BISECT_MANUAL = 1 (optional, default 0)
#
#   In case there's a problem with automating the bisect for
#   whatever reason. (Can't reboot, want to inspect each iteration)
#   Doing a BISECT_MANUAL will have the test wait for you to
#   tell it if the test passed or failed after each iteration.
#   This is basicall the same as running git bisect yourself
#   but ktest will rebuild and install the kernel for you.
#
948
# BISECT_CHECK = 1 (optional, default 0)
949 950
#
#   Just to be sure the good is good and bad is bad, setting
951 952 953 954
#   BISECT_CHECK to 1 will start the bisect by first checking
#   out BISECT_BAD and makes sure it fails, then it will check
#   out BISECT_GOOD and makes sure it succeeds before starting
#   the bisect (it works for BISECT_REVERSE too).
955
#
956 957 958
#   You can limit the test to just check BISECT_GOOD or
#   BISECT_BAD with BISECT_CHECK = good or
#   BISECT_CHECK = bad, respectively.
959
#
960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995
# BISECT_RET_GOOD = 0 (optional, default undefined)
#
#   In case the specificed test returns something other than just
#   0 for good, and non-zero for bad, you can override 0 being
#   good by defining BISECT_RET_GOOD.
#
# BISECT_RET_BAD = 1 (optional, default undefined)
#
#   In case the specificed test returns something other than just
#   0 for good, and non-zero for bad, you can override non-zero being
#   bad by defining BISECT_RET_BAD.
#
# BISECT_RET_ABORT = 255 (optional, default undefined)
#
#   If you need to abort the bisect if the test discovers something
#   that was wrong, you can define BISECT_RET_ABORT to be the error
#   code returned by the test in order to abort the bisect.
#
# BISECT_RET_SKIP = 2 (optional, default undefined)
#
#   If the test detects that the current commit is neither good
#   nor bad, but something else happened (another bug detected)
#   you can specify BISECT_RET_SKIP to an error code that the
#   test returns when it should skip the current commit.
#
# BISECT_RET_DEFAULT = good (optional, default undefined)
#
#   You can override the default of what to do when the above
#   options are not hit. This may be one of, "good", "bad",
#   "abort" or "skip" (without the quotes).
#
#   Note, if you do not define any of the previous BISECT_RET_*
#   and define BISECT_RET_DEFAULT, all bisects results will do
#   what the BISECT_RET_DEFAULT has.
#
#
996
# Example:
997 998 999 1000 1001 1002
#   TEST_START
#   TEST_TYPE = bisect
#   BISECT_GOOD = v2.6.36
#   BISECT_BAD = b5153163ed580e00c67bdfecb02b2e3843817b3e
#   BISECT_TYPE = build
#   MIN_CONFIG = /home/test/config-bisect
1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066
#
#
#
# For TEST_TYPE = config_bisect
#
#  In those cases that you have two different configs. One of them
#  work, the other does not, and you do not know what config causes
#  the problem.
#  The TEST_TYPE config_bisect will bisect the bad config looking for
#  what config causes the failure.
#
#  The way it works is this:
#
#   First it finds a config to work with. Since a different version, or
#   MIN_CONFIG may cause different dependecies, it must run through this
#   preparation.
#
#   Overwrites any config set in the bad config with a config set in
#   either the MIN_CONFIG or ADD_CONFIG. Thus, make sure these configs
#   are minimal and do not disable configs you want to test:
#   (ie.  # CONFIG_FOO is not set).
#
#   An oldconfig is run on the bad config and any new config that
#   appears will be added to the configs to test.
#
#   Finally, it generates a config with the above result and runs it
#   again through make oldconfig to produce a config that should be
#   satisfied by kconfig.
#
#   Then it starts the bisect.
#
#   The configs to test are cut in half. If all the configs in this
#   half depend on a config in the other half, then the other half
#   is tested instead. If no configs are enabled by either half, then
#   this means a circular dependency exists and the test fails.
#
#   A config is created with the test half, and the bisect test is run.
#
#   If the bisect succeeds, then all configs in the generated config
#   are removed from the configs to test and added to the configs that
#   will be enabled for all builds (they will be enabled, but not be part
#   of the configs to examine).
#
#   If the bisect fails, then all test configs that were not enabled by
#   the config file are removed from the test. These configs will not
#   be enabled in future tests. Since current config failed, we consider
#   this to be a subset of the config that we started with.
#
#   When we are down to one config, it is considered the bad config.
#
#   Note, the config chosen may not be the true bad config. Due to
#   dependencies and selections of the kbuild system, mulitple
#   configs may be needed to cause a failure. If you disable the
#   config that was found and restart the test, if the test fails
#   again, it is recommended to rerun the config_bisect with a new
#   bad config without the found config enabled.
#
#  The option BUILD_TYPE will be ignored.
#
#  CONFIG_BISECT_TYPE is the type of test to perform:
#	build	- bad fails to build
#	boot	- bad builds but fails to boot
#	test	- bad boots but fails a test
#
1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078
#  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.
#
# 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.
S
Steven Rostedt 已提交
1079
#
1080 1081 1082 1083
# Example:
#   TEST_START
#   TEST_TYPE = config_bisect
#   CONFIG_BISECT_TYPE = build
A
Al Viro 已提交
1084
#   CONFIG_BISECT = /home/test/config-bad
1085
#   MIN_CONFIG = /home/test/config-min
S
Steven Rostedt 已提交
1086
#   BISECT_MANUAL = 1
1087
#
1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110
#
#
# 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.
#
1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122
#  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.
#
1123 1124 1125 1126 1127
#  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.
1128 1129 1130
#   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.
1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145
#   (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)
#
1146 1147 1148 1149 1150 1151 1152 1153
#  MIN_CONFIG_TYPE can be either 'boot' or 'test'. With 'boot' it will
#   test if the created config can just boot the machine. If this is
#   set to 'test', then the TEST option must be defined and the created
#   config will not only boot the target, but also make sure that the
#   config lets the test succeed. This is useful to make sure the final
#   config that is generated allows network activity (ssh).
#   (optional)
#
1154 1155 1156 1157 1158 1159
#  USE_OUTPUT_MIN_CONFIG set this to 1 if you do not want to be prompted
#   about using the OUTPUT_MIN_CONFIG as the MIN_CONFIG as the starting
#   point. Set it to 0 if you want to always just use the given MIN_CONFIG.
#   If it is not defined, it will prompt you to pick which config
#   to start with (MIN_CONFIG or OUTPUT_MIN_CONFIG).
#
1160 1161 1162 1163 1164 1165
# 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
1166 1167
#  MIN_CONFIG_TYPE = test
#  TEST = ssh ${USER}@${MACHINE} echo hi
1168
#