15 Nov, 2013
5 commits
-
Allows for scripting test runs by module load / unload. Prevent module
load from returning until 'iterations' (finite) tests have completed, or
cause reads of the 'wait' parameter in sysfs to pause until the tests
are done.Also killed the local waitqueue since we can just let the thread exit
naturally as long as we hold a reference.Cc: Nicolas Ferre
Signed-off-by: Dan Williams -
Add iops and throughput to the summary output.
Acked-by: Andy Shevchenko
Signed-off-by: Dan Williams -
1/ move 'run' control to a module parameter so we can do:
modprobe dmatest run=1. With this moved the rest of the debugfs
boilerplate can go.2/ Fix parameter initialization. Previously the test was being started
without taking the parameters into account in the built-in case.Also killed off the '__' version of some routines. The new rule is just
hold the lock when calling a *threaded_test() routine.Acked-by: Linus Walleij
Cc: Andy Shevchenko
Acked-by: Andy Shevchenko
Signed-off-by: Dan Williams -
For long running tests the tracking results in a memory leak for the "ok"
results, and for the failures the kernel log should be sufficient. Provide a
uniform format for error messages so they can be easily parsed and remove the
debugfs file.Cc: Andy Shevchenko
Signed-off-by: Dan Williams -
This reverts commit d86b2f298e6de124984f5d5817ed1e6e759b3ada.
The kernel log buffer is sufficient for collecting test results. The
current logging OOMs the machine on long running tests, and usually only
the first error is relevant. It is better to stop on error and parse
the kernel output. If output volume becomes an issue we can always
investigate using trace messages.Cc: Andy Shevchenko
Acked-by: Andy Shevchenko
Signed-off-by: Dan Williams
23 Aug, 2013
1 commit
-
The debugfs interface brought a copy of the test case parameters. This makes
different set of values under /sys/module/dmatest/parameters/ and
/sys/kernel/debug/dmatest/. The user might be confused by the divergence of
values.The proposed solution in this patch is to make module parameters writable and
remove them from the debugfs. Though we're still using debugfs to control test
runner and getting results.Documentation part is updated accordingly.
Signed-off-by: Andy Shevchenko
Suggested-by: Dan Williams
Signed-off-by: Dan Williams
08 Jun, 2013
1 commit
-
When user interrupts ongoing transfers the dmatest may end up with console
lockup, oops, or data mismatch. This patch prevents user to abort any ongoing
test.Documentation is updated accordingly.
Signed-off-by: Andy Shevchenko
Reported-by: Will Deacon
Tested-by: Will Deacon
Signed-off-by: Vinod Koul
15 Apr, 2013
4 commits
-
Comparison between buffers is stored to the dedicated structure.
Note that the verify result is now accessible only via file 'results' in the
debugfs.Signed-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul -
The patch provides a storage for the test results in the linked list. The
gathered data could be used after test is done.The new file 'results' represents gathered data of the in progress test. The
messages collected are printed to the kernel log as well.Example of output:
% cat /sys/kernel/debug/dmatest/results
dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)The message format is unified across the different types of errors. A number in
the parens represents additional information, e.g. error code, error counter,
or status.Note that the buffer comparison is done in the old way, i.e. data is not
collected and just printed out.Signed-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul -
The following command should return actual state of the test.
% cat /sys/kernel/debug/dmatest/runTo wait for test done the user may perform a busy loop that checks the state.
% while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ]
> do
> echo -n "."
> sleep 1
> done
> echoSigned-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul -
Instead of doing
modprobe dmatest ...
modprobe -r dmatest
we allow user to run tests interactively.The dmatest could be built as module or inside kernel. Let's consider those
cases.1. When dmatest is built as a module...
After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest
folder with nodes will be created. They are the same as module parameters with
addition of the 'run' node that controls run and stop phases of the test.Note that in this case test will not run on load automatically.
Example of usage:
% echo dma0chan0 > /sys/kernel/debug/dmatest/channel
% echo 2000 > /sys/kernel/debug/dmatest/timeout
% echo 1 > /sys/kernel/debug/dmatest/iterations
% echo 1 > /sys/kernel/debug/dmatest/runAfter a while you will start to get messages about current status or error like
in the original code.Note that running a new test will stop any in progress test.
2. When built-in in the kernel...
The module parameters that is supplied to the kernel command line will be used
for the first performed test. After user gets a control, the test could be
interrupted or re-run with same or different parameters. For the details see
the above section "1. When dmatest is built as a module..."In both cases the module parameters are used as initial values for the test case.
You always could check them at run-time by running
% grep -H . /sys/module/dmatest/parameters/*Signed-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul