English

报告问题

简短指南（又名 TL;DR）

您是否在使用来自同一稳定版或长期支持系列的 vanilla（原生）内核时遇到了回归（regression）问题？且该系列仍受支持？如果是，请搜索 LKML 和 Linux stable 邮件列表存档，寻找匹配的报告并加入讨论。如果没找到，请安装该系列的最新版本。如果问题依然存在，请报告给稳定版邮件列表 (stable@vger.kernel.org) 并抄送 (CC) 回归列表 (regressions@lists.linux.dev)；理想情况下，还应抄送相关子系统的维护者和邮件列表。

在所有其他情况下，请尽力猜测哪个内核部分可能导致了问题。查看 MAINTAINERS 文件，了解开发人员希望如何获知问题，大多数情况下是通过向邮件列表抄送电子邮件。检查目的地的存档以寻找匹配报告；同时搜索 LKML 和网络。如果您没有找到可以加入的讨论，请安装最新的主线 (mainline) 内核。如果问题在其中依然存在，请发送报告。

如果问题在主线版已修复，但您希望在仍受支持的稳定版或长期支持系列中也得到解决？请安装该系列的最新版本。如果问题依然存在，请在主线版中搜索修复该问题的变更，并检查回迁 (backport) 工作是在进行中还是已被放弃；如果两者都不是，请向处理该变更的人员提出请求。

一般备注：按照上述说明安装和测试内核时，请确保它是 vanilla 的（换言之：未打补丁且不使用附加模块）。同时确保它是在健康的运行环境中构建和运行的，并且在问题发生前没有被“污染 (tainted)”。

如果您同时面临多个 Linux 内核问题，请分别报告。编写报告时，请包含所有与问题相关的信息，如所使用的内核和发行版。如果是回归问题，请在报告中抄送回归邮件列表 (regressions@lists.linux.dev)。同时尝试通过二分法 (bisection) 定位罪魁祸首；如果您成功了，请包含其 commit-id 并抄送 sign-off-by 链中的所有人。

报告发出后，请回答出现的任何问题并在力所能及的地方提供帮助。这包括保持关注，偶尔使用较新版本重新测试并随后发送状态更新。

向内核维护者报告问题的逐步指南

上述 TL;DR 大致概述了如何向 Linux 内核开发人员报告问题。对于已经熟悉向自由/开源软件 (FLOSS) 项目报告问题的人来说，这可能就足够了。对于其他人，我们准备了本节内容。它更加详尽并采用逐步指导的方法。为了可读性，它仍然力求简短并省略了许多细节；这些细节在逐步指南下方的参考章节中进行了描述，该章节更详细地解释了每个步骤。

注意：本节涵盖的内容比 TL;DR 稍多，且顺序略有不同。这符合您的利益，可以确保您能及早发现看起来像 Linux 内核问题的问题实际上是否由其他原因引起。因此，这些步骤有助于确保您在此过程中投入的时间最终不会白费。

  • 您是否面临硬件或软件供应商提供的 Linux 内核问题？如果是，在几乎所有情况下，您最好停止阅读本文档，转而向您的供应商报告问题，除非您愿意自己安装最新的 Linux 版本。请注意，为了追踪和修复问题，通常还是需要后者。

  • 使用您喜欢的互联网搜索引擎对现有报告进行大致搜索；此外，检查 Linux 内核邮件列表 (LKML) 的存档。如果您找到匹配的报告，请加入讨论而不是发送新报告。

  • 看看您处理的问题是否符合回归、安全问题或真正严重的严重问题：这些属于“高优先级问题”，在接下来的某些步骤中需要特殊处理。

  • 确保不是内核的周边环境导致了您面临的问题。

  • 创建一份新鲜的备份，并将系统修复和恢复工具准备在手边。

  • 确保您的系统不会通过动态构建额外的内核模块来增强其内核，像 DKMS 这样的解决方案可能会在您不知情的情况下在本地执行此操作。

  • 检查您的内核在问题发生时是否被“污染 (tainted)”，因为导致内核设置此标志的事件可能正是导致您面临问题的原因。

  • 粗略记录如何重现该问题。如果您同时处理多个问题，请为每个问题创建单独的记录，并确保它们在新鲜启动的系统上能独立发生。这是必要的，因为每个问题都需要分别向内核开发人员报告，除非它们具有强耦合性。

  • 如果您在稳定版或长期支持版本系列中遇到回归（例如，从 5.10.4 更新到 5.10.5 时出了问题），请向下滚动到“处理稳定版和长期支持内核系列中的回归问题”。

  • 定位似乎导致问题的驱动程序或内核子系统。查明其开发人员期望如何以及在哪里接收报告。注意：大多数情况下不会是 bugzilla.kernel.org，因为问题通常需要通过邮件发送给维护者和公共邮件列表。

  • 彻底搜索相关 Bug 追踪器或邮件列表的存档，寻找可能与您的问题匹配的报告。如果您发现任何内容，请加入讨论，而不是发送新报告。

完成这些准备工作后，现在您将进入主体部分

  • 除非您已经在运行最新的“主线 (mainline)”Linux 内核，否则最好在报告过程中安装它。在某些情况下，使用最新的“稳定版 (stable)”Linux 进行测试和报告是可以接受的替代方案；在合并窗口期间，这甚至可能是最好的方法，但在那个开发阶段，暂停几天的努力通常是个更好的主意。无论您选择哪个版本，理想情况下请使用“vanilla”构建。忽视所有这些建议将大大增加您的报告被拒绝或忽略的风险。

  • 确保您刚刚安装的内核在运行时不会自我“污染”。

  • 用您刚刚安装的内核重现该问题。如果问题没有出现，请向下滚动查看仅在稳定版和长期支持内核中发生的问题的说明。

  • 优化您的记录：尝试找到并写出重现问题最直接的方法。确保最终结果包含所有重要细节，同时对初次听闻的人来说易于阅读和理解。如果您在此过程中学到了什么，请考虑再次搜索有关该问题的现有报告。

  • 如果您的故障涉及“panic”、“Oops”、“warning”或“BUG”，请考虑解码内核日志以找到触发错误的源代码行。

  • 如果您的问题是回归，请尝试尽可能缩小问题引入的时间范围。

  • 通过编写有关问题的详细描述来开始汇编报告。务必提及几件事：用于重现的最新内核版本、所使用的 Linux 发行版以及关于如何重现问题的记录。理想情况下，将内核的构建配置 (.config) 和 dmesg 的输出发布在网上某处并提供链接。包含或上传可能相关的其他所有信息，如 Oops 的输出/截图或 lspci 的输出。写完这部分主体后，在顶部插入一个正常长度的段落，快速概述问题和影响。在此之上再加一句话，简要描述问题并吸引人们阅读下去。最后给它一个描述性且更简短的标题或主题。然后您就可以按照 MAINTAINERS 文件的指示发送或提交报告了，除非您处理的是“高优先级问题”：它们需要特殊处理，详见下文“高优先级问题的特殊处理”。

  • 等待回应并保持推进，直到您能以某种方式接受结果。因此，请公开且及时地回复任何询问。测试提议的修复程序。进行主动测试：至少在每个新主线版本的第一个候选发布版 (RC) 中进行重新测试并报告结果。如果进展停滞，请发送友好的提醒。如果您没有得到任何帮助或帮助不尽人意，请尝试自助。

报告稳定版和长期支持内核系列中的回归问题

如果您遵循上述流程，并在涉及稳定版或长期支持内核版本系列内的回归点被引导至此，那么本小节适合您。如果您在从 5.10.4 更新到 5.10.5 时出了问题，就属于此类情况（从 5.9.15 切换到 5.10.5 不属于此类）。开发人员希望尽快修复此类回归，因此有一个简化的流程来报告它们

  • 检查内核开发人员是否仍在维护您关心的 Linux 内核版本系列：前往 kernel.org 首页，确保它提到了特定版本系列的最新发布版本，且没有“[EOL]”标签。

  • 检查 Linux stable 邮件列表的存档，查看是否存在现有报告。

  • 将该特定版本系列的最新版本安装为 vanilla 内核。确保该内核未被污染且仍显示该问题，因为该问题可能已在其中修复。如果您最初是通过供应商内核发现问题的，请检查最后一个已知可运行版本的 vanilla 构建是否也运行良好。

  • 向 Linux stable 邮件列表 (stable@vger.kernel.org) 发送一份简短的问题报告，并抄送 Linux 回归邮件列表 (regressions@lists.linux.dev)；如果您怀疑原因在某个特定子系统中，请抄送其维护者和邮件列表。粗略描述问题，理想情况下解释如何重现。提及出现问题的第一个版本和最后一个运行正常的版本。然后等待进一步指示。

下面的参考章节更详细地解释了这些步骤中的每一步。

报告仅在旧版本内核系列中出现的问题

如果您按照上文所述尝试了最新的主线内核，但未能在那里重现您的问题，同时您希望在仍受支持的稳定版、长期支持系列或定期基于这些系列的供应商内核中修复该问题，那么本小节适合您。如果是这种情况，请遵循以下步骤

  • 做好心理准备：接下来的几个步骤可能无法在旧版本中解决问题，因为修复程序可能太大或风险太高而无法回迁。

  • 执行上述“处理稳定版和长期支持内核系列中的回归问题”章节中的前三个步骤。

  • 在 Linux 内核版本控制系统中搜索在主线版中修复该问题的变更，因为其提交消息可能会告诉您该修复是否已计划回迁。如果您以此种方式找不到任何内容，请在适当的邮件列表中搜索讨论此类问题或进行同行评审可能的修复程序的帖子；然后检查讨论，看该修复是否被认为不适合回迁。如果根本没有考虑过回迁，请加入最新的讨论，询问是否在考虑范围内。

  • 前述步骤之一应该会导向一个解决方案。如果行不通，请咨询似乎导致问题的子系统维护者的建议；同时抄送该特定子系统的邮件列表以及稳定版邮件列表。

