Free tools Windows power users keep installed
One-click scans. No signup required.
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
To report a Linux kernel regression, confirm that the same use case worked on an older kernel, record the last working and first failing versions, and send a concise report with [REGRESSION] in the subject to regressions@lists.linux.dev. Compare kernels built with similar configurations, search for an existing report, and add a regzbot tracking command so the issue can be followed.
What counts as a Linux kernel regression?
The Linux kernel documentation defines a regression as an application or practical use case that worked with one kernel but works worse or stops working with a newer kernel built using a similar configuration. The definition concerns interfaces the kernel provides to userland; it does not cover kernel-internal interfaces used by externally developed modules. Performance or power changes count when they are significant, not merely a negligible benchmark fluctuation. See the kernel regression reporting guide.
A useful comparison is between a last-known-good kernel and a first-known-bad kernel running the same workload. If you are compiling kernels, use the older kernel’s configuration as a base for the newer one and run make olddefconfig. With precompiled kernels, configuration differences may muddy the comparison; ask the kernel provider if you cannot establish that the builds are comparable.
Recommended Free Tools
Before filing: verify and narrow down the problem
Confirm the version range
Write down the newest kernel version on which the behavior worked and the oldest version on which it failed. “It broke after an update” is not enough to distinguish a new regression from a problem that was already present. Include the application or practical task affected and describe what changed in observable terms.
#1 Best Overall
Check for an existing report
Search the regression reporting guide’s linked resources, the regressions mailing-list archives, and regzbot’s interface for an existing report. If one already describes the same failure, add useful information to that conversation rather than starting a duplicate.
Reproduce on comparable kernels and bisect if feasible
Try to reproduce the issue on the relevant versions with comparable configurations. When feasible, use kernel bisection to identify the change that introduced it. The kernel’s bug verification and bisection guide explains how to set up kernels for investigating bugs and regressions. A culprit commit is valuable evidence, but it is not a prerequisite for reporting.
Rank #2
How to write and route the report
- Use a clear subject. Begin the subject with
[REGRESSION], followed by a short description of the affected behavior. - Send it to the right people. Copy
regressions@lists.linux.dev. Include the relevant subsystem mailing list and maintainer when known. For a regression in a stable or longterm kernel series, also copystable@vger.kernel.org. - State the evidence. Give the last working and first failing kernel versions, the practical impact, the steps or conditions that reproduce the issue, and relevant configuration details. If you bisected it, include the identified commit and copy the recipients in that commit’s
Signed-off-by:lines. - Link related material. Include any existing discussion or bug-tracker report. If the issue began in a bug tracker, forward it to the regressions list while copying the relevant maintainer and subsystem list.
- Request tracking. Add a standalone regzbot command, for example
#regzbot introduced: vX..vY, replacing the range with the actual versions. If you know the culprit commit, identify it instead. This optional, recommended command lets regzbot track the issue and include it in reports.
For a report with no known culprit, the version range should express the last known-good and first affected releases. The regression reporting guide documents the reporting conventions and regzbot command syntax at docs.kernel.org/admin-guide/reporting-regressions.html.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesExample report outline
Subject: [REGRESSION] <short description>
To: relevant maintainer and subsystem list
Cc: regressions@lists.linux.dev
Last known-good kernel: <version>
First affected kernel: <version>
Configuration: <how the builds were compared>
Impact: <what no longer works or got significantly worse>
Reproduction: <steps or conditions>
Bisection: <culprit commit, if identified>
#regzbot introduced: <last-good-version>..<first-affected-version>Replace the example text with actual details; do not send a report that leaves the version range or behavior ambiguous.
What developers should do with a report
If a regression report reaches a developer without the regressions list copied, the developer should bring the list into the conversation. Reports that begin in bug trackers should be forwarded to the list. A developer can ask regzbot to track the parent report using a reply command such as #regzbot ^introduced: ...; the caret tells the bot that the parent message is the issue to track. The reporting guide describes the reporter-side workflow, while Handling regressions covers developer responsibilities.
Connect the fix to the report and cause
When submitting a fix, developers should include a Closes: tag linking to the report and a Fixes: tag identifying the offending commit. If the culprit entered an earlier development cycle and the correction should be backported, add Cc: stable@vger.kernel.org. These tags help maintainers, distributions, and tracking tools connect the report, cause, and resolution.
Understand the time expectations
The kernel documentation says most regressions should be fixed within two weeks, while recognizing that timing depends on impact, age, and kernel series. Its handling guidance also says users ideally should not have to remain on an outdated, potentially insecure kernel for more than three weeks after the cause is identified—and preferably for less than two. These are expectations, not guaranteed deadlines; severe or widespread breakage calls for faster action. See the regression handling guidance.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →If the regression is in a stable or longterm kernel
Make clear which series and version are affected. Copy stable@vger.kernel.org in addition to the regressions list, and include the same last-good/first-bad range and reproduction details as for a mainline issue. If bisection identifies a change, provide its commit information and copy the commit’s Signed-off-by: recipients. The reporting route is described in the official reporting guide.
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.
