If git bisect reply is being used in the bisect tests, don't bother
doing the git bisect good or git bisect bad calls. The git bisect
reply will override them anyway, and that's called immediately
after the other two. Going the git bisect (good|bad) is just a
waste of time.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The reboot function when rebooting back to a good kernel has a check
to make sure that a new kernel was indeed booted. But that check
uses a timeout value, which when calling the monitor will still
return success if the timeout is hit (no bug was found). It should
return an error to let the reboot code know that a new kernel was
not reached. Only the reboot code checks the return value of the
monitor.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add a way to run a patchcheck test on the commits that are in one branch
but not in another. This uses git cherry to find a list of commits to
test each one with.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
With the more robust config_bisect, the documentation is out of
date and needs to be updated.
The new rewrite allows for finding missing configs and such, and
is much more robust to use.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
After the rewrite of the config bisect, there were several unused
functions that can be removed.
One of the unused functions printed out the failed config nicer than
what the rewrite did, so I kept that and used it to output the
bad config.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The new rewrite left out the CONFIG_BISECT_CHECK, which allows the
user to test that their "bad" config still is bad and their "good"
config still is good. This is especially important as the configs
are passed through a "make oldconfig" to update them with the lastest
kernel. Things could change that causes a bad config to work, or a
good config to break. The check is done after the configs have run
through the oldconfig processing.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I never liked the way config-bisect worked. I would assume the bad config
had some config that broke the system. But it would not work if the bad
config just happened to be missing something that the good config had.
I rewrote the config-bisect to do this properly. It does a diff of the two
configs, and sets half of the configs that are in one and not the other.
The way it works is that when it "sets", it really just makes one copy
what the other has. That is, a "set" can be setting a:
# CONFIG_FOO is not set
Basically, it looks at the differences between the two files and makes
them similar until it comes down to one config that makes it work or
not work depending on if it is set or not.
Note, if more than one config change makes the bad config not work, it
will only find one of them. But this is true with all bisect logic.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Some cleanup for improving readability as follows.
- Initialize $ktest_config at its definition.
- Put parentheses around the `config-file' argument in the usage message
because it's a optional one.
- Rename get_ktest_config{,s} to more descriptive get_mandatory_config{,s}.
Link: http://lkml.kernel.org/r/87fvmr30kb.wl%satoru.takeuchi@gmail.com
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Pull ktest updates from Steven Rostedt:
"Here's some basic updates to ktest.pl. They include:
- add config to modify the signal to terminate console
- update to documentation (missing some config options)
- add KERNEL_VERSION variable to use for other configs
- add '=~' to let configs eval other configs
- add BISECT_TRIES to run multiple tests per git bisect good"
* tag 'ktest-v3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest:
ktest: Add BISECT_TRIES to bisect test
ktest: Add eval '=~' command to modify variables in config file
ktest: Add special variable ${KERNEL_VERSION}
ktest: Add documentation of CLOSE_CONSOLE_SIGNAL
ktest: Make the signal to terminate the console configurable
For those cases that it takes several tries to hit a bug, it would be
useful for ktest.pl to try a test multiple times before it considers
the test as a pass. To accomplish this, BISECT_TRIES ktest config
option has been added. It is default to one, as most of the time a
bisect only needs to try a test once. But the user can now up this
to make ktest run a given test multiple times. The first failure
that is detected will set a bisect bad. It only repeats on success.
Note, as with all race bugs, there's no guarantee that if it succeeds,
it is really a good bisect. But it helps in case the bug is somewhat
reliable.
You can set BISECT_TRIES to zero, and all tests will be considered
good, unless you also set BISECT_MANUAL.
Suggested-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
With the added variable ${KERNEL_VERSION}, it is useful to be
able to use parts of it for other variables.
For example, if you want to create a warnings file for each major
kernel version to test sub versions against you can create
your warnings file with like this:
WARNINGS_FILE = warnings-file-${KERNEL_VERSION}
But this may add 3.8.12 or something, and we want all 3.8.* to
use the same file, and 3.10.* to use another file, and so on.
With the eval command we can, by adding:
WARNINGS_FILE =~ s/(-file-\d+\.\d+).*/$1/
Which will chop off the extra characters after the 3.8.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add a special variable that can be used in other variables called
${KERNEL_VERSION}. This will embed the current kernel version into
the variable. For example:
WARNINGS_FILE = ${OUTPUT_DIR}/warnings-${KERNEL_VERSION}
If the current version is v3.8 then the WARNINGS_FILE will become
${OUTPUT_DIR}/warnings-v3.8
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The sample.conf file needs to document all available options.
With the new CLOSE_CONSOE_SIGNAL option, it too needs to be
document.
Cc: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Currently ktest sends SIGINT to terminate the console.
However, there are consoles which do not exit by this signal, for example,
in my case, "virsh console <guest OS>". In such case, ktest is blocked in
close_console(). It prevents this automate test.
This patch adds new option CLOSE_CONSOLE_SIGNAL which mean the
signal to terminate the console. Since its default value is "INT",
the original behavior isn't changed.
Link: http://lkml.kernel.org/r/87zjol8pl5.wl%satoru.takeuchi@gmail.com
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Different tests may use a different machine. In such cases, we need to
try to get the current grub menu index. If the same grub menu is used
for two different machines, it may not be at the same index on the
second machine. A search for the index must be performed again.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
To save connecting and searching for a given grub menu for each test,
ktest.pl will cache the grub number it found. The problem is that
different tests might use a different grub menu, but ktest.pl will
ignore it.
Instead, have ktest.pl check if the grub menu it used to cache the
content is the same as when it grabbed the menu. If not, grab it again,
otherwise just return the cached value.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The index of a line where a warning is tested can be returned
differently on different versions of gcc (or same version compiled
differently). That is, a tab + space can give different results. This
causes the warning check to produce a false positive. Removing the
index from the check fixes this issue.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The reboot just wants to get to the next kernel. But if a warning (Call
Trace) appears, the monitor will report an error, and the reboot will
think something went wrong and power cycle the box, even though we
successfully made it to the next kernel.
Ignore warnings during the reboot until we get to the next kernel. It
will still timeout if we never get to the next kernel and then a power
cycle will happen. That's what we want it to do.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Sometimes when a test kernel passed fine, but on reboot it crashed,
ktest could get stuck and not proceed. This would be frustrating if you
let a test run overnight to find out the next morning that it was stuck
on the first test.
To fix this, I made reboot check for the REBOOT_SUCCESS_LINE. If the
line was not detected, then it would power cycle the box.
What it didn't cover was if the REBOOT_SUCCESS_LINE wasn't defined or if
a 'good' kernel did not display the line. Instead have it search for the
Linux banner "Linux version". The reboot just needs to get to the start
of the next kernel, it does not need to test if the next kernel makes it
to a boot prompt.
After we find the next kernel has booted, then we just wait for either
the REBOOT_SUCCESS_LINE to appear or the timeout.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