下面的参考章节更详细地解释了这些步骤中的每一步。

逐步指南结语

您在遵循逐步指南时是否遇到了下文参考章节未能说明的麻烦？您发现了错误吗？或者您有改进指南的想法吗？

如果有以上任何情况，请发送简短说明或补丁给 Thorsten Leemhuis <linux@leemhuis.info> 以告知开发人员，理想情况下请抄送公共 Linux 文档邮件列表 <linux-doc@vger.kernel.org>。此类反馈对于进一步改进此文本至关重要，这符合每个人的利益，因为它将使更多的人能够掌握此处描述的任务。

参考章节：向内核维护者报告问题

上述逐步指南简要概述了所有主要步骤，通常涵盖了所需的一切。但即使是经验丰富的用户，有时也会想知道如何实际实现其中的某些步骤，或者为什么要这样做；还有一些为了可读性而被指南忽略的边缘情况。这就是参考章节中各项条目的用途，它们为指南中的每个步骤提供了补充信息。

几点一般性建议

  • Linux 开发人员深知，向他们报告 Bug 比在其他 FLOSS 项目中更复杂且要求更高。部分原因在于内核不同，其原因包括其邮件驱动的开发流程以及它主要由驱动程序组成。部分原因在于，改进现状需要在多个技术领域开展工作，并需要人员对 Bug 进行分类——而目前还没有人站出来承担或资助这项工作。

  • 与某些供应商签订的保修或支持合同并不赋予您向上游 Linux 开发人员请求修复的权利：此类合同完全超出了上游 Linux 内核及其开发社区以及本文档的范畴——即使处理该问题的人员正为签发合同的供应商工作也是如此。如果您想主张自己的权利，请使用供应商的支持渠道。

  • 如果您以前从未向 FLOSS 项目报告过问题，请考虑浏览诸如 如何提好问题、提问的智慧 以及 如何有效地报告 Bug 等指南。

排除这些因素后，请在下面查看有关向 Linux 内核开发人员报告问题的详细指南中各步骤的详情。

确保您使用的是上游 Linux 内核

您是否面临硬件或软件供应商提供的 Linux 内核问题？如果是，在几乎所有情况下，您最好停止阅读本文档，转而向您的供应商报告问题，除非您愿意自己安装最新的 Linux 版本。请注意，为了追踪和修复问题，通常还是需要后者。

和大多数程序员一样，Linux 内核开发人员不喜欢花时间处理在他们当前代码中根本不会发生的问题报告。这只是在浪费每个人的时间，尤其是您的时间。不幸的是，涉及内核时，这种情况很容易发生，并往往导致双方都感到沮丧。这是因为预装在设备（电脑、笔记本、智能手机、路由器……）上的几乎所有基于 Linux 的内核，以及 Linux 发行商提供的大多数内核，都与 kernel.org 分发的官方 Linux 内核有相当大的距离：这些来自供应商的内核从 Linux 开发的角度来看通常是古老的，或者是经过大量修改的，通常两者兼而有之。

大多数此类供应商内核都非常不适合向 Linux 内核开发人员报告问题：您在其中一个内核中面临的问题可能早在几个月或几年前就被 Linux 内核开发人员修复了；此外，供应商的修改和增强可能是导致您面临问题的原因，即使它们看起来很小或完全无关。这就是为什么您应该向供应商报告这些内核的问题。其开发人员应调查该报告，如果事实证明是上游问题，则直接在上游修复或将报告转发到那里。在实践中，这往往行不通，或者可能不是您想要的。因此，您可能需要考虑绕过供应商，自己安装最新的 Linux 内核核心。如果这对您来说是一个选项，请继续此流程，因为本指南后面的步骤将解释在排除您问题的其他潜在原因后如何执行此操作。

注意，前一段是以“大多数”一词开头的，因为有时开发人员实际上愿意处理供应商内核中发生的问题报告。他们最终是否这样做很大程度上取决于开发人员和所涉及的问题。如果发行商仅对基于近期 Linux 版本的内核应用了少量修改，您的机会就相当大；例如，Debian GNU/Linux Sid 或 Fedora Rawhide 提供的 mainline 内核通常就是这种情况。一些开发人员也会接受有关提供最新稳定版内核的发行版内核的问题报告，只要它只是稍作修改；例如，Arch Linux、普通的 Fedora 发布版和 openSUSE Tumbleweed 通常就是这种情况。但请记住，您最好使用主线 Linux，并避免在此过程中使用稳定版内核，详见“安装新鲜内核进行测试”一节。

显然，您可以自由地忽略所有这些建议，并向上游 Linux 开发人员报告旧版或经过大量修改的供应商内核的问题。但请注意，这些报告经常被拒绝或忽略，因此请视此为警告。但这总比完全不报告问题要好：有时此类报告会直接或间接地帮助问题随着时间的推移得到修复。

搜索现有报告，第一轮

使用您喜欢的互联网搜索引擎对现有报告进行大致搜索；此外，检查 Linux 内核邮件列表 (LKML) 的存档。如果您找到匹配的报告，请加入讨论而不是发送新报告。

报告一个别人已经提出的问题通常是对参与其中的每个人时间的浪费，尤其是作为报告者的您。因此，彻底检查是否已经有人报告了该问题符合您自身的利益。在流程的这一步，只进行大致搜索是可以的：稍后的步骤会告诉您在知道问题需要报告到何处后，再进行更详细的搜索。尽管如此，请不要匆忙完成报告过程的这一步，它可以为您节省时间和麻烦。

首先只需使用您喜欢的搜索引擎搜索互联网。然后，搜索 Linux 内核邮件列表 (LKML) 存档。

如果您被淹没在结果中，请考虑告诉您的搜索引擎将搜索时间范围限制在过去的一个月或一年内。无论您在哪里搜索，都要确保使用好的关键词；也要变换几次关键词。在这样做时，尝试从他人的角度看待问题：这将帮助您想出其他词语作为搜索词。还要确保一次不要使用太多的搜索词。记住在搜索时带上或不带上诸如内核驱动程序名称或受影响硬件组件名称之类的信息。但其确切的品牌名称（例如“ASUS Red Devil Radeon RX 5700 XT Gaming OC”）通常没有太大帮助，因为它太具体了。相反，尝试使用型号系列（Radeon 5700 或 Radeon 5000）和主芯片的代号（“Navi”或“Navi10”）等搜索词，带上或不带上其制造商名称（“AMD”）。

如果您找到了有关您问题的现有报告，请加入讨论，因为您可能能够提供有价值的附加信息。即使修复程序已经准备就绪或已进入最后阶段，这可能也很重要，因为开发人员可能会寻找能够提供额外信息或测试提议修复程序的人员。跳转到“报告发出后的职责”一节，了解如何妥善参与的详细信息。

注意，搜索 bugzilla.kernel.org 也可能是一个好主意，因为那可能会提供有价值的见解或发现匹配的报告。如果您发现后者，请记住：大多数子系统期望在不同的地方接收报告，如“检查您需要向何处报告问题”一节所述。因此，理应处理该问题的开发人员甚至可能都不知道这个 Bugzilla 工单。因此，请检查该工单中是否已按本文档所述报告了该问题，如果没有，请考虑这样做。

是否为高优先级问题？

看看您处理的问题是否符合回归、安全问题或真正严重的严重问题：这些属于“高优先级问题”，在接下来的某些步骤中需要特殊处理。

Linus Torvalds 和领先的 Linux 内核开发人员希望某些问题能尽快得到修复，因此有一些“高优先级问题”在报告过程中会得到略微不同的处理。符合条件的三类情况是：回归、安全问题和真正严重的问题。

如果您在某个 Linux 内核下运行良好的应用程序或实际使用案例，在编译配置相似的较新版本中运行变差或完全无法运行，那么您就遇到了回归问题。文档 报告回归 对此进行了更详细的解释。它还提供了大量关于您可能希望了解的回归问题的其他信息；例如，它解释了如何将您的问题添加到跟踪的回归列表中，以确保它不会被遗漏。

什么算作安全问题由您自行判断。在继续之前，请考虑阅读 安全 Bug，因为它提供了关于如何最好地处理安全问题的更多细节。

当发生完全不可接受的糟糕情况时，该问题就是“真正严重的问题”。例如，当 Linux 内核损坏了它正在处理的数据或损坏了它正在运行的硬件时。当内核突然停止运行并显示错误消息（“kernel panic”）或没有任何告别消息时，您也面临着严重的问题。注意：不要将“panic”（导致内核停止运行的致命错误）与“Oops”（可恢复的错误）混淆，因为在发生后者之后内核仍会继续运行。

确保健康的运行环境

确保不是内核的周边环境导致了您面临的问题。

