Lines Matching full:stable
11 Are you facing a regression with vanilla kernels from the same stable or
13 <https://lore.kernel.org/lkml/>`_ and the `Linux stable mailing list
14 <https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
16 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
17 mailing list (stable@vger.kernel.org) and CC the regressions list
30 supported stable or longterm series as well? Then install its latest release.
101 * If you are facing a regression within a stable or longterm version line
103 'Dealing with regressions within a stable and longterm kernel line'.
118 the latest 'stable' Linux can be an acceptable alternative in some
130 stable and longterm kernels.
168 Reporting regressions within a stable and longterm kernel line
172 the point about regression within a stable or longterm kernel version line. You
183 * Check the archives of the `Linux stable mailing list
184 <https://lore.kernel.org/stable/>`_ for existing reports.
192 * Send a short problem report to the Linux stable mailing list
193 (stable@vger.kernel.org) and CC the Linux regressions mailing list
208 see the issue fixed in a still supported stable or longterm series or vendor
216 within a stable and longterm kernel line" above.
229 as the stable mailing list.
314 with kernels from distributions shipping the latest stable kernel, as long as
317 want to use a mainline Linux and avoid using a stable kernel for this
574 Regression in stable or longterm kernel?
577 *If you are facing a regression within a stable or longterm version line
579 'Dealing with regressions within a stable and longterm kernel line'.*
581 Regression within a stable and longterm kernel version line are something the
775 the latest 'stable' Linux can be an acceptable alternative in some
793 * Install a mainline kernel; the latest stable kernel can be an option, but
831 latest stable version offered on kernel.org. Using that is also acceptable in
836 Better avoid using the latest stable kernel outside merge windows, as all fixes
862 latest mainline or stable Linux built as vanilla kernel. It's totally okay to
866 are older than a week, as new mainline and stable kernels typically get released
929 stable and longterm kernels.*
934 users might still be plagued by it, as long as it's not fixed in either stable
1048 regression in a stable or longterm kernel, avoid testing versions which number
1288 tagging it for later backport to stable and longterm kernels that need it. Then
1464 Reference for "Reporting regressions within a stable and longterm kernel line"
1468 a regression within a stable and longterm kernel line.
1484 Note, if kernel.org lists two stable version lines on the front page, you
1491 Search stable mailing list
1494 *Check the archives of the Linux stable mailing list for existing reports.*
1497 `search the archives of the Linux stable mailing list
1498 <https://lore.kernel.org/stable/>`_ for reports about an issue like yours. If
1529 *Send a short problem report to the Linux stable mailing list
1530 (stable@vger.kernel.org) and CC the Linux regressions mailing list
1537 When reporting a regression that happens within a stable or longterm kernel
1540 stable and regressions mailing list is all it takes; but in case you suspect
1571 version lines (aka stable and longterm kernels).
1581 totally unexpected problems. The maintainers of the stable and longterm kernels
1583 within rules outlined in Documentation/process/stable-kernel-rules.rst.
1586 to mainline. Other fixes are easy to get backported to the newest stable and
1605 * Search the Linux stable mailing list for exiting reports.
1634 'stable tag' that looks like this:
1636 Cc: <stable@vger.kernel.org> # 5.4+
1658 * If the fix doesn't contain a stable tag and backporting was not discussed,
1669 as the stable mailing list.*
1674 for the subsystem as well as the stable mailing list (stable@vger.kernel.org).