报告问题¶
简短指南（又名 TL;DR）¶
您是否在同一稳定或长期系列的原始内核中遇到回归？仍然支持吗？然后搜索 LKML 和 Linux 稳定邮件列表 存档，以查找匹配的报告并加入。如果您没有找到任何匹配的报告，请安装 该系列的最新版本。如果它仍然显示问题，请将其报告给稳定邮件列表（stable@vger.kernel.org）并抄送回归列表（regressions@lists.linux.dev）；理想情况下，也抄送相关子系统的维护者和邮件列表。
在所有其他情况下，请尽力猜测哪个内核部分可能导致了问题。查看 MAINTAINERS 文件，了解其开发人员希望如何被告知问题，大多数情况下是通过电子邮件并抄送邮件列表。检查目标的存档中是否有匹配的报告；也搜索 LKML 和网络。如果您没有找到任何要加入的报告，请安装 最新的主线内核。如果该问题在那里出现，请发送报告。
该问题在那里已修复，但您也希望在仍然支持的稳定或长期系列中看到它得到解决？然后安装其最新版本。如果它显示问题，请搜索在主线中修复它的更改，并检查是否正在进行或已放弃反向移植；如果两者都不是，请向处理该更改的人员询问。
一般说明：当按照上述说明安装和测试内核时，请确保它是原始的（即：没有打补丁，也没有使用附加模块）。还要确保它是在健康的环境中构建和运行的，并且在问题发生之前没有被污染。
如果您同时面临 Linux 内核的多个问题，请分别报告每个问题。在编写报告时，请包含与问题相关的所有信息，例如所使用的内核和发行版。如果发生回归，请将回归邮件列表（regressions@lists.linux.dev）抄送到您的报告中。还要尝试通过二分法找出罪魁祸首；如果成功，请包含其提交 ID 并抄送签名者链中的所有人。
报告发出后，请回答出现的任何问题，并在力所能及的范围内提供帮助。这包括通过偶尔使用较新版本进行重新测试并在之后发送状态更新来保持进展。
如何向内核维护者报告问题的逐步指南¶
上面的 TL;DR 大致概述了如何向 Linux 内核开发人员报告问题。对于那些已经熟悉向自由/开放源代码软件（FLOSS）项目报告问题的人来说，这可能就足够了。对于其他人，请参考本节。它更详细，并使用逐步方法。为了可读性，它仍然尝试保持简洁，并省略了很多细节；这些细节在逐步指南下方的参考部分中进行说明，其中更详细地解释了每个步骤。
注意：本节涵盖的方面比 TL;DR 多一些，并且执行操作的顺序略有不同。这是为了您的利益，以确保您尽早注意到看起来像是 Linux 内核问题的实际上是由其他原因引起的。因此，这些步骤有助于确保您在此过程中投入的时间最终不会感到浪费。
您是否在硬件或软件供应商提供的 Linux 内核中遇到问题？那么在几乎所有情况下，您最好停止阅读本文档，而是向您的供应商报告该问题，除非您愿意自己安装最新的 Linux 版本。请注意，无论如何，通常都需要后者来查找和修复问题。
使用您喜欢的互联网搜索引擎对现有报告进行粗略搜索；此外，检查 Linux 内核邮件列表（LKML）的存档。如果您发现匹配的报告，请加入讨论，而不是发送新的报告。
查看您正在处理的问题是否符合回归、安全问题或真正严重的问题：这些是“高优先级问题”，需要在接下来的某些步骤中进行特殊处理。
确保导致您面临问题的不是内核的周围环境。
创建新的备份，并准备好系统修复和还原工具。
确保您的系统不会通过动态构建额外的内核模块来增强其内核，而 DKMS 之类的解决方案可能会在您不知情的情况下在本地执行此操作。
检查问题发生时您的内核是否被“污染”，因为导致内核设置此标志的事件可能导致您面临的问题。
粗略地记下如何重现问题。如果您同时处理多个问题，请为每个问题创建单独的笔记，并确保它们可以在新启动的系统上独立工作。这是必要的，因为每个问题都需要分别报告给内核开发人员，除非它们紧密纠缠在一起。
如果您在稳定或长期版本系列中遇到回归（例如，从 5.10.4 更新到 5.10.5 时某些内容损坏），请向下滚动到“处理稳定和长期内核系列中的回归”。
找到似乎导致问题的驱动程序或内核子系统。查明其开发人员希望如何以及在何处接收报告。注意：大多数情况下，这不是 bugzilla.kernel.org，因为问题通常需要通过邮件发送给维护者和公共邮件列表。
彻底搜索相关错误跟踪器或邮件列表的存档，查找可能与您的问题匹配的报告。如果您找到任何内容，请加入讨论，而不是发送新的报告。
在这些准备工作之后，您现在将进入主要部分
除非您已经在运行最新的“主线”Linux 内核，否则最好去安装它以进行报告过程。在某些情况下，使用最新的“稳定”Linux 进行测试和报告是可接受的替代方案；在合并窗口期间，实际上可能甚至是最好的方法，但在该开发阶段，暂停您的工作几天可能是一个更好的主意。无论您选择哪个版本，理想情况下都使用“原始”构建。忽略这些建议会大大增加您的报告被拒绝或被忽略的风险。
确保您刚安装的内核在运行时不会“污染”自己。
使用您刚安装的内核重现该问题。如果它在那里没有显示出来，请向下滚动到仅在稳定和长期内核中发生的问题的说明。
优化您的笔记：尝试找到并编写重现问题的最直接的方法。确保最终结果具有所有重要细节，同时对于第一次听说它的人来说易于阅读和理解。如果您在此过程中学到了什么，请考虑再次搜索有关该问题的现有报告。
如果您的故障涉及“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 稳定邮件列表的存档中查找现有的报告。
安装特定版本线的最新发行版作为纯净内核。确保此内核没有被污染，并且仍然显示问题，因为问题可能已经在那里修复了。如果你首先在供应商内核中注意到该问题，请检查已知可以正常工作的最后一个版本的纯净构建是否也表现良好。
向 Linux 稳定邮件列表 (stable@vger.kernel.org) 发送一份简短的问题报告，并抄送 Linux 回归邮件列表 (regressions@lists.linux.dev)；如果你怀疑是某个特定子系统中的原因，抄送其维护者和邮件列表。大致描述问题，最好解释如何重现它。提及显示问题的第一个版本和正常工作的最后一个版本。然后等待进一步的指示。
下面的参考部分将更详细地解释这些步骤中的每一个步骤。
报告仅在较旧内核版本线中发生的问题¶
如果你尝试了如上所述的最新主线内核，但无法在那里重现你的问题，那么本小节适合你；同时，你希望在仍然支持的稳定或长期系列或定期基于这些系列重新构建的供应商内核中看到问题得到修复。如果是这种情况，请按照以下步骤操作
做好准备，接下来的几个步骤可能无法在旧版本中解决该问题：修复可能太大或太冒险而无法移植到那里。
执行上面 “处理稳定和长期内核线中的回归” 部分中的前三个步骤。
在 Linux 内核版本控制系统中搜索在主线中修复该问题的更改，因为其提交消息可能会告诉你是否已安排修复程序进行反向移植。如果你没有找到任何这样的信息，请在相应的邮件列表中搜索讨论此类问题或同行评审可能的修复程序的帖子；然后检查讨论，看看是否认为该修复不适合反向移植。如果根本没有考虑反向移植，请加入最新的讨论，询问是否有可能。
以前的步骤之一应该会导致解决方案。如果不起作用，请向似乎导致问题的子系统的维护人员寻求建议；抄送特定子系统的邮件列表以及稳定邮件列表。
下面的参考部分将更详细地解释这些步骤中的每一个步骤。
参考部分：向内核维护者报告问题¶
上面的详细指南简要概述了所有主要步骤，这对大多数人来说应该足够了。但有时会出现一些情况，即使是经验丰富的用户也可能会想知道如何实际执行这些步骤中的一个。这就是本节的目的，因为它将提供有关上述每个步骤的更多详细信息。将此视为参考文档：可以从头到尾阅读。但它主要用于浏览和查找有关如何实际执行这些步骤的详细信息的地方。
在深入了解细节之前，先提供一些一般性建议
Linux 内核开发人员很清楚这个过程很复杂，并且比其他 FLOSS 项目要求更高。我们很乐意简化它。但这需要在各个地方以及一些基础设施中进行工作，这些基础设施需要不断维护；没有人站出来做这项工作，所以目前情况就是这样。
与某些供应商的保修或支持合同并不赋予你从上游 Linux 内核社区的开发人员那里请求修复的权利：此类合同完全超出 Linux 内核、其开发社区和本文档的范围。这就是为什么你不能要求在这种情况下此类合同保证的任何内容，即使处理问题的开发人员为相关供应商工作也是如此。如果你想主张你的权利，请使用供应商的支持渠道。这样做时，你可能想提到你希望看到问题在上游 Linux 内核中得到修复；通过说这是确保最终修复将纳入所有 Linux 发行版的唯一方法来激励他们。
现在，下面介绍如何正确向 Linux 内核开发人员报告问题的详细信息。
确保你正在使用上游 Linux 内核¶
您是否在硬件或软件供应商提供的 Linux 内核中遇到问题？那么在几乎所有情况下，您最好停止阅读本文档，而是向您的供应商报告该问题，除非您愿意自己安装最新的 Linux 版本。请注意，无论如何，通常都需要后者来查找和修复问题。
像大多数程序员一样，Linux 内核开发人员不喜欢花时间处理甚至在他们当前的代码中都没有发生的问题的报告。这只是浪费大家的时间，尤其是你的时间。不幸的是，当涉及到内核时，这种情况很容易发生，并且经常导致双方的沮丧。这是因为几乎所有预装在设备（计算机、笔记本电脑、智能手机、路由器等）上的基于 Linux 的内核，以及大多数由 Linux 发行商提供的内核，都与 kernel.org 发行的官方 Linux 内核相去甚远：这些来自供应商的内核通常从 Linux 开发的角度来看是很久以前的，或者是经过大量修改的，通常两者兼而有之。
这些供应商内核中的大多数都不适合向 Linux 内核开发人员报告问题：你在其中遇到的问题可能早在几个月或几年前就已被 Linux 内核开发人员修复；此外，供应商的修改和增强功能可能会导致你遇到的问题，即使它们看起来很小或完全无关。这就是为什么你应该向供应商报告这些内核的问题。它的开发人员应该调查报告，并且如果事实证明是上游问题，则直接在上游修复或将报告转发到那里。实际上，这通常不起作用或可能不是你想要的。因此，你可能需要考虑通过自己安装最新的 Linux 内核核心来绕过供应商。如果这对你来说是一个选择，请在此过程中继续前进，因为本指南的后续步骤将解释如何在排除问题的其他潜在原因后执行此操作。
请注意，上一段以 “大多数” 一词开头，因为有时开发人员实际上愿意处理关于供应商内核中发生的问题的报告。他们最终是否这样做高度取决于开发人员和所涉及的问题。如果发行商仅对基于最新 Linux 版本的内核应用了少量修改，那么你的机会就很好；例如，对于 Debian GNU/Linux Sid 或 Fedora Rawhide 发布的的主线内核来说，情况通常如此。一些开发人员也会接受关于发行版发布的最新稳定内核的问题的报告，只要它只经过轻微修改即可；例如，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 内核时运行良好，但使用相似配置编译的新版本运行时效果较差或根本无法运行，则您正在处理回归。文档报告回归对此进行了更详细的解释。它还提供了许多其他您可能需要注意的有关回归的信息；例如，它解释了如何将您的问题添加到跟踪的回归列表中，以确保它不会被遗漏。
哪些问题符合安全问题的定义由您自行判断。在继续操作之前，请考虑阅读安全错误，因为它提供了有关如何最佳处理安全问题的其他详细信息。
当发生完全无法接受的糟糕事情时，该问题是“真正严重的问题”。例如，当 Linux 内核损坏其正在处理的数据或损坏其正在运行的硬件时，情况就是如此。当内核突然停止工作并显示错误消息（“内核崩溃”）或根本没有任何告别提示时，您也正在处理严重问题。请注意：不要将“崩溃”（内核停止自身的致命错误）与“Oops”（可恢复的错误）混淆，因为后者发生后内核仍然在运行。
确保健康的环境¶
确保导致您面临问题的不是内核的周围环境。
看起来很像内核问题的问题有时是由构建或运行时环境引起的。很难完全排除该问题，但您应该尽量减少它
在构建内核时使用经过验证的工具，因为编译器或 binutils 中的错误可能会导致生成的内核行为不当。
确保您的计算机组件在其设计规范范围内运行；这对于主处理器、主内存和主板尤其重要。因此，在遇到潜在的内核问题时，请停止降压或超频。
尽量确保不是有故障的硬件导致了您的问题。例如，不良的主内存可能会导致多种问题，这些问题会表现为看起来像是内核问题。
如果您正在处理文件系统问题，您可能需要使用
fsck检查相关文件系统，因为它可能以导致意外内核行为的方式损坏。在处理回归时，请确保不是在更新内核的同时更改了其他内容。例如，问题可能是由同时更新的其他软件引起的。也可能在您第一次重新启动到新内核时，恰好某个硬件组件坏了。更新系统 BIOS 或更改 BIOS 设置中的某些内容也可能导致看起来很像内核回归的问题。
为紧急情况做好准备¶
创建新的备份，并准备好系统修复和还原工具。
提醒一下，您正在处理计算机，计算机有时会做出意想不到的事情，尤其是在您摆弄其操作系统内核之类的关键部件时。这就是您在此过程中将要执行的操作。因此，请务必创建一个新的备份；还要确保您手头有所有工具来修复或重新安装操作系统，以及恢复备份所需的一切。
确保您的内核不会被增强¶
确保您的系统不会通过动态构建额外的内核模块来增强其内核，而 DKMS 之类的解决方案可能会在您不知情的情况下在本地执行此操作。
如果您的内核以任何方式得到增强，则您的错误报告被忽略或拒绝的风险会急剧增加。这就是为什么您应该删除或禁用诸如 akmods 和 DKMS 之类的机制：这些机制会自动构建附加内核模块，例如当您安装新的 Linux 内核或首次启动它时。还要删除它们可能已安装的任何模块。然后重新启动后再继续。
请注意，您可能不知道您的系统正在使用这些解决方案之一：它们通常会在您安装 Nvidia 的专有图形驱动程序、VirtualBox 或其他需要来自并非 Linux 内核一部分的模块的一些支持的软件时静默设置。这就是为什么您可能需要卸载带有此类软件的软件包才能摆脱任何第三方内核模块。
检查“污点”标志¶
检查问题发生时您的内核是否被“污染”，因为导致内核设置此标志的事件可能导致您面临的问题。
当发生可能导致看起来完全不相关的后续错误时，内核会用“污点”标志标记自身。如果您的内核被污点，您面临的问题可能是此类错误。这就是为什么您有必要尽早排除这种情况，然后再在此过程中投入更多时间。这是此步骤仅存在的原因，因为此过程稍后会告诉您安装最新的主线内核；届时您需要再次检查污点标志，因为那时它很重要，因为它将是报告关注的内核。
在正在运行的系统上，很容易检查内核是否已自行污点：如果 cat /proc/sys/kernel/tainted 返回 “0”，则内核未被污点，一切正常。在某些情况下，无法检查该文件；这就是为什么内核在报告内部问题（“内核错误”）、可恢复错误（“内核 Oops”）或在停止操作前报告不可恢复错误（“内核崩溃”）时也会提到污点状态。查看发生其中一种情况时打印的错误消息顶部附近，并搜索以“CPU:”开头的行。如果内核在注意到问题时未被污点，则应以“Not tainted”结尾；如果您看到“Tainted:”后跟几个空格和一些字母，则表示内核被污点了。
如果您的内核被污点，请研究被污点的内核以找出原因。尝试消除原因。通常它是由以下三件事之一引起的
发生可恢复错误（“内核 Oops”），并且内核自行污点，因为内核知道此后它可能会以奇怪的方式行为不当。在这种情况下，请检查您的内核或系统日志，并查找以此开头的部分
Oops: 0000 [#1] SMP这是自启动以来第一个 Oops，括号之间的“#1”表示了这一点。每个 Oops 以及此后发生的任何其他问题都可能是该第一个 Oops 的后续问题，即使两者看起来完全不相关。通过消除第一个 Oops 的原因并在之后重现问题来排除这种情况。有时只需重新启动就足够了，有时对配置进行更改并重新启动即可消除 Oops。但是，不要在此过程的此时投入太多时间，因为 Oops 的原因可能已在您稍后在此过程中要安装的较新 Linux 内核版本中修复。
您的系统使用安装自己的内核模块的软件，例如 Nvidia 的专有图形驱动程序或 VirtualBox。当内核从外部来源（即使它们是开源的）加载此类模块时，内核会自行污点：它们有时会在不相关的内核区域中引起错误，因此可能会导致您面临的问题。因此，当您想向 Linux 内核开发者报告问题时，必须阻止这些模块加载。大多数时候，最简单的方法是：暂时卸载此类软件，包括它们可能已安装的任何模块。之后重新启动。
当内核加载位于 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 内核缺乏一个集中的错误跟踪器，你可以在其中简单地提交你的问题并使其到达需要了解该问题的开发人员手中。这就是为什么你必须自己找到正确的位置和方式来报告问题。你可以借助脚本（见下文）来完成此操作，但它主要针对内核开发人员和专家。对于其他人来说，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 <[email protected]>
Mailing list: [email protected]
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:” 开头的行：它会告诉你哪里可以找到子系统特定的错误跟踪器来提交你的问题。上面的示例没有这样的行。大多数部分都是这种情况，因为 Linux 内核的开发完全由邮件驱动。很少有子系统使用错误跟踪器，而且只有一些子系统依赖 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 <[email protected]> (supporter:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Another S. Human <[email protected]> (maintainer:NETWORKING DRIVERS)
[email protected] (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
[email protected] (open list:NETWORKING DRIVERS (WIRELESS))
[email protected] (open list:NETWORKING DRIVERS)
[email protected] (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。然后，该脚本会查看提交历史记录，以查找最近处理过相关代码的人，因为他们可能会提供帮助。但是请谨慎使用这些结果，因为它很容易将你带入错误的方向。例如，在很少更改的区域（如旧的或未维护的驱动程序）中，这种情况很容易发生：有时，此类代码会在由完全不关心特定驱动程序的开发人员进行的全树清理期间被修改。
搜索现有报告，第二次运行¶
彻底搜索相关错误跟踪器或邮件列表的存档，查找可能与您的问题匹配的报告。如果您找到任何内容，请加入讨论，而不是发送新的报告。
如前所述，报告其他人已经提出的问题通常是对所有参与者（尤其是你作为报告者）的浪费时间。这就是为什么你应该再次搜索现有报告，现在你已经知道需要在哪里报告它们。如果是邮件列表，你通常会在 lore.kernel.org 上找到其存档。
但是，某些列表托管在不同的位置。例如，前面步骤中使用的 ath10k WiFi 驱动程序就是这种情况。但是你通常可以在网上轻松找到这些列表的存档。例如，搜索 “archive ath10k@lists.infradead.org” 将引导你进入 ath10k 邮件列表的信息页面，该页面顶部链接到其 列表存档。遗憾的是，这个列表和相当多的其他列表缺少搜索存档的方法。在这种情况下，请使用常规互联网搜索引擎并在你的搜索词中添加类似 “site:lists.infradead.org/pipermail/ath10k/” 的内容，这将结果限制在该 URL 的存档中。
此时，再次检查互联网、LKML 也许还有 bugzilla.kernel.org 也是明智之举。如果你的报告需要在错误跟踪器中提交，你可能还需要检查该子系统的邮件列表存档，因为可能有人只在那里报告了该问题。
有关如何搜索以及如果你找到匹配的报告时该怎么做的详细信息，请参阅上面的 “搜索现有报告，第一次运行”。
不要急于进行报告过程的这一步骤：花费 30 到 60 分钟甚至更多的时间可以为你和其他人节省大量时间和麻烦。
安装新的内核以进行测试¶
除非你已经在运行最新的 “mainline” Linux 内核，否则最好在报告过程中安装它。在某些情况下，使用最新的 “stable” Linux 进行测试和报告是一个可以接受的替代方案；在合并窗口期间，这实际上可能甚至是最好的方法，但在该开发阶段，最好还是暂停几天你的工作。无论你选择哪个版本，理想情况下都应使用“vanilla”构建。忽略这些建议将大大增加你的报告被拒绝或忽略的风险。
如第一步的详细说明中所述：像大多数程序员一样，Linux 内核开发人员不喜欢花时间处理甚至没有在当前代码中发生的问题的报告。这只会浪费每个人的时间，尤其是你的时间。这就是为什么每个人都希望你在报告问题之前确认该问题仍然存在于最新的上游代码中。你可以忽略此建议，但如前所述：这样做会大大增加你的问题报告被拒绝或简单地忽略的风险。
在内核的范围内，“最新的上游” 通常是指
安装主线内核；最新的稳定内核可以是一个选项，但大多数时候最好避免使用。在此过程的这个阶段，长期内核（有时称为“LTS内核”）不适用。下一小节将更详细地解释这一切。
接下来的小节将描述获取和安装此类内核的方法。它还概述了使用预编译的内核是可以的，但最好是原始的，这意味着：它是使用直接从 kernel.org 获取的 Linux 源代码构建的，没有任何修改或增强。
选择适合测试的正确版本¶
前往 kernel.org 查找您要用于测试的版本。忽略标有“最新版本”的大黄色按钮，查看表格的下方。在其顶部，您会看到一行以 mainline 开头，这在大多数情况下会指向一个版本号如“5.8-rc2”的预发布版本。如果是这种情况，您将需要使用此主线内核进行测试，因为所有修复都必须首先应用于此处。不要让“rc”吓到您，这些“开发内核”相当可靠 - 而且您已经按照上面的指示进行了备份，不是吗？
大约每九到十周中的两周，主线可能会指向一个版本号如“5.7”的正式发布版本。如果发生这种情况，请考虑暂停报告过程，直到下一个版本的第一个预发布版本（5.8-rc1）出现在 kernel.org 上。这是因为 Linux 开发周期届时处于为期两周的“合并窗口”中。在此期间，大部分更改和所有侵入性更改都将合并到下一个版本中。在此期间使用主线会有点风险。内核开发人员通常也很忙，可能没有空闲时间来处理问题报告。此外，在合并窗口期间应用的许多更改中的一项很可能修复了您面临的问题；这就是为什么您很快无论如何都必须使用较新的内核版本重新测试的原因，如下面“报告发出后的职责”部分所述。
这就是为什么等待合并窗口结束可能是有意义的。但是，如果您正在处理不应等待的事情，请不要这样做。在这种情况下，请考虑通过 git（见下文）获取最新的主线内核，或使用 kernel.org 上提供的最新稳定版本。如果主线由于某种原因当前不适用于您，也可以接受使用它。一般来说：使用它来重现问题也比根本不报告问题要好。
最好避免在合并窗口之外使用最新的稳定内核，因为所有修复都必须首先应用于主线。这就是检查最新的主线内核如此重要的原因：您希望在较旧版本系列中修复的任何问题都需要首先在主线中修复，然后才能向后移植，这可能需要几天或几周的时间。另一个原因是：您希望的修复可能对于向后移植来说太难或太冒险；因此，再次报告问题不太可能改变任何事情。
这些方面也是为什么长期内核（有时称为“LTS内核”）不适合报告过程的这个部分的原因：它们与当前代码相距太远。因此，请首先测试主线并按照流程进一步进行：如果问题没有在主线中发生，它将指导您如何在较旧的版本系列中修复它（如果这是相关修复的计划）。
如何获取新的 Linux 内核¶
使用预编译的内核：这通常是测试的最快、最简单和最安全的方法 - 特别是如果您不熟悉 Linux 内核。问题在于：大多数由发行商或附加存储库提供的内核都是从修改后的 Linux 源代码构建的。因此，它们不是原始的，因此通常不适合测试和问题报告：这些更改可能会导致您面临的问题或以某种方式影响它。
但是，如果您使用的是流行的 Linux 发行版，那么您就很幸运：对于其中相当多的一些发行版，您会在网上找到包含最新主线或稳定 Linux 作为原始内核构建的软件包的存储库。使用这些完全可以，只需从存储库的描述中确保它们是原始的或至少接近原始的。此外，请确保软件包包含 kernel.org 上提供的最新版本。如果软件包比一周前更旧，则可能不适合，因为新的主线和稳定内核通常每周至少发布一次。
请注意，您可能稍后需要手动构建自己的内核：有时需要这样做来进行调试或测试修复程序，如本文档后面所述。还要注意，预编译的内核可能缺少调试符号，而这些调试符号是解码内核在发生 panic、Oops、警告或 BUG 时打印的消息所必需的；如果您计划解码这些消息，那么您最好自己编译内核（有关详细信息，请参阅本小节的末尾和标题为“解码失败消息”的部分）。
使用 git：开发人员和熟悉 git 的经验丰富的 Linux 用户通常最好直接从 kernel.org 上的官方开发存储库获取最新的 Linux 内核源代码。这些源代码可能比最新的主线预发布版本稍微领先一些。不要担心：它们与正式的预发布版本一样可靠，除非内核的开发周期当前处于合并窗口的中间。但即使如此，它们也相当可靠。
常规方法：不熟悉 git 的用户通常最好从 kernel.org 下载源代码作为 tarball。
此处不描述如何实际构建内核，因为许多网站已经解释了必要的步骤。如果您是新手，请考虑遵循其中一个建议使用 make localmodconfig 的操作指南，因为它会尝试获取您当前内核的配置，然后尝试针对您的系统进行一些调整。这并不会使生成的内核更好，但会使其编译速度更快。
注意：如果您正在处理来自内核的 panic、Oops、警告或 BUG，请在配置内核时尝试启用 CONFIG_KALLSYMS。此外，还要启用 CONFIG_DEBUG_KERNEL 和 CONFIG_DEBUG_INFO；后者是其中相关的选项，但只有在您启用前者后才能访问。请注意，CONFIG_DEBUG_INFO 会大大增加构建内核所需的存储空间。但这很值得，因为这些选项稍后将允许您精确定位触发问题的确切代码行。下面的“解码失败消息”部分将对此进行更详细的解释。
但请记住：始终记录遇到的问题，以防难以重现。发送未解码的报告比根本不报告问题要好。
检查“污点”标志¶
确保您刚安装的内核在运行时不会“污染”自己。
正如上面已经更详细地概述的那样：当发生可能导致看起来完全不相关的后续错误时，内核会设置一个“污点”标志。这就是为什么您需要检查您刚刚安装的内核是否未设置此标志的原因。如果设置了此标志，那么在报告发生在其上的问题之前，您几乎在所有情况下都需要消除导致此标志的原因。有关如何执行此操作的详细信息，请参阅上面的部分。
使用新的内核重现问题¶
使用您刚安装的内核重现该问题。如果它在那里没有显示出来，请向下滚动到仅在稳定和长期内核中发生的问题的说明。
检查问题是否发生在新安装的 Linux 内核版本中。如果问题已经在那里修复，请考虑坚持使用此版本系列并放弃您报告问题的计划。但是请记住，只要问题没有在 kernel.org 的稳定和长期版本（以及由此派生的供应商内核）中修复，其他用户可能仍会受到它的困扰。如果您更喜欢使用这些版本之一，或者只是想帮助他们的用户，请转到下面“有关仅在较旧内核版本系列中发生的问题的报告详细信息”部分。
优化重现问题的描述¶
优化您的笔记：尝试找到并编写重现问题的最直接的方法。确保最终结果具有所有重要细节，同时对于第一次听说它的人来说易于阅读和理解。如果您在此过程中学到了什么，请考虑再次搜索有关该问题的现有报告。
不必要的复杂报告会使其他人难以理解您的报告。因此，请尝试找到一个易于描述且易于理解的书面形式的重现方法。包含所有重要细节，但同时尽量保持简短。
在此步骤和之前的步骤中，您可能已经了解了一些您面临的问题。使用这些知识再次搜索现有报告，您可以加入这些报告。
解码失败消息¶
如果您的故障涉及“panic”、“Oops”、“warning”或“BUG”，请考虑解码内核日志以查找触发错误的行代码。
当内核检测到内部问题时，它将记录有关已执行代码的一些信息。这使得可以精确定位触发问题的源代码中的确切行，并显示它是如何被调用的。但这仅在您配置内核时启用 CONFIG_DEBUG_INFO 和 CONFIG_KALLSYMS 时才有效。如果您这样做，请考虑解码来自内核日志的信息。这将使更容易理解导致“panic”、“Oops”、“警告”或“BUG”的原因，从而增加了有人能够提供修复的可能性。
可以使用您在 Linux 源代码树中找到的脚本来完成解码。如果您正在运行您自己之前编译的内核，请像这样调用它
[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux
如果您正在运行打包的原始内核，您可能需要安装相应的带有调试符号的软件包。然后像这样调用脚本（如果您的发行版没有打包该脚本，您可能需要从 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 内核绝不能变差，这就是他认为回归是不可接受的并希望尽快修复它们的原因。这就是为什么如果它们引起的问题不能通过其他方式快速解决，那么引入回归的更改通常会被立即还原。因此，报告回归有点像打出一张王牌以快速修复某些问题。但要做到这一点，需要知道导致回归的更改。通常，由报告者来追踪罪魁祸首，因为维护人员通常没有时间或设置来自己重现它。
要找到更改，有一个称为“二分”的过程，文档二分回归详细描述了该过程。该过程通常需要你构建大约十到二十个内核镜像，尝试用每个镜像重现问题，然后再构建下一个镜像。是的，这需要一些时间，但不要担心，它的工作速度比大多数人认为的要快得多。由于“二分查找”，这将引导你找到源代码管理系统中导致回归的那个提交。一旦你找到它，请在网上搜索更改的主题、其提交 ID 和缩短的提交 ID（提交 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)如果你正在处理回归并执行了二分法，请提及导致回归的更改的主题和提交 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 上创建的工单，...）并在你的报告中包含指向它们的链接。理想情况下，使用一些可以让文件多年可用的东西，因为它们可能会在多年后的将来对某人有用；例如，如果五年或十年后，开发人员正在处理一些更改过的代码以修复你的问题，则可能会发生这种情况。
将文件放在一边，并提及你将在稍后对你自己的邮件的单独回复中发送它们。只需记住在报告发出后实际执行此操作。;-)
可能明智的提供事项¶
根据问题，你可能需要添加更多背景数据。以下是一些经常建议提供的内容
如果你正在处理内核的“警告”、“OOPS”或“panic”，请将其包括在内。如果你无法复制并粘贴它，请尝试捕获 netconsole 跟踪或至少拍摄屏幕照片。
如果问题可能与你的计算机硬件有关，请提及你使用的系统类型。例如，如果你在图形卡方面遇到问题，请提及制造商、卡的型号以及使用的芯片。如果是笔记本电脑，请提及它的名称，但请尽量确保它有意义。例如，“戴尔 XPS 13”不是，因为它可能是 2012 年的型号；它与今天销售的型号看起来没有太大区别，但除此之外，两者没有任何共同之处。因此，在这种情况下，请添加确切的型号，例如，2019 年推出的 XPS 13 型号的“9380”或“7390”。像“联想 Thinkpad T590”这样的名称也有些含糊不清：这款笔记本电脑有带和不带专用图形芯片的变体，因此请尝试查找确切的型号名称或指定主要组件。
提及正在使用的相关软件。如果加载模块时遇到问题，则需要提及正在使用的 kmod、systemd 和 udev 的版本。如果其中一个 DRM 驱动程序行为不端，则需要声明 libdrm 和 Mesa 的版本；还要指定你的 Wayland 合成器或 X 服务器及其驱动程序。如果你有文件系统问题，请提及相应文件系统实用程序（e2fsprogs、btrfs-progs、xfsprogs 等）的版本。
从内核中收集可能感兴趣的其他信息。例如，
lspci -nn的输出将帮助其他人识别你使用的硬件。如果你遇到硬件问题，你甚至可能需要提供sudo lspci -vvv的输出，因为它提供了有关如何配置组件的见解。对于某些问题，最好包括诸如/proc/cpuinfo、/proc/ioports、/proc/iomem、/proc/modules或/proc/scsi/scsi等文件的内容。一些子系统还提供了收集相关信息的工具。其中一种工具是alsa-info.sh音频/声音子系统开发人员提供的。
这些示例应该能给你一些关于附加哪些数据比较明智的想法，但你需要自己思考哪些信息对其他人会有帮助。不用太担心会遗漏什么，因为开发者会要求提供他们需要的额外细节。但是，从一开始就提供所有重要的信息会增加其他人仔细查看的可能性。
重要部分：报告的头部¶
既然你已经准备好了报告的详细部分，让我们来看看最重要的部分：前几句话。因此，请转到顶部，在你刚刚编写的部分之前添加类似“详细描述：”的内容，并在顶部插入两个换行符。现在，写一个正常长度的段落，粗略地描述这个问题。省略所有枯燥的细节，专注于读者需要了解的关键部分，以理解这一切是怎么回事；如果你认为这个错误会影响很多用户，请提及这一点以引起人们的兴趣。
完成此操作后，在顶部再插入两行，并写一个一句话的摘要，快速解释报告的内容。之后，你必须更加抽象，为报告编写一个更短的主题/标题。
现在你已经写好了这部分，花一些时间来优化它，因为它是报告中最重要的部分：很多人只会阅读这一部分，然后决定是否值得花时间阅读其余部分。
现在，按照 MAINTAINERS 文件中的说明发送或提交报告，除非它是前面概述的“高优先级问题”之一：在这种情况下，请在发送报告之前先阅读下一小节。
高优先级问题的特殊处理¶
高优先级问题的报告需要特殊处理。
严重问题：确保主题或工单标题以及第一段清楚地表明问题的严重性。
回归问题：让报告的主题以“[REGRESSION]”开头。
如果你成功进行了二分查找，请使用引入回归的更改标题作为主题的第二部分。报告还应提及罪魁祸首的提交 ID。如果二分查找不成功，请在报告中提及最后测试的正常版本（例如 5.7）和出现问题的最旧版本（例如 5.8-rc1）。
通过邮件发送报告时，抄送 Linux 回归邮件列表 (regressions@lists.linux.dev)。如果需要将报告提交到某个 Web 跟踪器，请继续执行此操作。提交后，通过邮件将报告转发到回归列表；抄送维护者和相关子系统的邮件列表。确保内联转发的报告，因此不要附加它。并在顶部添加一个简短的说明，提及工单的 URL。
在邮寄或转发报告时，如果二分查找成功，请将罪魁祸首的作者添加到收件人中；同时抄送在提交消息末尾找到的 signed-off-by 链中的每个人。
安全问题：对于这些问题，你必须评估如果公开披露细节是否会对其他用户造成短期风险。如果不是这种情况，只需按照描述报告问题即可。对于存在此类风险的问题，你需要稍微调整报告流程
如果 MAINTAINERS 文件指示你通过邮件报告问题，请不要抄送任何公共邮件列表。
如果你应该在错误跟踪器中提交问题，请确保将工单标记为“私有”或“安全问题”。如果错误跟踪器不提供保持报告私有的方法，请忽略它，并将报告作为私人邮件发送给维护者。
在这两种情况下，请务必将报告邮寄给 MAINTAINERS 文件“安全联系人”部分中列出的地址。理想情况下，在通过邮件发送报告时直接抄送他们。如果你在错误跟踪器中提交了报告，请将报告的文本转发到这些地址；但请在顶部添加一个小说明，提及你已提交并附有指向工单的链接。
有关更多信息，请参见 安全错误。
报告发出后的职责¶
等待回应，并保持进展，直到你以某种方式接受结果。因此，及时公开回应任何询问。测试提出的修复方案。进行主动测试：至少在每个新主线版本的第一个候选版本 (RC) 中重新测试，并报告你的结果。如果事情停滞不前，发送友好的提醒。如果得不到任何帮助或不满意，请尝试自己解决。
如果你的报告很好并且你真的很幸运，那么其中一位开发人员可能会立即发现导致问题的原因；他们可能会编写一个补丁来修复它，测试它，并将其直接发送到主线进行集成，同时将其标记为稍后回溯到需要它的稳定和长期内核。然后，你只需要回复“非常感谢”，并在修复程序发布后切换到具有修复程序的版本即可。
但是，这种理想的情况很少发生。这就是为什么一旦你发出报告，工作才刚刚开始的原因。你需要做什么取决于情况，但通常会是下面列出的事情。但在深入了解细节之前，以下是一些你需要记住的关于此过程的重要事项。
进一步互动的通用建议¶
始终公开回复：当你在错误跟踪器中提交问题时，始终在那里回复，不要私下联系任何开发人员。对于邮寄的报告，在回复你收到的任何邮件时，始终使用“全部回复”功能。这包括你可能想要添加到报告中的任何其他数据的邮件：转到你的邮件应用程序的“已发送”文件夹，并在你的报告邮件上使用“全部回复”。这种方法将确保公共邮件列表和随着时间的推移参与其中的其他人始终保持在循环中；它还保持邮件线程完整，这对于邮件列表将所有相关邮件分组在一起尤其重要。
只有两种情况下，错误跟踪器中的评论或“全部回复”是不合适的
有人告诉你私下发送某些内容。
你被告知要发送某些内容，但注意到它包含需要保密的敏感信息。在这种情况下，可以将其私下发送给要求它的开发人员。但在工单或邮件中注明你这样做了，以便其他人都知道你遵守了要求。
在请求澄清或帮助之前进行研究：在此过程的这一部分中，有人可能会告诉你做一些你可能尚未掌握的技能要求的事情。例如，你可能被要求使用一些你从未听说过的测试工具；或者你可能被要求将补丁应用于 Linux 内核源代码，以测试它是否有帮助。在某些情况下，发送回复询问如何操作是可以的。但在走这条路之前，尝试通过搜索互联网自行找到答案；或者考虑在其他地方寻求建议。例如，问一个朋友或将其发布到你通常出没的聊天室或论坛。
要有耐心：如果你真的很幸运，你可能会在几个小时内收到对你报告的回复。但大多数时候，这将需要更长的时间，因为维护人员分散在世界各地，因此可能处于不同的时区——他们已经在键盘上度过了一夜。
通常，内核开发人员需要一到五个工作日才能回复报告。有时会需要更长的时间，因为他们可能忙于合并窗口、其他工作、参加开发者会议，或者只是享受漫长的暑假。
“高优先级问题”（请参阅上面的解释）在此处是一个例外：维护人员应尽快解决这些问题；这就是为什么你应该最多等待一周（如果事情紧急，则只需两天）再发送友好的提醒。
有时，维护人员可能不会及时回复；其他时候可能会有分歧，例如问题是否符合回归的条件。在这种情况下，请在邮件列表中提出你的担忧，并要求其他人公开或私下回复如何继续前进。如果失败，则可能需要让更高级别的权威机构介入。对于 WiFi 驱动程序，那将是无线维护人员；如果没有更高级别的维护人员或所有其他方法都失败，那么这可能是极少数情况下可以让 Linus Torvalds 介入的情况。
主动测试：每次发布新主线内核版本的第一个预发布版（“rc1”）时，请检查问题是否在那里得到修复，或者是否发生了任何重要的更改。在工单中或在你发送的回复你报告的邮件中提及结果（确保其中包含截至当时参与讨论的所有人员）。这将表明你的承诺以及你愿意提供帮助。它还告诉开发人员问题是否仍然存在，并确保他们不会忘记它。其他一些偶尔的重新测试（例如 rc3、rc5 和最终版本）也是一个好主意，但只有在发生了相关更改或者你无论如何都要编写某些内容时才报告你的结果。
在解决了所有这些一般性问题之后，让我们深入了解一旦问题被报告后如何帮助解决这些问题的细节。
询问和测试请求¶
以下是你收到报告回复后的职责
检查你与谁打交道：大多数情况下，回复你报告的将是特定代码区域的维护者或开发人员。但是，由于问题通常是公开报告的，因此回复的可能是任何人——包括那些想提供帮助，但最终可能会用他们的问题或请求完全误导你的人。这种情况很少发生，但这是明智地快速进行互联网搜索以查看你正在与谁互动的原因之一。通过这样做，你还可以了解到你的报告是否被合适的人听到，因为如果讨论逐渐消失而没有找到令人满意的问题解决方案，则稍后可能会提醒维护者（见下文）。
数据查询：通常，您会被要求测试某些内容或提供更多详细信息。请尽快提供所请求的信息，因为此时您正受到可能提供帮助的人的关注，如果等待时间过长，可能会失去这种关注；如果几天内不提供信息，这种情况甚至很可能发生。
测试请求：当您被要求测试诊断补丁或可能的修复时，也请尽量及时测试。但请正确进行测试，不要操之过急：混淆情况很容易发生，并可能给所有相关人员带来很多困惑。例如，一个常见的错误是认为已应用了包含修复的建议补丁，但实际上并没有应用。即使是有经验的测试人员偶尔也会发生这种情况，但他们大多数时候会注意到带有修复的内核的行为与没有修复的内核的行为相同。
当没有任何实质性进展时该怎么办¶
有些报告可能不会得到负责的 Linux 内核开发人员的任何回应；或者围绕该问题的讨论有所进展，但最终不了了之，没有任何实质性结果。
在这种情况下，请等待两周（最好是三周）后再发送友好的提醒：也许维护者在您的报告到达时暂时离开了键盘，或者有更重要的事情需要处理。在编写提醒时，请礼貌地询问是否需要您这边提供其他任何信息才能使问题有所进展。如果报告是通过邮件发出的，请在回复您的初始邮件的邮件的第一行中执行此操作（见上文），该邮件应包含下面原始报告的完整引用：这是少数几种 ‘TOFU’（正文在前，完整引用在后）方法是正确的情况，因为这样所有收件人都可以立即按正确的顺序获得详细信息。
在发出提醒后，再等待三周以获取回复。如果您仍然没有得到适当的回应，您首先应该重新考虑您的方法。您是否可能尝试联系错误的人？报告是否可能具有攻击性或过于令人困惑，以至于人们决定完全避开它？排除这些因素的最佳方法是：将报告展示给一两个熟悉 FLOSS 问题报告的人，并征求他们的意见。还要向他们咨询如何继续前进的建议。这可能意味着：准备一份更好的报告，并在您发送之前让这些人审查它。这种方法完全可以接受；只需说明这是关于该问题的第二份改进报告，并包含指向第一份报告的链接。
如果报告是正确的，您可以发送第二次提醒；在其中询问为什么报告没有得到任何回复的建议。发送第二次提醒邮件的一个好时机是，在新 Linux 内核版本的第一个预发布版本（‘rc1’）发布后不久，因为您应该在此时重新测试并提供状态更新（见上文）。
如果第二次提醒在一周内仍然没有得到任何回应，请尝试联系更高级别的维护者寻求建议：即使是很忙的维护者也至少应该在此时发送某种确认。
请记住做好失望的准备：理想情况下，维护者应该对每个问题报告做出某种回应，但他们只负责修复前面提到的那些“高优先级的问题”。因此，如果您收到类似 “感谢您的报告，我目前有更重要的问题需要处理，并且在可预见的未来没有时间研究这个问题” 的回复，请不要过于沮丧。
也有可能在错误跟踪器或列表上进行一些讨论之后，没有任何进展，而提醒也无法激励任何人制定修复方案。这种情况可能令人沮丧，但在 Linux 内核开发中是可能发生的。本文档末尾的“为什么有些问题在报告后得不到任何回应或仍然未修复”部分解释了这种情况以及其他一些无法获得帮助的原因。
如果您没有找到任何帮助或者最终问题没有得到解决，请不要感到沮丧：Linux 内核是 FLOSS，因此您仍然可以自己解决问题。例如，您可以尝试找到其他受影响的人，并与他们合作解决问题。这样一个团队可以一起准备一份新的报告，说明你们有多少人以及为什么在你们看来这个问题应该得到修复。也许你们可以一起缩小根本原因或引入回归的更改范围，这通常会使开发修复变得更容易。如果运气好的话，团队中可能会有人懂一点编程，并且能够编写修复程序。
关于 “在稳定和长期内核系列中报告回归” 的参考¶
本小节详细介绍了如果您在稳定和长期内核系列中遇到回归需要执行的步骤。
确保特定的版本线仍然获得支持¶
检查内核开发人员是否仍然维护您关心的 Linux 内核版本线：访问 kernel.org 的首页，确保它在没有 ‘[EOL]’ 标签的情况下提到了特定版本线的最新版本。
大多数内核版本线仅获得大约三个月的支持，因为维护时间更长需要大量工作。因此，每年只选择一个版本线，并获得至少两年的支持（通常为六年）。这就是为什么您需要检查内核开发人员是否仍然支持您关心的版本线的原因。
请注意，如果 kernel.org 在首页上列出了两个稳定版本线，您应该考虑切换到较新的版本线，而忘记旧的版本线：对它的支持很可能很快被放弃。然后它将获得一个 “生命周期结束”（EOL）标记。达到此点的版本线仍然会在 kernel.org 首页上提及一两周，但不适合测试和报告。
搜索稳定邮件列表¶
检查 Linux 稳定邮件列表的存档中是否存在现有报告。
也许您遇到的问题已经为人所知，并且已经被修复或即将被修复。因此，请在 Linux 稳定邮件列表的存档中搜索有关与您类似的问题的报告。如果您找到任何匹配项，请考虑加入讨论，除非修复已经完成并计划很快应用。
使用最新版本重现问题¶
安装特定版本线的最新发行版作为纯净内核。确保此内核没有被污染，并且仍然显示问题，因为问题可能已经在那里修复了。如果你首先在供应商内核中注意到该问题，请检查已知可以正常工作的最后一个版本的纯净构建是否也表现良好。
在将更多时间投入到此过程中之前，您需要检查您感兴趣的版本线的最新版本是否已修复该问题。此内核必须是原生的，并且在问题发生之前不应被污染，如上面的“安装用于测试的新内核”部分中详细概述的那样。
您是否首先注意到供应商内核的回归？那么供应商应用的更改可能会产生干扰。您需要通过执行重新检查来排除这种情况。假设当您从 5.10.4-vendor.42 更新到 5.10.5-vendor.43 时，某些内容中断了。然后在按照上一段概述的方式测试最新的 5.10 版本之后，检查原生构建的 Linux 5.10.4 是否也能正常工作。如果那里出现问题，则该问题不符合上游回归的条件，您需要切换回主逐步指南以报告该问题。
报告回归¶
向 Linux 稳定邮件列表 ([email protected]) 发送一份简短的问题报告，并抄送 Linux 回归邮件列表 ([email protected])；如果您怀疑是某个特定子系统导致的问题，请抄送其维护者和邮件列表。大致描述问题，并理想地解释如何重现它。提及第一个出现问题的版本和最后一个正常工作的版本。然后等待进一步的说明。
当报告发生在稳定或长期内核系列中的回归（例如，从 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 仍然存在问题。
上一段概述的基本上是一个粗略的手动“二分查找”。一旦您的报告发出，您可能会被要求进行适当的二分查找，因为它允许精确定位导致问题的确切更改（然后可以轻松地还原该更改以快速修复问题）。因此，如果时间允许，请考虑立即进行适当的二分查找。有关如何执行二分查找的详细信息，请参阅“回归的特别注意事项”部分和文档 二分查找回归。如果二分查找成功，请将罪魁祸首的作者添加到收件人中；还要抄送您在其提交消息末尾找到的 signed-off-by 链中的每个人。
关于 “仅在较旧的内核版本线中出现的问题的报告” 的参考¶
本节详细介绍了当您无法在主线内核中重现您的问题，但希望在较旧的版本线（即稳定版和长期维护版内核）中修复该问题时，您需要采取的步骤。
某些修复过于复杂¶
做好准备，接下来的几个步骤可能无法在旧版本中解决该问题：修复可能太大或太冒险而无法移植到那里。
即使是看似很小且显而易见的代码更改，有时也会引入新的、完全意想不到的问题。稳定版和长期维护版内核的维护者非常清楚这一点，因此只会将符合 关于 Linux -stable 版本的你想要知道的一切 中概述的规则的更改应用于这些内核。
例如，复杂或有风险的更改不符合条件，因此只会应用于主线内核。其他修复程序很容易反向移植到最新的稳定版和长期维护版内核，但集成到较旧的版本中风险太高。因此，请注意您所希望的修复可能属于不会反向移植到您关心的版本线的情况。在这种情况下，您别无选择，只能接受该问题或切换到较新的 Linux 版本，除非您想自己将修复程序修补到内核中。
常用准备工作¶
执行上面“仅在较旧内核版本线中出现的问题报告”部分中的前三个步骤。
您需要执行本指南另一部分中已描述的几个步骤。这些步骤将允许您
检查内核开发人员是否仍然维护您关心的 Linux 内核版本线。
在 Linux 稳定版邮件列表中搜索现有报告。
检查最新版本。
检查代码历史并搜索现有讨论¶
在 Linux 内核版本控制系统中搜索在主线中修复该问题的更改，因为其提交消息可能会告诉你是否已安排修复程序进行反向移植。如果你没有找到任何这样的信息，请在相应的邮件列表中搜索讨论此类问题或同行评审可能的修复程序的帖子；然后检查讨论，看看是否认为该修复不适合反向移植。如果根本没有考虑反向移植，请加入最新的讨论，询问是否有可能。
在很多情况下，您处理的问题会在主线内核中发生，但在那里得到了修复。修复它的提交也需要进行反向移植才能解决问题。这就是为什么您要搜索它或任何相关的讨论。
首先尝试在保存 Linux 内核源代码的 Git 存储库中查找修复程序。您可以使用 kernel.org 上的 Web 界面或其镜像 在 GitHub 上；如果您有本地克隆，您也可以使用
git log --grep=<pattern>在命令行中进行搜索。如果您找到修复程序，请查看提交消息的末尾附近是否包含类似于此的“稳定标签”
抄送：<stable@vger.kernel.org> # 5.4+
如果是这种情况，开发人员将修复标记为可以安全地反向移植到 5.4 及更高版本的版本线。大多数情况下，它会在两周内应用到那里，但有时会稍长一些。
如果提交没有告诉您任何信息，或者您找不到修复程序，请再次查找有关该问题的讨论。使用您喜欢的互联网搜索引擎以及 Linux 内核开发人员邮件列表的存档来搜索网络。另请阅读上面的 定位导致问题的内核区域 部分，并按照说明查找相关子系统：其错误跟踪器或邮件列表存档中可能包含您正在寻找的答案。
如果您看到建议的修复程序，请如上所述在版本控制系统中搜索它，因为提交可能会告诉您是否可以预期进行反向移植。
检查讨论中是否有任何迹象表明修复程序风险太大，无法反向移植到您关心的版本线。如果是这种情况，您必须接受该问题或切换到应用修复程序的内核版本线。
如果修复程序不包含稳定标签，并且没有讨论反向移植，请加入讨论：提及您遇到问题的版本，以及您希望看到修复，如果合适的话。
寻求建议¶
以前的步骤之一应该会导致解决方案。如果不起作用，请向似乎导致问题的子系统的维护人员寻求建议；抄送特定子系统的邮件列表以及稳定邮件列表。
如果前面三个步骤没有让您更接近解决方案，那么只剩下一个选择：寻求建议。在您发送给问题似乎根源的子系统维护者的邮件中执行此操作；同时抄送子系统的邮件列表和稳定邮件列表 (stable@vger.kernel.org)。
为什么某些问题在报告后没有任何反应或仍然未修复¶
向 Linux 开发人员报告问题时，请注意只有“高优先级问题”（回归、安全问题、严重问题）肯定会得到解决。维护人员，或者在万不得已的情况下，Linus Torvalds 本人会确保这一点。他们和其他内核开发人员也会修复许多其他问题。但请注意，有时他们无法或不愿提供帮助；有时甚至没有人可以发送报告。
最好用那些在业余时间为 Linux 内核做出贡献的内核开发人员来解释这一点。内核中的相当多的驱动程序是由此类程序员编写的，通常是因为他们只是想让他们的硬件在他们喜欢的操作系统上可用。
这些程序员大多数情况下会很乐意修复其他人报告的问题。但没有人可以强迫他们这样做，因为他们是自愿贡献的。
还有一些情况是这些开发人员真的想修复问题，但却无法修复：有时他们缺乏硬件编程文档来做到这一点。当公开提供的文档肤浅或驱动程序是在逆向工程的帮助下编写的时，这种情况经常发生。
迟早，业余时间开发人员也会停止关心该驱动程序。也许他们的测试硬件坏了，被更高级的硬件取代了，或者太旧了，以至于你在计算机博物馆之外都很难找到。有时开发人员会停止关心他们的代码和 Linux，因为他们生活中的其他事情变得更加重要。在某些情况下，没有人愿意接替维护者的工作——而且没有人可以被迫这样做，因为为 Linux 内核做出贡献是自愿的。但是，废弃的驱动程序仍然保留在内核中：它们对人们仍然有用，移除它们将是一种退步。
对于那些为他们在 Linux 内核上的工作获得报酬的开发人员来说，情况也没有什么不同。这些开发人员贡献了现在的大部分更改。但他们的雇主迟早也会停止关心他们的代码，或者让其程序员专注于其他事情。例如，硬件供应商主要通过销售新硬件来赚钱；因此，他们中的很多人并没有投入太多时间和精力来维护他们几年前停止销售的产品的 Linux 内核驱动程序。企业 Linux 发行商通常会维护更长的时间，但在新版本中，通常会放弃对旧的和罕见的硬件的支持，以限制范围。一旦公司放弃某些代码，业余时间贡献者通常会接手，但如上所述：迟早他们也会放弃代码。
优先级是某些问题未得到修复的另一个原因，因为维护人员经常被迫设置这些优先级，因为在 Linux 上工作的时间是有限的。对于业余时间或雇主允许其开发人员在上游内核上进行维护工作的时间来说，都是如此。有时，维护人员也会被报告淹没，即使驱动程序几乎完美地工作。为了不完全陷入困境，程序员可能别无选择，只能优先处理问题报告并拒绝其中的一些。
但不要太担心所有这些，许多驱动程序都有积极的维护人员，他们很有兴趣修复尽可能多的问题。
结束语¶
与其他自由/开源软件相比，向 Linux 内核开发人员报告问题是困难的：本文档的长度和复杂性以及字里行间的含义都说明了这一点。但目前情况就是这样。本文的主要作者希望记录当前的技术水平将为随着时间的推移改善这种情况奠定一些基础。