看起来非常像内核问题的问题有时是由构建或运行时环境引起的。虽然很难完全排除这类问题，但您应该将其降至最低

  • 构建内核时使用经过验证的工具，因为编译器或 binutils 中的 Bug 会导致生成的内核表现异常。

  • 确保您的计算机组件在其设计规范内运行；这对于主处理器、主内存和主板尤为重要。因此，在面临潜在的内核问题时，请停止降压或超频。

  • 尝试确保不是硬件故障导致了您的问题。例如，损坏的主内存可能导致多种问题，这些问题会表现为看起来像内核问题的故障。

  • 如果您正在处理文件系统问题，您可能需要使用 fsck 检查相关文件系统，因为它可能已经损坏，从而导致意外的内核行为。

  • 在处理回归问题时，请确保不是在更新内核的同时发生了其他变化。例如，问题可能是由同时更新的其他软件引起的。也有可能在您第一次重启进入新内核时，某个硬件组件正巧坏了。更新系统 BIOS 或更改 BIOS 设置中的某些内容也可能导致看起来非常像内核回归的问题。

为紧急情况做好准备

创建一份新鲜的备份，并将系统修复和恢复工具准备在手边。

提醒一下，您正在与电脑打交道，它们有时会做出出人意料的事情，特别是当您摆弄其操作系统的内核等关键部分时。这正是您在此过程中要做的。因此，请务必创建一份新鲜的备份；还要确保手边有修理或重新安装操作系统的所有工具，以及恢复备份所需的一切。

确保您的内核没有被“增强”

确保您的系统不会通过动态构建额外的内核模块来增强其内核，像 DKMS 这样的解决方案可能会在您不知情的情况下在本地执行此操作。

如果您的内核以任何方式被“增强”，您的问题报告被忽略或拒绝的风险会大大增加。这就是为什么您应该删除或禁用诸如 akmods 和 DKMS 之类的机制：当您安装新的 Linux 内核或第一次引导它时，它们会自动构建附加内核模块。还要删除它们可能已安装的任何模块。然后在继续之前重新启动。

注意，您可能没意识到您的系统正在使用这些解决方案之一：当您安装 Nvidia 的专有图形驱动程序、VirtualBox 或其他需要不属于 Linux 内核的模块支持的软件时，它们通常会被静默设置。这就是为什么您可能需要卸载带有此类软件的软件包以清除任何第三方内核模块。

检查“污染（taint）”标志

检查您的内核在问题发生时是否被“污染 (tainted)”，因为导致内核设置此标志的事件可能正是导致您面临问题的原因。

当发生某些可能导致看起来完全无关的后续错误的事情时，内核会用“污染 (taint)”标志标记自己。如果您的内核被污染了，您面临的问题可能就是这样一个错误。因此，在投入更多时间到此过程之前，尽早排除这一点符合您的利益。这是此步骤出现在这里的唯一原因，因为此流程稍后会告诉您安装最新的主线内核；届时您将需要再次检查污染标志，因为那是它真正重要的时候，因为那是报告关注的内核。

在运行中的系统上，很容易检查内核是否污染了自己：如果 cat /proc/sys/kernel/tainted 返回“0”，则内核未被污染，一切正常。在某些情况下无法检查该文件；这就是为什么内核在报告内部问题（“kernel bug”）、可恢复错误（“kernel Oops”）或停机前的不可恢复错误（“kernel panic”）时也会提到污染状态。查看出现上述任一情况时打印的错误消息顶部附近，搜索以“CPU:”开头的行。如果内核在注意到问题时未被污染，该行应以“Not tainted”结尾；如果您看到“Tainted:”，后跟几个空格和一些字母，则它已被污染。

