Re: [PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ
On Mon, Jun 1, 2020 at 10:42 PM David Gow wrote: > > Add an FAQ entry to the KUnit documentation with some tips for > troubleshooting KUnit and kunit_tool. > > These suggestions largely came from an email thread: > https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 > > Signed-off-by: David Gow Looks good to me + Alan's suggestion. Reviewed-by: Brendan Higgins
Re: [PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ
On Mon, 1 Jun 2020, David Gow wrote: > Add an FAQ entry to the KUnit documentation with some tips for > troubleshooting KUnit and kunit_tool. > > These suggestions largely came from an email thread: > https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 > > Signed-off-by: David Gow > --- > Documentation/dev-tools/kunit/faq.rst | 32 +++ > 1 file changed, 32 insertions(+) > > diff --git a/Documentation/dev-tools/kunit/faq.rst > b/Documentation/dev-tools/kunit/faq.rst > index ea55b2467653..40109d425988 100644 > --- a/Documentation/dev-tools/kunit/faq.rst > +++ b/Documentation/dev-tools/kunit/faq.rst > @@ -61,3 +61,35 @@ test, or an end-to-end test. >kernel by installing a production configuration of the kernel on production >hardware with a production userspace and then trying to exercise some > behavior >that depends on interactions between the hardware, the kernel, and > userspace. > + > +KUnit isn't working, what should I do? > +== > + > +Unfortunately, there are a number of things which can break, but here are > some > +things to try. > + > +1. Try running ``./tools/testing/kunit/kunit.py run`` with the > ``--raw_output`` > + parameter. This might show details or error messages hidden by the > kunit_tool > + parser. > +2. Instead of running ``kunit.py run``, try running ``kunit.py config``, > + ``kunit.py build``, and ``kunit.py exec`` independently. This can help > track > + down where an issue is occurring. (If you think the parser is at fault, > you > + can run it manually against stdin or a file with ``kunit.py parse``.) > +3. Running the UML kernel directly can often reveal issues or error messages > + kunit_tool ignores. This should be as simple as running ``./vmlinux`` > after > + building the UML kernel (e.g., by using ``kunit.py build``). Note that UML > + has some unusual requirements (such as the host having a tmpfs filesystem > + mounted), and has had issues in the past when built statically and the > host > + has KASLR enabled. (On older host kernels, you may need to run ``setarch > + `uname -m` -R ./vmlinux`` to disable KASLR.) > +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test > + (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config > + around, so you can see what config was used after running ``kunit.py > run``. > + It also preserves any config changes you might make, so you can > + enable/disable things with ``make ARCH=um menuconfig`` or similar, and > then > + re-run kunit_tool. > +5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py > run`` > + may help clean up any residual config items which could be causing > problems. > + Looks great! Could we add something like: 6. Try running kunit standalone (without UML). KUnit and associated tests can be built into a standard kernel or built as a module; doing so allows us to verify test behaviour independent of UML so can be useful to do if running under UML is failing. When tests are built-in they will execute on boot, and modules will automatically execute associated tests when loaded. Test results can be collected from /sys/kernel/debug/kunit//results. For more details see "KUnit on non-UML architectures" in :doc:`usage`. Reviewed-by: Alan Maguire
[PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ
Add an FAQ entry to the KUnit documentation with some tips for troubleshooting KUnit and kunit_tool. These suggestions largely came from an email thread: https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 Signed-off-by: David Gow --- Documentation/dev-tools/kunit/faq.rst | 32 +++ 1 file changed, 32 insertions(+) diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index ea55b2467653..40109d425988 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -61,3 +61,35 @@ test, or an end-to-end test. kernel by installing a production configuration of the kernel on production hardware with a production userspace and then trying to exercise some behavior that depends on interactions between the hardware, the kernel, and userspace. + +KUnit isn't working, what should I do? +== + +Unfortunately, there are a number of things which can break, but here are some +things to try. + +1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output`` + parameter. This might show details or error messages hidden by the kunit_tool + parser. +2. Instead of running ``kunit.py run``, try running ``kunit.py config``, + ``kunit.py build``, and ``kunit.py exec`` independently. This can help track + down where an issue is occurring. (If you think the parser is at fault, you + can run it manually against stdin or a file with ``kunit.py parse``.) +3. Running the UML kernel directly can often reveal issues or error messages + kunit_tool ignores. This should be as simple as running ``./vmlinux`` after + building the UML kernel (e.g., by using ``kunit.py build``). Note that UML + has some unusual requirements (such as the host having a tmpfs filesystem + mounted), and has had issues in the past when built statically and the host + has KASLR enabled. (On older host kernels, you may need to run ``setarch + `uname -m` -R ./vmlinux`` to disable KASLR.) +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test + (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config + around, so you can see what config was used after running ``kunit.py run``. + It also preserves any config changes you might make, so you can + enable/disable things with ``make ARCH=um menuconfig`` or similar, and then + re-run kunit_tool. +5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py run`` + may help clean up any residual config items which could be causing problems. + +If none of the above tricks help, you are always welcome to email any issues to +kunit-...@googlegroups.com. -- 2.27.0.rc2.251.g90737beb825-goog
