iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use the kernel source tree’s documented kselftest targets to build and execute Linux kernel selftests: run make headers, build with make -C tools/testing/selftests, and start the suite with make -C tools/testing/selftests run_tests. For a combined build-and-run operation, use make kselftest. Select only the groups you need with TARGETS, exclude groups with SKIP_TARGETS, and add FORCE_TARGETS=1 when a partial build must not be accepted as success.
kselftest is a collection of small userspace tests in tools/testing/selftests/. They exercise individual kernel code paths, but applicability depends on the kernel configuration and execution environment. Some tests require root privileges, and the normal workflow is to build, install, and boot the kernel you intend to test before running the suite. The commands and runner behavior below follow the official Linux kernel selftest guide; check the guide in the kernel tree you are testing because targets and settings can vary by revision.
What kselftest tests—and what it does not promise
Linux kernel selftests are maintained under tools/testing/selftests/ in the kernel source tree. Unlike an in-kernel test harness, the tests run as userspace processes and exercise selected kernel interfaces and code paths. The suite is therefore an integration check against a running system: the kernel configuration, loaded modules, permissions, CPU and memory topology, and other environmental details can determine whether a test is applicable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The official documentation generally expects you to build the tests after building the kernel, install and boot that kernel, and then run the tests on the booted system. “The suite ran” is not the same as “every kernel feature was validated.” A test can be unavailable for the current configuration, skipped because a prerequisite is absent, or require privileges that the invoking account does not have.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application:Upgraded attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Warranty & Support: Our Electric air duster comes with 5 years warranty and 24/7 customer service. During this period, if you have any questions,pls kindly feel free to contact us.
- Source location:
tools/testing/selftests/in the kernel source tree. - Execution model: userspace processes interacting with the kernel.
- Privileges: some tests require root; others can run as an ordinary user.
- Coverage: controlled by the selected targets and by what the kernel configuration and environment support.
For the authoritative target names, configuration notes, and runner behavior for a particular release, use the corresponding version of the kernel documentation.
Prepare the kernel tree and test environment
Run the commands from the root of the kernel source tree. If you have separate source and output directories, use the same output arrangement consistently for the kernel and selftests; the build system supports an output directory through O= or KBUILD_OUTPUT, described later.
Start with the kernel you intend to exercise
Selftests are most meaningful when they are built from, and run against, the kernel revision you plan to boot. Build and install that kernel using your normal kernel workflow, reboot into it, and confirm that the resulting system has the devices, filesystems, namespaces, modules, and permissions needed by the selected tests. The selftest guide does not claim that every test works on every configuration.
Check privileges before choosing tests
Keep an account with the required administrative privileges available. Tests that manipulate privileged kernel interfaces can fail or be skipped when run without root. Do not assume that launching the aggregate target as root makes an unsupported test applicable: configuration and environment requirements still govern the result.
Read the selected test’s own requirements
Configuration is test-specific. Before narrowing a run to a subsystem, inspect that subsystem’s documentation and any configuration file in its test directory. Those files identify kernel options or other prerequisites that the generic build commands cannot infer for you.
Build and run the complete in-tree suite
The official basic sequence is three commands from the kernel source root:
make headers
make -C tools/testing/selftests
make -C tools/testing/selftests run_testsThe first command prepares the exported headers needed by the selftest build. The second builds the tests. The third invokes the in-tree runner. If you want the documented combined target instead, use:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteRank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
make kselftestmake kselftest is convenient for a normal full-suite attempt, while the three-command sequence makes the preparation, compilation, and execution stages visible. Whichever form you choose, a successful make invocation does not establish that every test was built or applicable. Aggregate behavior can allow a build to proceed when only part of the requested set builds unless you enable strict target checking.
What to expect during execution
The runner starts individual tests as userspace processes. Some tests finish quickly; others depend on hardware, kernel features, or operations such as CPU or memory offlining. Read the per-test result information rather than treating the final make exit status as a complete coverage report. For a machine-readable or repeatable workflow, retain the output and the separate result files produced by the runner.
Configure tests that need particular kernel options
There is no single configuration switch that enables every selftest. Requirements vary by directory and by test. The documentation recommends adding a configuration file in a test directory when a test needs specific kernel configuration options, then following that test’s instructions.
Module-based tests
The guide’s module workflow is an example for tests that rely on modules, not a universal recipe. In that pattern, use make kselftest-merge to merge the required selftest configuration, build the modules, install them into the test kernel’s module tree, and then invoke the selected selftest target. The exact kernel build, module installation, and target commands depend on your tree and the test directory’s documentation.
Recommended Free Tools
- Open the selected test directory and identify its configuration file and module requirements.
- Apply the documented configuration, using
make kselftest-mergewhere the module workflow calls for it. - Rebuild the kernel or modules as required by that configuration.
- Install the resulting modules and boot the kernel that contains the matching configuration.
- Build and run only the target whose prerequisites you have satisfied.
Do not copy the module example to unrelated tests without checking their own instructions. A test may require a configuration option but no module, or may depend on a runtime facility that cannot be enabled merely by merging a config fragment.
Run selected groups instead of the full suite
Use the TARGETS make variable to limit a build and run to one or more selftest groups. For example, the official guide shows a ptrace-only run:
make -C tools/testing/selftests TARGETS=ptrace run_testsYou can also select multiple groups with the combined target:
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
make TARGETS='size timers' kselftestSelection reduces unrelated work and makes failures easier to attribute, but it does not bypass a selected test’s configuration or privilege requirements. Check the target’s documentation before interpreting a failure as a kernel defect.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsExclude groups with SKIP_TARGETS
SKIP_TARGETS excludes named groups from an otherwise broader invocation. This is useful when you want the aggregate suite but need to omit a known-inapplicable subsystem, a test that requires unavailable hardware, or a disruptive class of tests. Keep the exclusion visible in CI configuration and run notes: an aggregate result with skipped targets is not equivalent to a full-suite result.
Require every selected target to build
By default, the aggregate build can succeed when at least one target builds successfully, even if another selected target did not. Set FORCE_TARGETS=1 when every target named in TARGETS must build:
make FORCE_TARGETS=1 TARGETS=ptrace kselftestThis option is particularly important in continuous integration. Without it, a green aggregate build can conceal missing coverage because an unavailable or failed target did not prevent the remaining targets from building.
Keep build output separate and request summaries
The kernel build system supports placing selftest output outside the source tree. Supply an output directory with O=, or set KBUILD_OUTPUT in the environment. If both are supplied, O= takes precedence.
make O=/var/tmp/kernel-selftest-out kselftestUse a directory appropriate for your build permissions and storage policy. Keeping generated files separate makes it easier to reuse a clean source checkout, compare builds, or remove test artifacts without deleting source files.
To request summary output from the combined target, add summary=1:
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
make summary=1 kselftestThe summary is an overview; detailed individual result files are written separately. Preserve both when diagnosing a failure or publishing CI artifacts. A summary can tell you which tests need attention, while the per-test files provide the detail needed to distinguish a failure, skip, timeout, or environment limitation.
Install the tests and run them outside the source tree
For a target machine, a lab image, or a packaged test artifact, install the selftests rather than keeping the source checkout on the execution host:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →make -C tools/testing/selftests installThe command uses the documented default installation location. Set INSTALL_PATH to choose another destination:
make -C tools/testing/selftests INSTALL_PATH=/var/tmp/kselftest installThe installed directory contains run_kselftest.sh, the standalone runner. From that directory:
./run_kselftest.sh -l-l lists available tests. Use -c to select collections and -t to select individual tests. This lets you deploy one test bundle and choose the scope at execution time instead of rebuilding the source tree for every run.
Package a subset for another machine
The selftest build supports packaging with:
make -C tools/testing/selftests gen_tarSet TARGETS with gen_tar when the package should contain only selected groups. Build and package against the kernel revision and configuration that the destination machine will run; an installed bundle does not remove runtime prerequisites or privilege requirements.
Free tools Windows power users keep installed
One-click scans. No signup required.
Understand timeouts and hotplug tests
Per-test timeout
The kselftest documentation specifies a default timeout of 45 seconds per test. A test can override that value in its settings file, and the runner supports a command-line timeout override. Treat a timeout as a diagnostic signal rather than automatic proof of a kernel regression: a slow virtual machine, unavailable resource, or blocked hotplug operation can produce the same symptom.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
CPU and memory hotplug
Ordinary hotplug tests run in a limited, safer mode according to the guide. Separate hotplug and run_hotplug targets exercise the full range. Those tests can wait for CPU or memory offlining and may hang in some environments, so schedule them only where changing online CPU or memory state is acceptable and recovery is understood.
make -C tools/testing/selftests hotplug
make -C tools/testing/selftests run_hotplugCheck the selected kernel tree’s guide and the test settings for the exact behavior of your revision before enabling the full hotplug targets. Do not combine them casually with production workloads that depend on a fixed CPU or memory topology.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose an execution workflow
The following choices are documented workflow differences, not performance comparisons.
| Decision | Option A | Option B | When to choose |
|---|---|---|---|
| Scope | Full aggregate suite | TARGETS selection or SKIP_TARGETS exclusions |
Use the full suite for broad validation; select or exclude groups for focused debugging and known environmental limits. |
| Execution location | In-tree run_tests |
Installed run_kselftest.sh or a generated tar package |
Use in-tree runs while developing; install or package when the test host should be separate from the source checkout. |
| Build strictness | Default aggregate behavior | FORCE_TARGETS=1 |
Use the default for exploratory work; use forced target coverage in CI when any selected build failure must fail the job. |
| Output placement | Source-tree output | O= or KBUILD_OUTPUT |
Keep output in-tree for a quick local run; use a separate directory for repeatable or disposable builds. |
| Result detail | Normal runner output | summary=1 plus individual result files |
Use summaries for a quick overview and retain result files for diagnosis and archival. |
| Hotplug coverage | Ordinary limited/safe hotplug behavior | hotplug and run_hotplug full-range targets |
Use the full targets only on systems where CPU or memory offlining is safe and expected. |
Repeatable recipes
Local smoke run after booting a test kernel
- Change to the root of the matching kernel source tree.
- Boot the kernel revision and configuration you intend to test.
- Run
make headers. - Build with
make -C tools/testing/selftests. - Run with
make -C tools/testing/selftests run_tests. - Review individual results and investigate skips or failures against the selected test’s requirements.
Focused ptrace investigation
- Confirm that the running kernel and userspace provide the ptrace-related prerequisites documented for the target.
- Build and run only that group with
make -C tools/testing/selftests TARGETS=ptrace run_tests. - If this run is part of CI, add
FORCE_TARGETS=1to the make invocation so an incomplete target build cannot appear complete. - Save the per-test output and the kernel configuration used for the run.
Build a deployable bundle
- Build the selected groups with
TARGETSfrom the source tree. - Generate an archive with
make -C tools/testing/selftests gen_tar. - Copy the archive to a machine running the matching test kernel.
- Extract it, enter the installed directory, and use
./run_kselftest.sh -lto verify the available tests. - Use
-cfor collections or-tfor individual tests, supplying the privileges and environment those tests require.
Troubleshoot common outcomes
| Symptom | Likely interpretation | Next action |
|---|---|---|
| The build stops before tests start. | Headers, source-tree state, compiler inputs, or a selected test prerequisite may be missing. | Run the documented header preparation, inspect the selected test directory’s requirements, and rebuild the affected target. |
| The aggregate build succeeds but a target is absent. | Default aggregate behavior can succeed when at least one target builds. | Repeat with FORCE_TARGETS=1 and treat any selected target that cannot build as a coverage failure. |
| A test is skipped or reports that it is not applicable. | The running kernel configuration or environment does not provide the test’s prerequisite. | Read the target’s configuration file and documentation; enable the required option, provide the required environment, or record the exclusion explicitly. |
| A test fails only for an unprivileged account. | The test needs root privileges or another restricted kernel operation. | Run it with the required administrative privileges, then compare the result with an unprivileged run only if that distinction is relevant to your test plan. |
| A test reaches the 45-second default timeout. | The operation may be genuinely slow, blocked by the environment, or waiting on a resource such as hotplug state. | Inspect the test settings, use the runner’s documented timeout override when justified, and investigate the environment before labeling it a kernel failure. |
| Hotplug execution appears to hang. | Full hotplug tests can wait for CPU or memory offlining and may hang in some environments. | Stop using the full hotplug target on that host, review the selected tree’s hotplug guidance, and reserve those tests for a controlled machine. |
| The installed runner cannot find an expected test. | The package may contain only selected TARGETS, or the installed files may not match the source revision you expected. |
Run ./run_kselftest.sh -l, verify the package contents, and regenerate the installation or tar archive with the intended target selection. |
Interpret results without overstating coverage
A complete-looking command line is not a complete test claim. The meaningful scope is the intersection of three things: what you selected, what successfully built, and what the running kernel and environment could execute. Record the target list, any SKIP_TARGETS exclusions, whether FORCE_TARGETS=1 was used, the kernel configuration, privilege level, and any hotplug restrictions alongside the results.
When reporting CI status, distinguish at least these outcomes:
- Built and passed: the selected test executed and reported success.
- Built and failed: the test ran but reported a failure that needs investigation.
- Skipped or not applicable: a prerequisite was unavailable; this is not equivalent to a pass.
- Not built: the target was unavailable or failed to compile; without
FORCE_TARGETS=1, an aggregate job may still look successful. - Timed out or hung: the operation exceeded its allowed time or stopped making progress; inspect the environment and test settings.
This classification prevents a partial, environment-limited run from being presented as full kernel validation. The official kselftest documentation remains the reference for target names, runner options, configuration files, and revision-specific behavior.
A practical default for developers and CI
For an interactive developer run, start with the three basic commands, then narrow to a TARGETS group when a failure needs isolation. For CI, use a separate output directory, select the groups that your machine can support, enable FORCE_TARGETS=1, request summary=1, and archive the detailed result files. Install or package the suite when tests execute on a dedicated host rather than in the source checkout. Reserve the full hotplug targets for controlled systems, and document every configuration, privilege, exclusion, timeout, and unavailable target with the result.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