如果您的内核被污染了，请研究 受污染的内核 以查明原因。尝试消除原因。通常是由以下三件事之一引起的

  1. 发生了一个可恢复的错误（“kernel Oops”），内核污染了自己，因为内核知道在那之后它可能会以奇怪的方式表现异常。在这种情况下，请检查您的内核或系统日志，并查找以此开头的段落

    Oops: 0000 [#1] SMP

    那是自启动以来的第一次 Oops，如括号间的“#1”所示。在那之后发生的每一次 Oops 和任何其他问题都可能是该次 Oops 的后续问题，即使两者看起来完全无关。通过消除第一次 Oops 的原因并在此后重现问题来排除这种情况。有时仅需重新启动就足够了，有时更改配置并随后重新启动可以消除 Oops。但在此过程的这一点上，不要投入太多时间，因为 Oops 的原因可能已经在您稍后要安装的较新 Linux 内核版本中修复了。

  2. 您的系统使用的软件安装了自己的内核模块，例如 Nvidia 的专有图形驱动程序或 VirtualBox。当内核从外部源加载此类模块时（即使它们是开源的），它会污染自己：它们有时会在无关的内核区域引起错误，从而可能导致您面临的问题。因此，当您想向 Linux 内核开发人员报告问题时，必须防止加载这些模块。通常最简单的方法是：暂时卸载此类软件，包括它们可能已安装的任何模块。随后重新启动。

  3. 当内核加载位于 Linux 内核源代码 staging 树中的模块时，它也会污染自己。那是专门为尚未达到正常 Linux 内核质量标准的内核代码（主要是驱动程序）准备的区域。当您报告此类模块的问题时，内核被污染显然是可以的；只需确保该模块是造成污染的唯一原因即可。如果问题发生在无关区域，请重新启动，并通过指定 foo.blacklist=1 作为内核参数暂时阻止加载该模块（将“foo”替换为相关模块的名称）。

记录如何重现问题

粗略记录如何重现该问题。如果您同时处理多个问题，请为每个问题创建单独的记录，并确保它们在新鲜启动的系统上能独立发生。这是必要的，因为每个问题都需要分别向内核开发人员报告，除非它们具有强耦合性。

如果您同时处理多个问题，则必须分别报告它们，因为它们可能由不同的开发人员处理。在一个报告中描述各种问题也会使其他人很难将其拆解。因此，只有在问题强耦合的情况下才将它们合并到一个报告中。

此外，在报告过程中，您将不得不测试该问题在其他内核版本中是否发生。因此，如果您确切知道如何在新鲜启动的系统上快速重现问题，将使您的工作变得更加轻松。

注意：报告只发生过一次的问题往往是徒劳的，因为它们可能是由于宇宙辐射引起的比特翻转造成的。这就是为什么在进一步操作之前，您应该尝试通过重现问题来排除这种情况。如果您经验丰富，足以区分硬件故障导致的一次性错误与罕见发生、难以重现的内核问题，请随意忽略此建议。

稳定版或长期支持内核中的回归？

如果您在稳定版或长期支持版本系列中遇到回归（例如，从 5.10.4 更新到 5.10.5 时出了问题），请向下滚动到“处理稳定版和长期支持内核系列中的回归问题”。

稳定版和长期支持内核版本系列内的回归是 Linux 开发人员急于修复的问题，因为此类问题比主开发分支中的回归更令人厌烦，因为它们会迅速影响很多人。因此开发人员希望尽快了解此类问题，为此有一个简化的流程来报告它们。注意，较新内核版本系列的回归（例如，从 5.9.15 切换到 5.10.5 时出了问题）不符合此条件。

检查您需要向何处报告问题

定位似乎导致问题的驱动程序或内核子系统。查明其开发人员期望如何以及在哪里接收报告。注意：大多数情况下不会是 bugzilla.kernel.org，因为问题通常需要通过邮件发送给维护者和公共邮件列表。

将报告发送给正确的人至关重要，因为 Linux 内核是一个庞大的项目，大多数开发人员只熟悉其中的一小部分。例如，相当多的程序员只关心一个驱动程序，例如 WiFi 芯片的驱动程序；其开发人员可能对远程或不相关的“子系统”内部结构（如 TCP 栈、PCIe/PCI 子系统、内存管理或文件系统）知之甚少，甚至一无所知。

问题在于：Linux 内核缺乏一个中央 Bug 追踪器，您不能简单地提交问题并让它传达给需要了解它的开发人员。这就是为什么您必须自己找到报告问题的正确位置和方式。您可以借助脚本（见下文）来做到这一点，但它主要针对内核开发人员和专家。对于其他人，MAINTAINERS 文件是更好的地方。

如何阅读 MAINTAINERS 文件

为了说明如何使用 MAINTAINERS 文件，让我们假设您的笔记本电脑上的 WiFi 在更新内核后突然表现异常。在这种情况下，很可能是 WiFi 驱动程序的问题。显然，它也可能是它所基于的一些代码，但除非您怀疑是这类情况，否则请坚持找驱动程序。如果确实是其他问题，驱动程序的开发人员会让合适的人员参与进来。

遗憾的是，没有一种既通用又简单的方法来检查哪段代码正在驱动特定的硬件组件。

如果 WiFi 驱动程序出现问题，您可能需要查看 lspci -k 的输出，因为它列出了 PCI/PCIe 总线上的设备以及驱动它的内核模块

[user@something ~]$ lspci -k
[...]
3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
  Subsystem: Bigfoot Networks, Inc. Device 1535
  Kernel driver in use: ath10k_pci
  Kernel modules: ath10k_pci
[...]

但如果您的 WiFi 芯片是通过 USB 或其他内部总线连接的，这种方法就行不通了。在这种情况下，您可能需要检查您的 WiFi 管理器或 ip link 的输出。查找有问题的网络接口名称，它可能类似于“wlp58s0”。可以使用该名称通过以下方式找到驱动它的模块

[user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
ath10k_pci

如果这些技巧都不能带您进一步深入，请尝试在互联网上搜索如何缩小所涉及的驱动程序或子系统的范围。如果您不确定是哪一个：尽力猜测即可，如果您猜得不好，会有人帮您的。

一旦知道驱动程序或子系统，就需要在 MAINTAINERS 文件中搜索它。在“ath10k_pci”的情况下，您将一无所获，因为名称太具体了。有时您需要在网上搜索帮助；但在那之前，在搜索 MAINTAINERS 文件时尝试使用稍短或修改过的名称，这样您可能会发现如下内容

QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
Mail:          A. Some Human <shuman@example.com>
Mailing list:  ath10k@lists.infradead.org
Status:        Supported
Web-page:      https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
SCM:           git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
Files:         drivers/net/wireless/ath/ath10k/

注意：如果您阅读 Linux 源码树根目录下的纯文本 MAINTAINERS 文件，行描述将是缩写。例如，“Mail:”将是“M:”，“Mailing list:”将是“L”，而“Status:”将是“S:”。该文件顶部附近的一个部分解释了这些缩写和其他缩写。

首先看“Status”行。理想情况下，它应该是“Supported（受支持）”或“Maintained（已维护）”。如果它声明“Obsolete（已废弃）”，那么您正在使用一些已被您需要切换到的更新解决方案取代的过时方法。有时代码只有人在有动力时提供“Odd Fixes（零星修复）”。如果是“Orphan（孤儿）”，那您就彻底没戏了，因为再也没有人管这段代码了。那就只剩这些选择了：设法忍受这个问题、自己修复它，或者在某处找到一个愿意修复它的程序员。

检查状态后，寻找以“bugs:”开头的行：它会告诉您在何处可以找到特定子系统的 Bug 追踪器以提交您的问题。上面的例子中没有这样的行。大多数章节都是如此，因为 Linux 内核开发完全是由邮件驱动的。只有极少数子系统使用 Bug 追踪器，而其中只有一部分依赖于 bugzilla.kernel.org。

在这种和许多其他情况下，您必须寻找以“Mail:”开头的行。这些行提到了特定代码维护者的姓名和电子邮件地址。还要寻找以“Mailing list:”开头的行，它会告诉您开发代码的公共邮件列表。您的报告稍后需要通过邮件发送到这些地址。此外，对于所有通过电子邮件发送的问题报告，请务必在抄送中添加 Linux 内核邮件列表 (LKML) <linux-kernel@vger.kernel.org>。稍后通过邮件发送问题报告时，不要遗漏这两个邮件列表中的任何一个！维护者很忙，可能会将一些工作留给特定子系统列表上的其他开发人员；而 LKML 对于建立一个可以找到所有问题报告的场所非常重要。

在脚本的帮助下查找维护者

对于手边有 Linux 源码的人来说，还有第二种寻找合适报告地点的选择：脚本“scripts/get_maintainer.pl”，它尝试查找所有需要联系的人员。它查询 MAINTAINERS 文件，并需要带有所涉及源代码路径的调用。对于编译为模块的驱动程序，通常可以通过如下命令找到路径

$ modinfo ath10k_pci | grep filename | sed 's!/lib/modules/.*/kernel/!!; s!filename:!!; s!\.ko\(\|\.xz\)!!'
drivers/net/wireless/ath/ath10k/ath10k_pci.ko

将此路径的一部分传递给脚本

$ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k*
Some Human <shuman@example.com> (supporter:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Another S. Human <asomehuman@example.com> (maintainer:NETWORKING DRIVERS)
ath10k@lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)

不要将您的报告发送给所有人。发送给维护者（脚本称之为“supporter:”）；此外，抄送该代码最具体的邮件列表以及 Linux 内核邮件列表 (LKML)。在这种情况下，您需要将报告发送给“Some Human <shuman@example.com>”，并在抄送中包含 ‘ath10k@lists.infradead.org’ 和 ‘linux-kernel@vger.kernel.org’。

注意：如果您使用 git 克隆了 Linux 源代码，您可能想要带上 --git 再次调用 get_maintainer.pl。脚本随后将查看提交历史以找出最近在该代码上工作过的人员，因为他们也许能提供帮助。但请谨慎使用这些结果，因为它很容易将您引向错误的方向。例如，在很少变动的区域（如过时或无人维护的驱动程序）很容易发生这种情况：有时这类代码会在由完全不关心特定驱动程序的开发人员进行的树范围清理期间被修改。

搜索现有报告，第二轮

彻底搜索相关 Bug 追踪器或邮件列表的存档，寻找可能与您的问题匹配的报告。如果您发现任何内容，请加入讨论，而不是发送新报告。

如前所述：报告一个别人已经提出的问题通常是对参与其中的每个人时间的浪费，尤其是作为报告者的您。这就是为什么您应该再次搜索现有报告，既然现在您已经知道它们需要报告到何处。如果是邮件列表，您通常可以在 lore.kernel.org 上找到其存档。

但有些邮件列表托管在其他地方。例如上一步作为例子的 ath10k WiFi 驱动程序。但您通常可以很容易地在网上找到这些列表的存档。例如，搜索“archive ath10k@lists.infradead.org”将带您到 ath10k 邮件列表的信息页面，其顶部链接到它的列表存档。遗憾的是，此列表和相当多其他列表缺少搜索存档的方法。在这种情况下，请使用常规的互联网搜索引擎，并在搜索词中添加类似于“site:lists.infradead.org/pipermail/ath10k/”的内容，这将把结果限制在该 URL 的存档中。

在此时再次检查互联网、LKML 以及可能的 bugzilla.kernel.org 也是明智之举。如果您的报告需要提交到 Bug 追踪器中，您可能还需要检查子系统的邮件列表存档，因为可能有人仅在那里报告过。

有关如何搜索以及发现匹配报告后如何操作的详细信息，请参阅上文“搜索现有报告，第一轮”。

不要匆忙完成报告过程的这一步：花费 30 到 60 分钟甚至更多时间可以为您和他人节省大量的时间和麻烦。

安装新鲜的内核用于测试

除非您已经在运行最新的“主线 (mainline)”Linux 内核，否则最好在报告过程中安装它。在某些情况下，使用最新的“稳定版 (stable)”Linux 进行测试和报告是可以接受的替代方案；在合并窗口期间，这甚至可能是最好的方法，但在那个开发阶段，暂停几天的努力通常是个更好的主意。无论您选择哪个版本，理想情况下请使用“vanilla”构建。忽视所有这些建议将大大增加您的报告被拒绝或忽略的风险。

正如在第一步的详细解释中已经提到的：和大多数程序员一样，Linux 内核开发人员不喜欢花时间处理在当前代码中根本不会发生的问题报告。这只是在浪费每个人的时间，尤其是您的时间。这就是为什么在报告之前确认问题在最新的上游代码中仍然存在符合每个人的利益。您可以自由地忽略此建议，但如前所述：这样做会大大增加您的问题报告被拒绝或干脆被忽略的风险。

在内核范畴内，“最新上游”通常意味着

  • 安装一个主线内核；最新的稳定版内核可以是一个选项，但在大多数情况下最好避开。在此过程的这一点上，长期支持内核（有时称为“LTS 内核”）是不合适的。下一小节将更详细地解释所有这些内容。

  • 再下一小节描述了获取和安装此类内核的方法。它还概述了使用预编译内核是可以的，但最好是 vanilla 内核，这意味着：它是使用直接从 kernel.org 获取且未经过任何修改或增强的 Linux 源代码构建的。

选择正确的版本进行测试

前往 kernel.org 以查明您想用于测试的版本。忽略显示“Latest release”的大黄色按钮，向下看表格。在顶部您会看到以 mainline 开头的一行，大多数时候它会指向一个版本号类似于“5.8-rc2”的预发布版本。如果是这种情况，您将需要使用此主线内核进行测试，因为那是所有修复程序必须首先应用的地方。不要让那个“rc”吓到您，这些“开发内核”相当可靠——而且您已经按指示做了备份，不是吗？

在每九到十周中大约有两周，主线可能会指向版本号类似于“5.7”的正式发布版本。如果是这样，请考虑暂停报告过程，直到下一个版本的第一个预发布版 (5.8-rc1) 出现在 kernel.org 上。这是因为 Linux 开发周期此时正处于为期两周的“合并窗口”中。大部分更改和所有侵入性的更改都会在此期间为下一个版本合并。在此期间使用主线内核风险稍大。内核开发人员在此期间通常也非常忙碌，可能没有空闲时间处理问题报告。此外，合并窗口期间应用的许多更改之一很可能会修复您面临的问题；这就是为什么您很快就不得不使用更新的内核版本重新测试的原因，详见下文“报告发出后的职责”一节。

这就是为什么等待合并窗口结束可能是有意义的。但如果您处理的是刻不容缓的事情，请不要那样做。在这种情况下，考虑通过 git（见下文）获取最新的主线内核，或者使用 kernel.org 上提供的最新稳定版本。如果您由于某种原因目前无法使用主线内核，使用该版本也是可以接受的。总的来说：使用它来重现问题也比完全不报告问题要好。

除非在合并窗口期间，否则最好避免使用最新的稳定版内核，因为所有修复必须首先应用到主线。这就是检查最新主线内核如此重要的原因：任何您希望在旧版本系列中得到修复的问题都必须首先在主线中修复，然后才能被回迁，这可能需要几天或几周的时间。另一个原因：您所期待的修复可能对于回迁来说太难或太冒险；因此再次报告该问题不太可能改变任何事情。

这些方面也是长期支持内核（有时称为“LTS 内核”）不适合报告过程这一部分的原因：它们与当前代码距离太远。因此，请先测试主线版并进一步遵循流程：如果主线版不出现问题，它将指导您如何（如果修复方案允许的话）在旧版本系列中修复它。

如何获取新鲜的 Linux 内核

使用预编译内核：这通常是测试最快、最简单且最安全的方法——特别是如果您不熟悉 Linux 内核。问题在于：大多数由发行商或附加仓库分发的内核都是从修改过的 Linux 源码构建的。因此它们不是 vanilla 的，因而不适合进行测试和问题报告：这些修改可能会导致或影响您面临的问题。

但如果您使用的是流行的 Linux 发行版，那么您很幸运：对于其中的不少发行版，您可以在网上找到包含以 vanilla 内核构建的最新主线或稳定版 Linux 软件包的仓库。使用这些仓库是完全没问题的，只需从仓库的描述中确保它们是 vanilla 的或至少接近 vanilla 的。此外，确保这些软件包包含 kernel.org 上提供的最新版本。如果软件包的时间超过一周，它们可能就不合适了，因为新的主线和稳定版内核通常每周至少发布一次。

请注意，您稍后可能需要手动构建自己的内核：正如本文档后面所述，调试或测试修复程序有时需要这样做。还要注意，预编译的内核可能缺少解码内核在发生 panic、Oops、warning 或 BUG 时打印的消息所需的调试符号；如果您计划解码这些消息，您最好自己编译内核（详见本小节末尾和名为“解码失败消息”的章节）。

使用 git：熟悉 git 的开发人员和资深 Linux 用户最好直接从 kernel.org 上的官方开发仓库获取最新的 Linux 内核源代码。这些源代码可能比最新的主线预发布版领先一点。不用担心：它们和正式的预发布版一样可靠，除非内核的开发周期正处于合并窗口中期。但即便如此，它们也相当可靠。

常规方法：不熟悉 git 的人最好从 kernel.org 下载 tar 包形式的源码。

这里不描述如何实际构建内核，因为许多网站已经解释了必要的步骤。如果您是新手，请考虑遵循其中一个建议使用 make localmodconfig 的教程，因为该命令会尝试获取当前内核的配置，然后尝试针对您的系统进行一些调整。这不会使生成的内核变得更好，但编译起来会更快。

注意：如果您正在处理来自内核的 panic、Oops、warning 或 BUG，请在配置内核时尝试启用 CONFIG_KALLSYMS。此外，也要启用 CONFIG_DEBUG_KERNEL 和 CONFIG_DEBUG_INFO；后者是这两个选项中相关的那个，但只有启用前者后才能访问它。请注意，CONFIG_DEBUG_INFO 会大幅增加构建内核所需的存储空间。但这是值得的，因为这些选项稍后将允许您精确指出触发您问题的代码行。“解码失败消息”章节下文对此进行了更详细的解释。

但请记住：如果问题难以重现，请务必保留遇到的问题的记录。发送未解码的报告也比完全不报告问题要好。

检查“污染（taint）”标志

确保您刚刚安装的内核在运行时不会自我“污染”。

如上文已详细说明的：当发生可能导致看起来完全无关的后续错误的事情时，内核会设置“污染 (taint)”标志。这就是为什么您需要检查您刚刚安装的内核是否没有设置此标志。如果设置了，在几乎所有情况下，您都需要在报告随之发生的问题之前消除原因。有关如何操作的详情，请参阅上文章节。

用新鲜内核重现问题

用您刚刚安装的内核重现该问题。如果问题没有出现，请向下滚动查看仅在稳定版和长期支持内核中发生的问题的说明。

检查问题是否在您刚刚安装的新鲜 Linux 内核版本中发生。如果已经在那里修复了，请考虑坚持使用该版本系列并放弃报告问题的计划。但请记住，只要它在 kernel.org 的稳定版和长期支持版本中（以及由此衍生的供应商内核中）没有得到修复，其他用户可能仍会受到其困扰。如果您更喜欢使用其中之一，或者只是想帮助他们的用户，请前往下文“关于报告仅在旧版本内核系列中出现的问题的详情”一节。

优化重现问题的描述

优化您的记录：尝试找到并写出重现问题最直接的方法。确保最终结果包含所有重要细节，同时对初次听闻的人来说易于阅读和理解。如果您在此过程中学到了什么，请考虑再次搜索有关该问题的现有报告。

不必要的复杂报告会使他人难以理解。因此，尝试找到一种描述起来直截了当、从而易于以书面形式理解的重现方法。包含所有重要的细节，但同时尽量保持简短。

在这一步和之前的步骤中，您可能已经对所面临的问题有了一些了解。利用这些知识再次搜索您可以加入的现有报告。

解码失败消息

如果您的故障涉及“panic”、“Oops”、“warning”或“BUG”，请考虑解码内核日志以找到触发错误的源代码行。

当内核检测到内部问题时，它会记录一些关于执行代码的信息。这使得精确定位源代码中触发问题的确切行并显示它是如何被调用的成为可能。但这只有在您配置内核时启用了 CONFIG_DEBUG_INFO 和 CONFIG_KALLSYMS 的情况下才有效。如果您已经启用，请考虑解码内核日志中的信息。这将使理解导致“panic”、“Oops”、“warning”或“BUG”的原因变得容易得多，从而增加了有人能提供修复方案的机会。

可以使用您在 Linux 源码树中找到的一个脚本来完成解码。如果您运行的是您之前自己编译的内核，请如下调用它

[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux

如果您运行的是打包的 vanilla 内核，您可能需要安装带有调试符号的相应软件包。然后调用脚本（如果您的发行版没有打包该脚本，您可能需要从 Linux 源码中获取），如下所示

[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \
 /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/

该脚本将处理如下日志行，这些行显示了发生错误时内核正在执行的代码地址

[   68.387301] RIP: 0010:test_module_init+0x5/0xffa [test_module]

一旦解码，这些行将如下所示

[   68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:16) test_module

在这种情况下，执行的代码是由文件“~/linux-5.10.5/test-module/test-module.c”构建的，错误发生在第“16”行的指令中。

该脚本将类似地解码以“Call trace”开头的部分提到的地址，这些地址显示了通往发生问题的函数的路径。此外，该脚本将显示内核正在执行的代码段的汇编输出。

注意，如果您无法让此脚本工作，只需跳过此步骤并在报告中提及原因即可。如果幸运的话，可能不需要它。如果需要，有人可能会帮您运行起来。还要注意，这只是解码内核堆栈轨迹的几种方法之一。有时需要不同的步骤来检索相关细节。不用担心，如果情况确实需要，开发人员会告诉您该怎么做。

对回归问题的特别关注

如果您的问题是回归，请尝试尽可能缩小问题引入的时间范围。

Linux 首席开发人员 Linus Torvalds 坚持认为 Linux 内核绝不能倒退，这就是为什么他认为回归是不可接受的，并希望看到它们被迅速修复。这就是为什么如果引入回归的更改引起的问题无法迅速以其他方式解决，该更改通常会被立即撤销。因此，报告回归问题有点像打出一张王牌，以快速获得修复。但为了实现这一点，需要知道导致回归的更改。通常由报告者负责找出罪魁祸首，因为维护者往往没有时间或手头没有环境来自己重现它。

为了找到该项更改，有一个被称为“二分 (bisection)”的过程，文档 二分定位回归问题 对此有详细描述。该过程通常需要您构建大约十到二十个内核镜像，并在构建下一个之前尝试用每个镜像重现该问题。是的，这需要一些时间，但别担心，它的工作速度比大多数人想象的要快得多。多亏了“二分查找”，这将引导您找到源代码管理系统中导致回归的那次提交。一旦找到它，在网上搜索该变更的主题、它的 commit id 和缩短的 commit id（commit id 的前 12 个字符）。如果有现成的报告，这将引导您找到它们。

注意，二分定位需要一点并非每个人都具备的专门知识，以及相当一部分并非每个人都愿意投入的精力。尽管如此，强烈建议您自己进行二分。如果您确实不能或不想走那条路，至少要查明是哪个主线内核引入了回归。例如，如果从 5.5.15 切换到 5.8.4 时出了问题，那么至少尝试该范围内的所有主线发布版本（5.6、5.7 和 5.8），以检查它最初出现的时间。除非您试图在稳定版或长期支持内核中寻找回归，否则请避免测试版本号包含三个部分的版本（5.6.12、5.7.8），因为这会使结果难以解释，从而可能使您的测试变得徒劳。一旦您找到了引入回归的主版本号，请随意继续报告过程。但请记住：在不知道罪魁祸首的情况下，开发人员是否能够提供帮助取决于手头的问题。有时他们可能会从报告中识别出哪里出了错并能修复它；有时除非您进行二分，否则他们将无法提供帮助。

在处理回归问题时，请确保您面临的问题确实是由内核引起的，而不是由其他原因引起的，如上所述。

在整个过程中请记住：只有当旧内核和新内核是使用相似配置构建的时，问题才符合回归条件。这可以通过使用 make olddefconfig 来实现，详见 报告回归；该文档还提供了大量关于您可能希望了解的回归问题的其他信息。

编写并发送报告

首先通过编写问题的详细描述来开始编写报告。务必提到以下几点：你为了重现问题而安装的最新内核版本、所使用的 Linux 发行版，以及关于如何重现该问题的笔记。理想情况下，请将内核的编译配置 (.config) 和 ``dmesg`` 的输出上传到网络上的某个地方并提供链接。包含或上传所有其他可能相关的信息，例如 Oops 的输出/截图或 ``lspci`` 的输出。写完这个主要部分后，在顶部插入一段普通长度的文字，快速概述问题及其影响。在此基础上，再增加一句话简要描述问题并吸引人们继续阅读。最后，给它一个描述性的标题或主题，且字数要短。然后，你就可以按照 MAINTAINERS 文件告诉你的那样发送或提交报告了，除非你正在处理那些“高优先级问题”：它们需要特殊处理，具体在下文的“高优先级问题的特殊处理”中说明。

既然你已经准备好了一切，现在是时候编写报告了。如何编写报告在上面前言中链接的三个文档中已有部分解释。因此，本文将只提及一些要点以及 Linux 内核特有的事项。

有一点同时适用于这两个类别：报告中最重要的部分是标题/主题、第一句话和第一段。开发人员通常会收到大量的邮件。因此，他们通常只花几秒钟浏览一下邮件，然后决定是继续处理还是仔细查看。因此：报告的开头部分写得越好，有人研究并帮助你的机会就越高。这就是为什么你应该暂时忽略它们，先写详细报告的原因。;-)

每份报告应提及的事项

详细描述你安装的新原生（vanilla）内核中是如何出现问题的。尽量包含你之前编写并优化的分步说明，概述你以及理想情况下其他人如何重现该问题；在那些极少数无法重现的情况下，尝试描述你做了什么触发了它。

还应包含其他人理解该问题及其环境可能需要的所有相关信息。实际需要什么在很大程度上取决于问题，但有一些内容是你应该始终包含的

  • cat /proc/version 的输出，其中包含 Linux 内核版本号和构建它的编译器。

  • 机器运行的 Linux 发行版（hostnamectl | grep "Operating System"）

  • CPU 和操作系统的架构（uname -mi）

  • 如果你正在处理回归问题并执行了二分查找（bisect），请提及导致该问题的更改的主题和 commit-id。

在很多情况下，向阅读报告的人提供另外两样东西也是明智的

  • 用于构建 Linux 内核的配置（“.config”文件）

  • 将从 dmesg 获取的内核消息写入文件。确保它以类似 “Linux version 5.8-1 (foobar@example.com) (gcc (GCC) 10.2.1, GNU ld version 2.34) #1 SMP Mon Aug 3 14:54:37 UTC 2020” 的行开头。如果缺少这一行，说明第一阶段启动的重要消息已经丢失。在这种情况下，请考虑使用 journalctl -b 0 -k；或者，你也可以重新启动，重现问题，并在之后立即调用 dmesg。

这两个文件很大，因此直接将它们放入报告中不是个好主意。如果你是在错误跟踪系统中提交问题，请将它们作为附件添加到工单中。如果你通过邮件报告问题，请不要附加它们，因为这会使邮件过大；相反，请执行以下操作之一

  • 将文件上传到公共场所（你的网站、公共文件粘贴服务、专门为此目的在 bugzilla.kernel.org 上创建的工单等），并在报告中包含指向它们的链接。理想情况下，请使用文件可以保存多年的平台，因为多年后这些文件可能对某些人有用；例如，五到十年后，开发人员可能会处理为了修复你的问题而更改的代码。

  • 把文件放在一边，并说明你稍后会在回复自己的邮件时单独发送。只是要记得在报告发出后真的去执行这个操作。;-)

提供这些信息可能是明智的

根据问题的不同，你可能需要添加更多背景数据。以下是一些通常建议提供的内容

  • 如果你正在处理内核的“warning”、“OOPS”或“panic”，请将其包含在内。如果你无法复制粘贴，请尝试捕获 netconsole 追踪，或者至少拍一张屏幕照片。

  • 如果问题可能与你的计算机硬件有关，请提及你使用的是哪种系统。例如，如果你的显卡有问题，请提及制造商、型号以及使用的芯片。如果是笔记本电脑，请提及它的名称，但要确保名称是有意义的。例如，“Dell XPS 13”就没有意义，因为它可能是 2012 年那款；那款看起来与今天销售的那款没什么不同，但除此之外两者没有任何共同点。因此，在这种情况下，请添加确切的型号，例如 2019 年推出的 XPS 13 型号是“9380”或“7390”。像“Lenovo Thinkpad T590”这样的名称也有点模糊：这款笔记本电脑有带独立显卡芯片和不带独立显卡芯片的版本，因此请尝试查找确切的型号名称或指定主要组件。

  • 提及相关的在用软件。如果你在加载模块时遇到问题，你需要提及使用的 kmod、systemd 和 udev 版本。如果其中一个 DRM 驱动程序运行异常，你需要说明 libdrm 和 Mesa 的版本；同时指明你的 Wayland 合成器或 X-Server 及其驱动程序。如果你遇到文件系统问题，请提及相应文件系统工具（e2fsprogs, btrfs-progs, xfsprogs, ...）的版本。

  • 从内核收集其他可能感兴趣的信息。例如，lspci -nn 的输出将帮助他人识别你使用的硬件。如果你的硬件有问题，你甚至可能需要提供 sudo lspci -vvv 的输出，因为这可以让你深入了解组件是如何配置的。对于某些问题，包含 /proc/cpuinfo、/proc/ioports、/proc/iomem、/proc/modules 或 /proc/scsi/scsi 等文件的内容可能会更好。某些子系统还提供收集相关信息的工具。其中一个工具是 alsa-info.sh，由音频/声音子系统开发人员提供。

这些例子应该能给你一些关于哪些数据值得附上的想法，但你必须自己思考什么信息对他人有帮助。不要太担心遗漏了什么，因为开发人员会询问他们需要的额外细节。但从一开始就提供所有重要的信息，可以增加有人仔细查看的机会。

重要部分：报告的头部

现在你已经准备好了报告的详细部分，让我们来看看最重要的部分：前几句话。因此，请回到顶部，在你刚写完的部分之前添加类似“详细描述：”的内容，并在顶部插入两个换行符。现在写一个普通长度的段落，粗略地描述该问题。省去所有无聊的细节，专注于读者需要了解的关键部分，以理解这是怎么回事；如果你认为这个错误影响了大量用户，请提及这一点以引起人们的兴趣。

完成之后，在顶部再插入两行，并写一个句子的总结，快速解释报告的内容。之后，你必须更加抽象，为报告写一个更短的主题/标题。

写完这部分后，花点时间优化它，因为它是报告中最重要的部分：很多人在决定阅读剩余部分是否值得之前，只会阅读这部分。

现在，按照 MAINTAINERS 文件的指示发送或提交报告，除非它是前面概述的“高优先级问题”之一：在这种情况下，请在发送报告之前先阅读下一小节。

高优先级问题的特殊处理

高优先级问题的报告需要特殊处理。

严重问题：确保主题或工单标题以及第一段能体现出严重性。

回归（Regressions）：让报告的主题以“[REGRESSION]”开头。

如果你成功执行了二分查找，请使用引入回归的更改的标题作为主题的第二部分。报告中还要提到罪魁祸首的 commit id。如果二分查找不成功，请在报告中提到最后一个测试正常工作的版本（如 5.7）和出现问题的最早版本（如 5.8-rc1）。

通过邮件发送报告时，抄送 Linux 回归邮件列表（regressions@lists.linux.dev）。如果报告需要提交到某些 Web 跟踪器，请照做。提交后，通过邮件将报告转发到回归列表；抄送相关子系统的维护者和邮件列表。确保将转发的报告正文内联，不要将其作为附件。此外，在顶部添加简短说明，提及工单的 URL。

发送或转发报告时，如果二分查找成功，请将罪魁祸首的作者添加到收件人中；同时抄送其 commit 消息末尾的 signed-off-by 链中的所有人。

安全问题：对于这些问题，你需要评估如果详细信息公开，是否会对其他用户产生短期风险。如果不是这种情况，只需按所述方式报告问题即可。对于带有此类风险的问题，你需要稍微调整报告流程

  • 如果 MAINTAINERS 文件指示你通过邮件报告问题，请不要抄送任何公共邮件列表。

  • 如果你应该在错误跟踪器中提交问题，请确保将工单标记为“私有”或“安全问题”。如果错误跟踪器不提供将报告设为私有的方法，请忽略它，改为向维护者发送私密邮件报告。

在上述两种情况下，请务必将你的报告也发送到 MAINTAINERS 文件“security contact”（安全联系人）部分列出的地址。理想情况下，通过邮件发送报告时直接抄送他们。如果你是在错误跟踪器中提交的，请将报告的文本转发到这些地址；但在顶部附上一张小纸条，提到你提交了该报告并附上指向工单的链接。

更多信息请参阅 安全漏洞。

报告发出后的职责

等待回应并保持推进，直到您能以某种方式接受结果。因此，请公开且及时地回复任何询问。测试提议的修复程序。进行主动测试：至少在每个新主线版本的第一个候选发布版 (RC) 中进行重新测试并报告结果。如果进展停滞，请发送友好的提醒。如果您没有得到任何帮助或帮助不尽人意，请尝试自助。

如果你的报告写得很好，而且你真的很幸运，那么其中一位开发人员可能会立即发现导致问题的原因；然后他们可能会编写一个补丁来修复它，进行测试，并直接将其发送到主线进行集成，同时将其标记为稍后向后移植到需要的稳定版和长期维护版内核。那么你所需要做的就是回复一句“非常感谢”，并在修复程序发布后切换到包含该修复程序的版本。

但这种理想情况很少发生。这就是为什么工作在报告发出后才刚刚开始。你需要做些什么取决于具体情况，但通常是下面列出的事情。但在深入了解细节之前，关于流程的这部分，你需要牢记一些重要事项。

后续互动的通用建议

始终在公开场合回复：当你在错误跟踪器中提交问题时，请始终在那里回复，不要私下联系任何开发人员。对于通过邮件发送的报告，回复收到的任何邮件时请始终使用“全部回复”功能。这包括包含你可能想要添加到报告中的任何附加数据的邮件：转到邮件应用程序的“已发送”文件夹，并对包含报告的邮件使用“全部回复”。这种方法将确保公共邮件列表和随着时间的推移参与其中的其他所有人都知情；它还保持了邮件线程的完整性，这对于邮件列表将所有相关邮件分组在一起非常重要。

只有两种情况不适合在错误跟踪器中评论或“全部回复”

  • 有人告诉你要私下发送某些东西。

  • 你被告知要发送某些东西，但注意到它包含需要保密的敏感信息。在这种情况下，可以私下将其发送给要求的开发人员。但在工单或邮件中注明你已经这样做，以便其他人都知道你履行了请求。

在寻求澄清或帮助之前进行研究：在流程的这一部分，可能会有人告诉你要做一些你尚未掌握技能的事情。例如，你可能被要求使用一些你从未听说过的测试工具；或者你可能被要求将补丁应用到 Linux 内核源代码以测试它是否有帮助。在某些情况下，发送一封询问如何执行此操作的回复是可以的。但在走这条路之前，试着通过搜索互联网自己找到答案；或者，考虑在其他地方征求意见。例如，问一个朋友，或者在平时常去的聊天室或论坛发帖询问。

要有耐心：如果你真的很幸运，你可能会在几小时内收到对报告的答复。但大多数情况下需要更长的时间，因为维护者分散在全球各地，因此可能处于不同的时区——在这个时区，他们已经离开了键盘享受夜晚。

一般来说，内核开发人员需要一到五个工作日来响应报告。有时需要更长的时间，因为他们可能正忙于合并窗口、其他工作、参加开发人员会议，或者只是在享受漫长的暑假。

“高优先级问题”（解释见上文）在这里是个例外：维护者应尽快处理它们；这就是为什么你在发送友好提醒之前最多等待一周（如果很紧急则只需两天）。

有时维护者可能没有及时回应；其他时候可能会有分歧，例如一个问题是否属于回归。在这种情况下，在邮件列表上提出你的疑虑，并询问其他人公开或私下回复如何继续。如果失败了，让更高层级的权威介入可能是合适的。如果是 WiFi 驱动程序的问题，那就是无线维护者；如果没有更高级别的维护者或一切尝试都失败了，这可能是少数几种可以让 Linus Torvalds 介入的情况之一。

主动测试：每当发布新的主线内核版本的第一个预发布版（“rc1”）时，去检查问题是否在那里得到修复，或者是否有任何重要的变化。在工单中或在你作为报告回复发送的邮件中提及结果（确保抄送截至当时参与讨论的所有人）。这将显示你的承诺以及你愿意提供帮助的态度。它还告诉开发人员问题是否仍然存在，并确保他们不会忘记它。偶尔进行其他一些重新测试（例如 rc3、rc5 和最终版本）也是个好主意，但只有在发生相关更改或你正在撰写其他内容时才报告结果。

处理完这些通用事务后，让我们深入了解报告发出后如何帮助解决问题的细节。

询问和测试请求

如果你收到报告的回复，你的职责如下

确认你在与谁打交道：大多数情况下，响应你报告的将是特定代码区域的维护者或开发人员。但由于问题通常是在公开场合报告的，回复的可能是任何人——包括那些想提供帮助，但最终可能会由于他们的问题或要求而让你完全走偏的人。这种情况很少发生，但它是通过互联网快速搜索看看你在与谁互动的众多原因之一。通过这样做，你还可以意识到你的报告是否被正确的人听到，如果讨论逐渐平息且没有产生令人满意的解决方案，稍后可能需要提醒维护者（见下文）。

数据查询：通常你会收到测试某些内容或提供额外细节的请求。尽量尽快提供所请求的信息，因为你已经引起了可能提供帮助的人的注意，等待的时间越长，就有失去这种关注的风险；如果你在几个工作日内没有提供信息，即使失去了关注也很有可能。

测试请求：当你被要求测试诊断补丁或可能的修复程序时，也要尝试及时测试。但要妥善处理，确保不要匆忙：混淆事情很容易发生，并可能导致参与其中的每个人产生很多困惑。例如，一个常见的错误是认为应用了提议的带有修复的补丁，但实际上并没有。即使是经验丰富的测试人员偶尔也会发生这类事情，但大多数情况下，当带有修复的内核表现得和没有修复的内核完全一样时，他们会注意到。

当没有任何实质性进展时该怎么办

有些报告不会得到负责的 Linux 内核开发人员的任何反应；或者围绕该问题的讨论已经展开，但逐渐平息，没有产生任何实质性的结果。

在这种情况下，请等待两周（最好是三周），然后发送一封友好的提醒：也许当你的报告到达时，维护者刚好离开键盘一段时间，或者有更重要的事情要处理。写提醒时，请询问是否需要你提供其他任何东西来使事情运作起来。如果报告是通过邮件发出的，请在回复初始邮件（见上文）的邮件前几行中进行，并在下方包含原始报告的全额引用：这是少数几种“TOFU”（Text Over, Fullquote Under，正文在上，全文引用在下）是正确方法的情况之一，因为这样所有收件人都能立即按照正确的顺序掌握详细信息。

提醒之后，再等三周看是否有回复。如果你仍然没有得到适当的反应，你首先应该重新考虑你的方法。你是不是找错人了？报告是不是具有冒犯性，或者太混乱以至于人们决定完全避开它？排除此类因素的最佳方法是：将报告展示给一两个熟悉 FLOSS 问题报告的人，并征求他们的意见。还要征求他们关于如何推进的建议。这可能意味着：准备一份更好的报告，并在发送之前让这些人进行审查。这种方法完全没问题；只需提及这是关于该问题的第二份改进报告，并附上第一份报告的链接即可。

如果报告本身是妥当的，你可以发送第二次提醒；在其中询问为什么报告没有得到任何答复的建议。发送这封第二次提醒邮件的一个好时机是在新的 Linux 内核版本的第一个预发布版（“rc1”）发布后不久，因为届时你无论如何都应该重新测试并提供状态更新（见上文）。

如果第二次提醒在一周内仍未收到任何反应，请尝试联系更高级别的维护者寻求建议：即使是忙碌的维护者，到那时也至少应该发送某种确认。

记住要做好失望的准备：维护者理想情况下应该对每个问题报告做出某种反应，但他们只义务修复前面概述的那些“高优先级问题”。因此，如果你收到类似“感谢报告，我现在有更重要的问题要处理，在可预见的未来没有时间研究这个问题”的答复，不要太沮丧。

在错误跟踪器或列表上进行一些讨论后，也有可能再也没有任何进展，提醒也无法激励任何人制定修复方案。这种情况可能令人沮丧，但在 Linux 内核开发方面是有可能的。本文末尾的“为什么有些问题在报告后没有得到任何反应或仍未修复”中解释了这一点以及未能获得帮助的其他几个原因。

如果你找不到任何帮助，或者问题最终没有得到解决，不要感到沮丧：Linux 内核是 FLOSS（自由开源软件），因此你仍然可以自救。例如，你可以尝试寻找受影响的其他用户，并与他们合作解决问题。这样的团队可以共同准备一份新的报告，提及有多少人受影响，以及为什么在你看来这是应该修复的问题。也许你们可以一起缩小根本原因或引入回归的更改，这通常会使开发修复程序变得更容易。运气好的话，团队中可能会有人懂一点编程，并能够编写修复程序。

“报告稳定版和长期维护版内核系列中的回归”参考

本小节提供了如果你在稳定版和长期维护版内核系列中面临回归时需要执行的步骤的详细信息。

确保特定版本系列仍受支持

检查内核开发人员是否仍在维护你关心的 Linux 内核版本系列：转到 kernel.org 首页，确保它提到的该特定版本系列的最新版本没有带有“[EOL]”标记。

大多数内核版本系列只支持大约三个月，因为维护更长时间的工作量很大。因此，每年只有一个版本被选中并获得至少两年（通常是六年）的支持。这就是为什么你需要检查内核开发人员是否仍然支持你关心的版本系列。

请注意，如果 kernel.org 在首页列出了两个稳定版本系列，你应该考虑切换到较新的版本，忘掉较旧的版本：对旧版本的支持很可能很快就会停止。到那时它将被盖上“end-of-life”（生命周期结束，EOL）印章。达到该点的版本系列仍会在 kernel.org 首页上提及一两周，但不适合测试和报告。

搜索稳定版邮件列表

检查 Linux 稳定版邮件列表的存档中是否有现有的报告。

也许你面临的问题已经众所周知并且已经修复或即将修复。因此，请搜索 Linux 稳定版邮件列表的存档，查找有关像你这样问题的报告。如果你发现任何匹配项，请考虑加入讨论，除非修复程序已经完成并计划很快应用。

使用最新版本重现问题

将该特定版本系列的最新版本安装为 vanilla 内核。确保该内核未被污染且仍显示该问题，因为该问题可能已在其中修复。如果您最初是通过供应商内核发现问题的，请检查最后一个已知可运行版本的 vanilla 构建是否也运行良好。

在投入更多时间到此流程之前，你需要检查问题是否已在你感兴趣的版本系列的最新版本中修复。该内核必须是原生（vanilla）的，并且在问题发生之前不应带有 tainted（污染）标记，具体细节已在上面的“安装新鲜内核进行测试”一节中概述。

你是否首先通过厂商内核注意到了回归？那么厂商应用的更改可能会产生干扰。你需要通过执行重新检查来排除这种情况。假设当你从 5.10.4-vendor.42 更新到 5.10.5-vendor.43 时某些东西坏了。那么，在按照上一段所述测试最新的 5.10 版本后，检查原生构建的 Linux 5.10.4 是否也能正常工作。如果那里也坏了，该问题就不属于上游回归，你需要切回主要的逐步指南来报告该问题。

报告回归

向 Linux 稳定版邮件列表 (stable@vger.kernel.org) 发送一份简短的问题报告，并抄送 Linux 回归邮件列表 (regressions@lists.linux.dev)；如果你怀疑原因是特定的子系统，请抄送其维护者及其邮件列表。粗略描述问题，并理想地解释如何重现它。提及出现问题的第一个版本和最后一个正常工作的版本。然后等待进一步的指示。

当报告发生在稳定版或长期维护版内核系列中的回归（例如从 5.10.4 更新到 5.10.5 时）时，一份简短的报告足以快速完成问题报告。因此，向稳定版和回归邮件列表进行粗略描述就足够了；但如果你怀疑原因是某个特定子系统，也请抄送其维护者及其邮件列表，因为这会加快进度。

请注意，如果你能指定引入问题的确切版本，对开发人员会有很大帮助。因此，如果能在合理的时间范围内完成，请尝试使用原生内核找到该版本。假设当你的发行商发布从 Linux 内核 5.10.5 到 5.10.8 的更新时某些东西坏了。那么，按照上面的指示去检查该版本系列的最新内核，例如 5.10.9。如果它显示有问题，请尝试原生 5.10.5，以确保发行商应用的补丁没有干扰。如果问题在那里没有表现出来，请尝试 5.10.7，然后（根据结果）尝试 5.10.8 或 5.10.6，以找到出现问题的第一个版本。在报告中提及它，并声明 5.10.9 仍然存在问题。

上一段概述的内容基本上是粗略的手动“二分查找”。一旦你的报告发出，你可能会被要求做一个适当的二分查找，因为它可以精确定位导致问题的确切更改（然后可以轻松撤销以快速修复问题）。因此，如果时间允许，请考虑立即执行适当的二分查找。有关如何执行此操作的详细信息，请参阅“回归问题的特别护理”部分和文档 二分查找回归。如果二分查找成功，请将罪魁祸首的作者添加到收件人中；同时抄送其 commit 消息末尾的 signed-off-by 链中的所有人。

“报告仅在旧内核版本系列中发生的问题”参考

本节提供了如果你无法使用主线内核重现问题，但希望在旧版本系列（即稳定版和长期维护版内核）中看到它被修复时需要采取的步骤的详细信息。

有些修复过于复杂

做好心理准备：接下来的几个步骤可能无法在旧版本中解决问题，因为修复程序可能太大或风险太高而无法回迁。

即使是微小且看似明显的代码更改有时也会引入新的、完全意想不到的问题。稳定版和长期维护版内核的维护者对此非常清楚，因此仅对这些内核应用符合 关于 Linux -stable 版本你所想知道的一切 中概述的规则的更改。

例如，复杂或有风险的更改不符合条件，因此仅应用于主线。其他修复很容易被向后移植到最新的稳定版和长期维护版内核，但集成到旧版本内核中的风险太大。因此请意识到，你希望得到的修复可能是那些不会向后移植到你关心的版本系列的修复之一。在这种情况下，除了忍受该问题或切换到更新的 Linux 版本外，你别无选择，除非你想自己将修复补丁应用到你的内核中。

共同准备工作

执行上面“报告仅在旧内核版本系列中发生的问题”部分的前三个步骤。

你需要执行本指南另一部分中已经描述的几个步骤。这些步骤将让你

  • 检查内核开发人员是否仍在维护你关心的 Linux 内核版本系列。

  • 在 Linux 稳定版邮件列表中搜索现有的报告。

  • 使用最新版本进行检查。

检查代码历史并搜索现有讨论

在 Linux 内核版本控制系统中搜索在主线版中修复该问题的变更，因为其提交消息可能会告诉您该修复是否已计划回迁。如果您以此种方式找不到任何内容，请在适当的邮件列表中搜索讨论此类问题或进行同行评审可能的修复程序的帖子；然后检查讨论，看该修复是否被认为不适合回迁。如果根本没有考虑过回迁，请加入最新的讨论，询问是否在考虑范围内。

在很多情况下，你处理的问题可能发生在主线版本中，但已在那里得到修复。修复它的 commit 也需要向后移植才能解决问题。这就是为什么你需要搜索它或任何围绕它的讨论。

  • 首先尝试在保存 Linux 内核源代码的 Git 仓库中找到修复程序。你可以通过 kernel.org 上的 Web 界面或其在 GitHub 上的镜像来完成此操作；如果你有本地克隆，也可以使用命令行搜索：git log --grep=<pattern>。

    如果你找到了修复程序，请查看 commit 消息末尾附近是否包含类似这样的“stable tag”（稳定版标签）

    如果是这种情况，说明开发人员已将该修复程序标记为可以安全地向后移植到 5.4 及更高版本系列。大多数情况下，它会在两周内在那里应用，但有时需要更长的时间。

  • 如果 commit 没有告诉任何信息，或者你找不到修复程序，请再次查找关于该问题的讨论。使用你最喜欢的互联网搜索引擎搜索网络，以及 Linux 内核开发人员邮件列表的存档。此外，请阅读上面的“定位导致问题的内核区域”部分，并按照指示找到相关子系统：其错误跟踪器或邮件列表存档可能包含你正在寻找的答案。

  • 如果你看到了一个提议的修复程序，请如上所述在版本控制系统中搜索它，因为 commit 可能会告诉你是否可以预期向后移植。

    • 检查讨论中是否有任何迹象表明该修复程序风险太大，无法向后移植到你关心的版本系列。如果是这种情况，你必须忍受该问题或切换到已应用修复程序的内核版本系列。

    • 如果修复程序不包含稳定版标签且未讨论向后移植，请加入讨论：提及你面临该问题的版本，并说明你希望看到它被修复（如果合适的话）。

寻求建议

前述步骤之一应该会导向一个解决方案。如果行不通，请咨询似乎导致问题的子系统维护者的建议；同时抄送该特定子系统的邮件列表以及稳定版邮件列表。

如果前三个步骤没有让你更接近解决方案，那么只剩下一个选择：寻求建议。给你认为问题根源所在的子系统维护者发送邮件；同时抄送该子系统的邮件列表以及稳定版邮件列表 (stable@vger.kernel.org)。

附录：为什么报告内核错误有些困难

Linux 内核开发人员非常清楚，向他们报告错误比在其他自由/开源软件项目中更困难。其中的许多原因在于内核的性质、Linux 的开发模型以及世界如何使用内核

  • 大多数 Linux 发行版的内核完全不适合向上游报告错误。 上面的参考部分已经详细解释了这一点：过时的代码库以及修改和附加组件导致的内核错误，在上游很久以前就已经修复了，或者根本从未发生过。其他开源软件的开发人员也面临这些问题，但内核的情况要糟糕得多，因为更改及其影响要严重得多——这就是为什么许多内核开发人员希望得到使用新鲜且几乎未修改的源代码构建的内核报告的原因。

  • 错误通常只发生在特殊环境中。 那是因为 Linux 大部分是驱动程序，并且可以以多种方式使用。开发人员通常手头没有匹配的设置——因此经常必须依靠错误报告者来隔离问题的原因并测试提议的修复程序。

  • 内核有数百名维护者，但全才非常罕见。 这又是由于功能和驱动程序繁多造成的后果，许多内核开发人员对与其代码相关的较低层或较高层了解甚少，对其他领域更是知之甚少。

  • 很难找到向哪里报告问题，原因之一是缺乏中央错误跟踪系统。 这甚至是某些内核开发人员也不喜欢的事情，但这就是目前每个人都必须面对的情况。

  • 稳定版和长期维护版内核主要由专门的“稳定版团队”维护，该团队仅处理稳定版和长期维护版系列中引入的回归。 因此，当有人使用 Linux 6.1.2 报告错误时，团队总是会询问主线版本是否受影响：如果错误已经在 6.1 中发生，或者在最新的主线（例如 6.2-rc3）中发生，为了大家的利益，他们会将其转交给常规开发人员，因为那些人最了解代码。

  • Linux 开发人员可以自由地专注于最新的主线版本。 因此，一些人对关于 Linux 6.0 中错误的报告反应冷淡，而此时 6.1 已经发布；一旦 6.2-rc1 发布，即使是 6.1 可能也不够。一些人也不会非常欢迎关于 6.1.5 或 6.1.6 的报告，因为该问题可能是稳定版团队（见上文）导致的特定系列的回归，必须由他们修复。

  • 有时没有人能提供帮助。 有时是因为缺乏硬件文档——例如，当一个驱动程序是使用反向工程构建的，或者是当硬件制造商放弃它后由业余开发人员接管时。其他时候甚至没有人可以报告错误：当维护者离开而没有继任者时，他们的代码只要有用，通常就会留在内核中。

这些方面中的一些可以得到改进，以促进错误报告——许多 Linux 内核开发人员都非常清楚这一点，并且如果有一些个人或实体将此作为他们的使命，他们会很高兴。