path: root/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst

.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
..
   If you want to distribute this text under CC-BY-4.0 only, please use 'The
   Linux kernel developers' for author attribution and link this as source:
   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
..
   Note: Only the content of this RST file as found in the Linux kernel sources
   is available under CC-BY-4.0, as versions of this text that were processed
   (for example by the kernel's build system) might contain content taken from
   files which use a more restrictive license.

.. include:: ../disclaimer-zh_CN.rst

:Original: Documentation/admin-guide/reporting-issues.rst

:译者:

 �想� Wu XiangCheng <bobwxc@email.cn>


报告问题
+++++++++


简明指�（亦� 太长�看）
==========================

您�临的是�为�系列稳定版或长期支�内核的普通内核的回归？是��然�支�？
请�索 `LKML内核邮件列表 <https://lore.kernel.org/lkml/>`_ 和
`Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ 存档中匹�的报告并
加入讨论。如果找�到匹�的报告，请安装该系列的最新版本。如果它�然出现问题，
报告给稳定版邮件列表（stable@vger.kernel.org）。

在所有其他情况下，请尽�能猜测是哪个内核部分导致了问题。查看MAINTAINERS文件，
了解开�人员希望如何得知问题，大多数情况下，报告问题都是通过电�邮件和抄�
相关邮件列表进行的。检查报告目的地的存档中是�已有匹�的报告；也请�索
`LKML <https://lore.kernel.org/lkml/>`_ 和网络。如果找�到�加入的讨论，请
安装 `最新的主线内核 <https://kernel.org/>`_ 。如果�存在问题，请��报告。

问题已�解决了，但是您希望看到它在一个�然支�的稳定版或长期支�系列中得到
解决？请安装其最新版本。如果它出现了问题，那么在主线中�索修�它的更改，并
检查是�正在回传（backporting）或者已放弃；如果两者都没有，那么�询问处�
更改的人员。

**通用�醒** ：当安装和测试上述内核时，请确�它是普通的（�：没有补�，也没
有使用附加模�）。还�确�它是在一个正常的环境中构建和�行，并且在问题�生
之�没有被污染（tainted）。

在编写报告时，�涵盖与问题相关的所有信�，如使用的内核和�行版。在碰�回归时，
�试给出引入它的更改的�交ID，二分�以找到它。如果您�时�临Linux内核的多个
问题，请分别报告�个问题。

一旦报告�出，请回答任何出现的问题，并尽�能地�供帮助。这包括通过�时�新
测试新版本并��状�更新�推动进展。


如何�内核维护人员报告问题的�步指�
=====================================

上�的简明指�概述了如何�Linux内核开�人员报告问题。对于已�熟悉�自由和开
�软件（FLOSS）项目报告问题的人�说，这�能是他们所需�的全部内容。对于其他
人，本部分更为详细，并一步一步地�述。为了便于阅读，它�然尽�简�，并�略
了许多细节；这些在�步指��的�考章节中进行了�述，该章节更详细地解释了�
个步骤。

注�：本节涉�的方�比简明指�多，顺�也�有��。这符�你的利益，以确�您
尽早�识到看起��Linux内核毛病的问题�能实际上是由其他原因引起的。这些步骤
�以确�你最终�会觉得在这一过程中投入的时间是浪费：

 * 您是��临硬件或软件供应商�供的Linux内核的问题？那么基本上您最好�止阅读
   本文档，转而�您的供应商报告问题，除�您愿�自己安装最新的Linux版本。寻找
   和解决问题往往需��者。

 * 使用您喜爱的网络�索引擎对现有报告进行粗略�索；此外，请检查
   `Linux内核邮件列表（LKML） <https://lore.kernel.org/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 的首页
   <https://kernel.org/>`_ ，确�此特定版本线的最新版没有“[EOL]�标记。

 * 检查 `Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ 中的现有报告。

 * 从特定的版本线安装最新版本作为纯净内核。确�这个内核没有被污染，并且�然
   存在问题，因为问题�能已�在那里被修�了。如果您第一次�现供应商内核的问题，
   请检查已知最新版本的普通构建是��以正常�行。

 * �Linux稳定版邮件列表��一个简短的问题报告(stable@vger.kernel.org)。大致
   �述问题，并解释如何�现。讲清楚首个出现问题的版本和最�一个工作正常的版本。
   然�等待进一步的指示。

下�的�考章节部分详细解释了这些步骤中的�一步。


报告��生在较旧内核版本线的问题
----------------------------------

若您�试了上述的最新主线内核，但未能在那里�现问题，那么本�节适用于您；以下
�程有助于使问题在�然支�的稳定版或长期支�版本线，或者定期基于最新稳定版或
长期支�内核的供应商内核中得到修�。如果是这�情况，请执行以下步骤：

 * 请�好准备，接下�的几个步骤�能无法在旧版本中解决问题：修��能太大或太
   冒险，无法移�到那里。

 * 执行�节“报告稳定版和长期支�内核线的回归�中的�三个步骤。

 * 在Linux内核版本控制系统中�索修�主线问题的更改，因为它的�交消��能会
   告诉你修�是�已�计划好了支�。如果你没有找到，�索适当的邮件列表，寻找
   讨论此类问题或�行评议�能修�的帖�；然�检查讨论是�认为修��适�支�。
   如果支�根本�被考虑，加入最新的讨论，询问是�有�能。

 * ��的步骤之一应该会给出一个解决方案。如果�未能�功，请��能引起问题的
   �系统的维护人员询问建议；抄�特定�系统的邮件列表以�稳定版邮件列表

下�的�考章节部分详细解释了这些步骤中的�一步。


�考章节：�内核维护者报告问题
===============================

上�的详细指�简�地列出了所有主�步骤，这对大多数人�说应该足够了。但有时，
�使是有�验的用户也�能想知�如何实际执行这些步骤之一。这就是本节的目的，
因为它将�供关于上述�个步骤的更多细节。请将此作为�考文档：�以从头到尾
阅读它。但它主�是为了�览和查找如何实际执行这些步骤的详细信�。

在深入挖掘细节之�，我想先给你一些一般性建议：

 * Linux内核开�人员很清楚这个过程很��，比其他的FLOSS项目�求更多。我们很
   希望让它更简�。但这需�在��的地方以�一些基础设施上付诸努力，这些基础
   设施需��续的维护；尚未有人站出��这些工作，所以目�情况就是这样。

 * 与�些供应商签订的��或支���并�能使您有��求上游Linux内核社区的开
   �人员进行修�：这样的��完全在Linux内核�其开�社区和本文档的范围之外。
   这就是为什么在这�情况下，你�能�求任何契约��，�使开�人员处�的问
   题对供应商有效。如果您想主张您的�利，使用供应商的支�渠�代替。当这样�
   的时候，你�能想�出你希望看到这个问题在上游Linux内核中修�；�以这是确
   �最终修�将被纳入所有Linux�行版的唯一方法�鼓励他们。

 * 如果您从未�FLOSS项目报告过任何问题，那么您应该考虑阅读 `如何有效地报告
   缺陷 <https://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_ ， `如何
   以明智的方��问 <http://www.catb.org/esr/faqs/smart-questions.html>`_ ，
   和 `如何�出好问题 <https://jvns.ca/blog/good-questions/>`_ 。

解决这些问题之�，�以在下�找到如何正确地�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 Turboweed。但是请记�，您最好使用主线Linux，并��在此�程中使用
稳定版内核，如“安装一个新的内核进行测试�一节中所详述。

当然，您�以忽略所有这些建议，并�上游Linux开�人员报告旧的或�过大�修改的
供应商内核的问题。但是注�，这样的报告�常被拒�或忽视，所以自行�心考虑一下。
�过这还是比根本�报告问题�好：有时候这样的报告会直接或间接地帮助解决之�的
问题。


�索现有报告（第一部分）
-------------------------

    *使用您喜爱的网络�索引擎对现有报告进行粗略�索；此外，请检查Linux内核
    邮件列表（LKML）的存档。如果找到匹�的报告，请加入讨论而�是��新报告。*

报告一个别人已��出的问题，对�个人�说都是浪费时间，尤其是作为报告人的你。
所以彻底检查是�有人已�报告了这个问题，这对你自己是有利的。在�程中的这一步，
�以�执行一个粗略的�索：一旦您知�您的问题需�报告到哪里，��的步骤将告诉
您如何详细�索。尽管如此，��仓促完�这一步，它�以节�您的时间和�少麻烦。

�需先用你最喜欢的�索引擎在互�网上�索。然���索Linux内核邮件列表（LKML）
存档。

如果�索结果实在太多，�以考虑让你的�索引擎将�索时间范围�制在过去的一个
月或一年。而且无论你在哪里�索，一定�用�当的�索关键�；也��化几次关键
�。�时，试�从别人的角度看问题：这将帮助你想出其他的关键�。�外，一定�
��时使用过多的关键�。记��索时��时�试包�和�包�内核驱动程�的�称
或�影�的硬件组件的�称等信�。但其确切的�牌�称（比如说“�硕红魔 Radeon
RX 5700 XT Gaming OC�）往往帮助�大，因为它太具体了。相�，�试�索术语，如
型�（Radeon 5700 或 Radeon 5000）和核心代�（“Navi�或“Navi10�），以�包�
和�包�其制造商（“AMD�）。

如果你�现了关于你的问题的现有报告，请加入讨论，因为你�能会�供有价值的�
外信�。这一点很��，�使是在修�程�已�准备好或处于最�阶段，因为开�人
员�能会寻找能够�供�外信�或测试建议修�程�的人。跳到“�布报告�的责任�
一节，了解有关如何正确�与的细节。

注�，�索 `bugzilla.kernel.org <https://bugzilla.kernel.org/>`_ 网站�能
也是一个好主�，因为这�能会�供有价值的�解或找到匹�的报告。如果您�现�者，
请记�：大多数�系统都希望在��的�置报告，如下�“你需�将问题报告到何处�
一节中所述。因此本应处�这个问题的开�人员甚至�能�知�bugzilla的工�。所以
请检查工�中的问题是�已�按照本文档所述得到报告，如果没有，请考虑这样�。

高优先级的问题？
-----------------

    *看看你正在处�的问题是�是回归问题�安全问题或�常严�的问题：这些都是
    需�在接下�的一些步骤中特别处�的“高优先级问题�。*

Linus Torvalds和主�的Linux内核开�人员希望看到一些问题尽快得到解决，因此在
报告过程中有一些“高优先级问题�的处�略有��。有三�情况符��件:回归�安全
问题和�常严�的问题。

如果在旧版本的Linux内核中工作的东西�能在新版本的Linux内核中工作，或者��
程度上在新版本的Linux内核中工作得更差，那么你就需�处�“回归�。因此，当一个
在Linux 5.7中表现良好的WiFi驱动程�在5.8中表现�佳或根本�能工作时，这是一
�回归。如果应用程�在新的内核中出现�稳定的现象，这也是一�回归，这�能是
由于内核和用户空间之间的接�（如procfs和sysfs）�生�兼容的更改造�的。显著
的性能�低或功耗增加也�以称为回归。但是请记�:新内核需�使用与旧内核相似的
�置�构建（��下�如何实现这一点）。这是因为内核开�人员在实现新特性时有
时无法���兼容性；但是为了��回归，这些特性必须在构建�置期间显�地�用。

什么是安全问题留给您自己判断。在继续之�，请考虑阅读
“Documentation/translations/zh_CN/admin-guide/security-bugs.rst�，
因为它�供了如何最�当地处�安全问题的�外细节。

当�生了完全无法接�的糟糕事情时，此问题就是一个“�常严�的问题�。例如，
Linux内核破�了它处�的数�或��了它�行的硬件。当内核�然显示错误消�
（“kernel panic�）并�止工作，或者根本没有任何�止信�时，您也在处�一个严�
的问题。注�：��混淆“panic�（内核�止自身的致命错误）和“Oops�（���错误），
因为显示�者之�内核�然在�行。


确�环境�康
--------------

    *确��是内核所处环境导致了你所�临的问题。*

看起�很�内核问题的问题有时是由构建或�行时环境引起的。很难完全排除这�问
题，但你应该尽��少这�问题：

 * 构建内核时，请使用�过验�的工具，因为编译器或二进制文件中的错误�能会导
   致内核出现错误行为。

 * 确�您的计算机组件在其设计规范内�行；这对处�器�内存和主�尤为��。因
   此，当�临潜在的内核问题时，�止低电压或超频。

 * 尽�确��是硬件故障导致了你的问题。例如，内存��会导致大�的问题，这些
   问题会表现为看起��内核问题。

 * 如果你正在处�一个文件系统问题，你�能需�用 ``fsck`` 检查一下文件系统，
   因为它�能会以��方�被��，从而导致无法预期的内核行为。

 * 在处�回归问题时，�确�没有在更新内核的�时�生了其他�化。例如，这个问
   题�能是由�时更新的其他软件引起的。也有�能是在你第一次��进入新内核时，
   �个硬件巧�地�了。更新系统 BIOS 或改� BIOS 设置中的�些内容也会导致
   一些看起�很�内核回归的问题。


为紧急情况�好准备
-------------------

    *创建一个全新的备份，并将系统修�和还原工具放在手边*

我得�醒您，您正在和计算机打交�，计算机有时会出现�想�到的事情，尤其是当
您折腾其�作系统的内核等关键部件时。而这就是你在这个过程中��的事情。因此，
一定�创建一个全新的备份；还�确�你手头有修�或�装�作系统的所有工具，
以���备份所需的一切。


确�你的内核�会被增强
------------------------

    *确�您的系统�会通过动�构建�外的内核模��增强其内核，�DKMS这样的解
    决方案�能在您�知情的情况下就在本地进行了这样的工作。*

如果内核以任何方�得到增强，那么问题报告被忽略或拒�的风险就会急剧增加。这就
是为什么您应该删除或�用�akmods和DKMS这样的机制：这些机制会自动构建�外内核
模�，例如当您安装新的Linux内核或第一次引导它时。也�记得�时删除他们�能安装
的任何模�。然��新�动�继续。

注�，你�能�知�你的系统正在使用这些解决方案之一：当你安装 Nvidia 专有图
形驱动程��VirtualBox 或其他需� Linux 内核以外的模�支�的软件时，它们通
常会�默设置。这就是为什么你�能需��载这些软件的软件包，以摆脱任何第三方
内核模�。


检查“污染�标志
----------------

    *当问题�生时，检查您的内核是�被“污染�，因为使内核设置这个标志的事件�
    能会导致您�临的问题。*

当�些�能会导致看起�完全�相关的�续错误的事情�生时，内核会用“污染
（taint）�标志标记自己。如果您的内核�到污染，那么您�临的�能是这样的错误。
因此在投入更多时间到这个过程中之�，尽早排除此情况�能对你有好处。这是这个
步骤出现在这里的唯一原因，因为这个过程��会告诉您安装最新的主线内核；然�
您将需��次检查污染标志，因为当它出问题的时候内核报告会关注它。

在正在�行的系统上检查内核是�污染�常容易：如果 ``cat /proc/sys/kernel/tainted``
返回“0�，那么内核没有被污染，一切正常。在�些情况下无法检查该文件；这就是
为什么当内核报告内部问题（“kernel bug�）����错误（“kernel Oops�）或�止
�作�����的错误（“kernel panic�）时，它也会�到污染状�。当其中一个错
误�生时，查看打�的错误消�的顶部，�索以“CPU:�开头的行。如果�现问题时内
核未被污染，那么它应该以“Not infected�结�；如果你看到“Tainted:�且�跟一些
空格和字�，那就被污染了。

如果你的内核被污染了，请阅读“Documentation/translations/zh_CN/admin-guide/tainted-kernels.rst�
以找出原因。设法消除污染因素。通常是由以下三�因素之一引起的：

 1. �生了一个���的错误（“kernel Oops�），内核污染了自己，因为内核知�在
    此之�它�能会出现奇怪的行为错乱。在这�情况下，检查您的内核或系统日志，
    并寻找以下列文字开头的部分::

       Oops: 0000 [#1] SMP

    如方括�中的“#1�所示，这是自�动以�的第一次Oops。�个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内核缺少一个，�以简�地将问题归档并让需�了解它的开�人员了
解它的，中心化缺陷跟踪器。这就是为什么你必须找到正确的途径�自己报告问题。
您�以在脚本的帮助下�到这一点（�下文），但它主�针对的是内核开�人员和专
家。对于其他人�说，MAINTAINERS（维护人员）文件是更好的选择。

如何阅读MAINTAINERS维护者文件
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

为了说明如何使用 :ref:`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�代�树的根目录中找到的原始维护者文件，则行�述将是
缩写。例如，“Mail:（邮件）�将是“M:�，“Mailing list:（邮件列表）�将是“L�，
“Status:（状�）�将是“S:�。此文件顶部有一段解释了这些和其他缩写。

首先查看“Status�状�行。�想情况下，它应该得到“Supported（支�）�或
“Maintained（维护）�。如果状�为“Obsolete（过时的）�，那么你在使用一些过时的
方法，需�转�到新的解决方案上。有时候，�有在感到有动力时，�会有人为代�
�供“Odd Fixes�。如果碰�“Orphan�，你就完全�走�了，因为�也没有人关心代�
了，�剩下这些选项:准备好与问题共存，自己修�它，或者找一个愿�修�它的程�员。

检查状��，寻找以“bug:�开头的一行：它将告诉你在哪里�以找到�系统特定的缺
陷跟踪器��交你的问题。上�的例�没有此行。大多数部分都是这样，因为 Linux
内核的开�完全是由邮件驱动的。很少有�系统使用缺陷跟踪器，且其中�有一部分
�赖于 bugzilla.kernel.org。

在这�以�其他很多情况下，你必须寻找以“Mail:�开头的行。这些行�到了特定代�
的维护者的�字和电�邮件地�。也�以查找以“Mailing list:�开头的行，它告诉你
开�代�的公共邮件列表。你的报告之�需�通过邮件�到这些地�。�外，对于所有
通过电�邮件��的问题报告，一定�抄� Linux Kernel Mailing List（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。脚本会查看�交历�，以找到最近哪些人�与了相关代�的编写，
因为他们�能会�供帮助。但��心使用这些结果，因为它很容易让你误入歧途。
例如，这�情况常常会�生在很少被修改的地方（比如�旧的或未维护的驱动程�）：
有时这样的代�会在树级清�期间被根本�关心此驱动程�的开�者修改。


�索现有报告（第二部分）
--------------------------

    *在缺陷追踪器或问题相关邮件列表的存档中彻底�索�能与您的问题匹�的报告。
    如果找到匹�的报告，请加入讨论而�是��新报告。*

如�所述：报告一个别人已��出的问题，对�个人�说都是浪费时间，尤其是作为报告
人的你。这就是为什么你应该�次�索现有的报告。现在你已�知�问题需�报告到哪里。
如果是邮件列表，那么一般在 `lore.kernel.org <https://lore.kernel.org/>`_ �以
找到相应存档。

但有些列表�行在其他地方。例如��步骤中当例�的ath10k WiFi驱动程�就是这�
情况。但是你通常�以在网上很容易地找到这些列表的档案。例如�索“archive
ath10k@lists.infradead.org�，将引导您到ath10k邮件列表的信�页，该页�顶部链接
到其 `列表存档 <https://lists.infradead.org/pipermail/ath10k/>`_ 。�憾的是，
这个列表和其他一些列表缺��索其存档的功能。在这�情况下�以使用常规的互�网
�索引擎，并添加类似“site:lists.infadead.org/pipermail/ath10k/�这
样的�索�件，这会把结果�制在该链接中的档案。

也请进一步�索网络�LKML和bugzilla.kernel.org网站。

有关如何�索以�在找到匹�报告时如何�作的详细信�，请�阅上�的“�索现有报告
（第一部分）�。

��急�完�报告过程的这一步：花30到60分钟甚至更多的时间�以为你和其他人节� /
�少相当多的时间和麻烦。


安装一个新的内核进行测试
--------------------------

    *除�您已�在�行最新的“主线�Linux内核，�则最好在报告�程�安装它。在
    �些情况下，使用最新的“稳定版�Linux进行测试和报告也是�以接�的替代方案；
    在�并窗�期间，这实际上�能是最好的方法，但在开�阶段最好还是暂�几天。
    无论你选择什么版本，最好使用“普通�构建。忽略这些建议会大大增加您的报告
    被拒�或忽略的风险。*

正如第一步的详细解释中所�到的：与大多数程�员一样，与大多数程�员一样，Linux
内核开�人员�喜欢花时间处�他们维护的�代�中根本�会�生的问题的报告。这�
会浪费�个人的时间，尤其是你的时间。这就是为什么在报告问题之�，您必须先确认
问题�然存在于最新的上游代�中，这符��个人的利益。您�以忽略此建议，但如�
所述：这样�会�大地增加问题报告被拒�或被忽略的风险。

内核“最新上游�的范围通常指：

 * 安装一个主线内核；最新的稳定版内核也�以是一个选择，但大多数时候都最好��。
   长期支�内核（有时称为“LTS内核�）�适�此�程。下一�节将更详细地解释所有
   这些。

 * 下一�节�述获�和安装这样一个内核的方法。它还指出了使用预编译内核是�以的，
   但普通的内核更好，这�味�：它是直接使用从 `kernel.org <https://kernel.org/>`_
   获得的Linux�代�构建并且没有任何方�修改或增强。


选择适�测试的版本
~~~~~~~~~~~~~~~~~~~~

�往 `kernel.org <https://kernel.org/>`_ �决定使用哪个版本。忽略那个写�
“Latest release最新版本�的巨大黄色按钮，往下看有一个表格。在表格的顶部，你会
看到一行以“mainline�开头的字样，大多数情况下它会指�一个版本�类似“5.8-rc2�
的预�布版本。如果是这样的�，你将需�使用这个主线内核进行测试。��让“rc�
�到你，这些“开�版内核�实际上�常��——而且你已�按照上�的指示�了备份，
�是�？

大概��到�周，“mainline��能会给你指出一个版本�类似“5.7�的正�版本。如果
碰�这�情况，请考虑暂�报告过程，直到下一个版本的第一个预�布（5.8-rc1）出
现在 `kernel.org <https://kernel.org/>`_ 上。这是因为 Linux 的开�周期正在
两周的“�并窗��内。大部分的改动和所有干扰性的改动都会在这段时间内被�并到
下一个版本中。在此期间使用主线是比较�险的。内核开�者通常也很忙，�能没有
多余的时间�处�问题报告。这也是很有�能在�并窗�中应用了许多修改�修�你
所�临的问题；这就是为什么你很快就得用一个新的内核版本�新测试，就�下�“�
布报告�的责任�一节中所述的那样。

这就是为什么�等到�并窗�结���去�。但是如果你处�的是一些�应该等待的
东西，则无需这样�。在这�情况下，�以考虑通过 git 获�最新的主线内核（�下
文），或者使用 kernel.org 上�供的最新稳定版本。如果 mainline 因为�些原因
�无法正常工作，那么使用它也是�以接�的。总的�说：用它��现问题也比完全
�报告问题�好。

最好��在�并窗�外使用最新的稳定版内核，因为所有修�都必须首先应用于主线。
这就是为什么检查最新的主线内核是如此��：你希望看到在旧版本线修�的任何问题
需�先在主线修�，然��能得到回传，这�能需�几天或几周。�一个原因是：您
希望的修�对于回传�说�能太难或太冒险；因此�次报告问题�太�能改�任何事情。

这些方�也部分表明了为什么长期支�内核（有时称为“LTS内核�）�适�报告�程：
它们与当�代�的�离太远。因此，先去测试主线，然��按�程走：如果主线没有
出现问题，�程将指导您如何在旧版本线中修�它。

如何获得新的 Linux 内核
~~~~~~~~~~~~~~~~~~~~~~~~~

你�以使用预编译或自编译的内核进行测试；如果你选择�者，�以使用 git 获��
代�，或者下载其 tar 存档包。

**使用预编译的内核** ：这往往是最快速�最简��最安全的方法——尤其是在你�熟
悉 Linux 内核的情况下。问题是：�行商或附加存储库�供的大多数版本都是从修改
过的Linux�代�构建的。因此它们�是普通的，通常�适�于测试和问题报告：这些
更改�能会导致您�临的问题或以��方�影�问题。

但是如果您使用的是�行的Linux�行版，那么您就很幸�了：对于大部分的�行版，
您�以在网上找到包�最新主线或稳定版本Linux内核包的存储库。使用这些是完全�
以的，��从存储库的�述中确认它们是普通的或者至少接近普通。此外，请确�软件
包包�kernel.org上�供的最新版本内核。如果这些软件包的时间超过一周，那么它们
�能就��适了，因为新的主线和稳定版内核通常至少�周�布一次。

请注�，您以��能需�手动构建自己的内核：有时这是调试或测试修�程�所必需的，
如�文所述。还�注�，预编译的内核�能缺少在出现panic�Oops�warning或BUG时
解�内核打�的消�所需的调试符�；如果您计划解�这些消�，最好自己编译内核
（有关详细信�，请�阅本�节结尾和“解�失败信���节）。

**使用git** ：熟悉 git 的开�者和有�验的 Linux 用户通常最好直接从
`kernel.org 上的官方开�仓库
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_
中获�最新的 Linux 内核�代�。这些很�能比最新的主线预�布版本更新一些。�
用担心：它们和正�的预�布版本一样��，除�内核的开�周期目�正处于�并窗
�中。�过�便如此，它们也是相当��的。

**常规方法** ：�熟悉 git 的人通常最好从 `kernel.org <https://kernel.org/>`_
下载��的tar 存档包。

如何实际构建一个内核并�在这里�述，因为许多网站已�解释了必�的步骤。如果
你是新手，�以考虑按照那些建议使用 ``make localmodconfig`` ��，它将�试获
�你当�内核的�置，然�根�你的系统进行一些调整。这样�并�能使编译出�的
内核更好，但�以更快地编译。

注�：如果您正在处��自内核的pannc�Oops�warning或BUG，请在�置内核时�试
�用 CONFIG_KALLSYMS 选项。此外，还�以�用 CONFIG_DEBUG_KERNEL 和
CONFIG_DEBUG_INFO；�者是相关选项，但�有�用�者�能开�。请注�，
CONFIG_DEBUG_INFO 会需�更多储存空间�构建内核。但这是值得的，因为这些选项将
�许您��精确定�触�问题的确切代�行。下�的“解�失败信��一节对此进行了更
详细的解释。

但请记�：始终记录�到的问题，以防难以�现。��未解�的报告总比�报告�好。


检查“污染�标志
----------------

    *确�您刚刚安装的内核在�行时�会“污染�自己。*

正如上�已�详细介�过的：当�生一些�能会导致一些看起�完全�相关的�续错
误的事情时，内核会设置一个“污染�标志。这就是为什么你需�检查你刚刚安装的内
核是�有设置此标志。如果有的�，几乎在任何情况下你都需�在报告问题之�先消
除它。详细的�作方法请看上�的章节。


用新内核�现问题
------------------

    *在您刚刚安装的内核中�现这个问题。如果它没有出现，请查看下方��生在
    稳定版和长期支�内核的问题的说明。*

检查这个问题是��生在你刚刚安装的新 Linux 内核版本上。如果新内核已�修�了，
�以考虑使用此版本线，放弃报告问题。但是请记�，��它没有在 `kernel.org
<https://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
	/usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/

如果您�行的是打包好的普通内核，则�能需�安装带有调试符�的相应包。然�按以下
方�调用脚本（如果�行版未打包，则�能需�从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 内核永远�应�化，这就是为什么他
认为回归是��接�的，并希望看到它们被迅速修�。这就是为什么引入了回归的改
动导致的问题若无法通过其他方�快速解决，通常会被迅速撤销。因此，报告回归有
点�“王炸�，会迅速得到修�。但��到这一点，需�知�导致回归的�化。通常情
况下，�由报告者�追查罪�祸首，因为维护者往往没有时间或手头设置�便�自行
�现它。

有一个��“二分�的过程�以�寻找�化，这在
“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst�文档中进行了详细
的�述，这个过程通常需�你构建�到二�个内核镜�，�次都�试在构建下一个镜�
之��现问题。是的，这需�花费一些时间，但�用担心，它比大多数人想象的�快得多。
多�了“binary search二进制�索�，这将引导你在�代�管�系统中找到导致回归的�交。
一旦你找到它，就在网上�索其主题��交ID和缩短的�交ID（�交ID的�12个字符）。
如果有的�，这将引导您找到关于它的现有报告。

需�注�的是，二分法需�一点�门，�是�个人都懂得诀�，也需�相当多的努力，
�是�个人都愿�投入。尽管如此，还是强烈建议自己进行一次二分。如果你真的
�能或者�想走这�路，至少�找出是哪个主线内核引入的回归。比如说从 5.5.15
切�到 5.8.4 的时候出现了一些问题，那么至少�以�试一下相近的所有的主线版本
（5.6�5.7 和 5.8）�检查它是什么时候出现的。除�你想在一个稳定版或长期支�
内核中找到一个回归，�则���测试那些编�有三段的版本（5.6.12�5.7.8），因
为那会使结果难以解释，�能会让你的测试�得无用。一旦你找到了引入回归的主�
版本，就�以放心地继续报告了。但请记�：在�知�罪�祸首的情况下，开�人员
是�能够�供帮助�决于手头的问题。有时他们�能会从报告中确认是什么出现了问
题，并能修�它；有时他们�能无法�供帮助，除�你进行二分。

当处�回归问题时，请确�你所�临的问题真的是由内核引起的，而�是由其他东西
引起的，如上文所述。

在整个过程中，请记�：�有当旧内核和新内核的�置相似时，问题�算回归。最好
的方法是：把�置文件（``.config``）从旧的工作内核直接�制到你�试的�个新内
核版本。之��行 ``make oldnoconfig`` �调整它以适应新版本的需�，而��用
任何新的功能，因为那些功能也�能导致回归。


撰写并��报告
---------------

    *通过详细�述问题�开始编写报告。记得包括以下�目：您为�现而安装的最新
    内核版本�使用的Linux�行版以�关于如何�现该问题的说明。如果�能，将内
    核构建�置（.config）和 ``dmesg`` 的输出放在网上的�个地方，并链接到它。
    包�或上传所有其他�能相关的信�，如Oops的输出/截图或�自 ``lspci``
    的输出。一旦你写完了这个主�部分，请在上方�入一个正常长度的段�快速概
    述问题和影�。�在此之上添加一个简��述问题的��，以得到人们的阅读。
    现在给出一个更短的�述性标题或主题。然�就�以�MAINTAINERS文件告诉你的
    那样��或�交报告了，除�你在处�一个“高优先级问题�：它们需�按照下�
    “高优先级问题的特殊处��所述特别关照。*

现在你已�准备好了一切，是时候写你的报告了。上文�言中链接的三篇文档对如何
写报告�了部分解释。这就是为什么本文将��到一些基本的内容以� Linux 内核特
有的东西。

有一点是符�这两类的：你的报告中最关键的部分是标题/主题�第一��和第一段。
开�者�常会收到许多邮件。因此，他们往往�是花几秒钟的时间�览一下邮件，然
��决定继续下一�或仔细查看。因此，你报告的开头越好，有人研究并帮助你的机
会就越大。这就是为什么你应该暂时忽略他们，先写出详细的报告。;-)

�份报告都应��的事项
~~~~~~~~~~~~~~~~~~~~~~~~

详细�述你的问题是如何�生在你安装的新纯净内核上的。试�包�你之�写的和优
化过的分步说明，概述你和其他人如何�现这个问题；在�少数无法�现的情况下，
尽��述你�了什么�触�它。

还应包括其他人为了解该问题�其环境而�能需�的所有相关信�。实际需�的东西
在很大程度上�决于具体问题，但有些事项你总是应该包括在内：

 * ``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 <https://bugzilla.kernel.org/>`_ 上创建的工�……），
   并在你的报告中放上链接。�想情况下请使用�许这些文件�存很多年的地方，因
   为它们�能在很多年�对别人有用；例如 5 年或 10 年�，一个开�者正在修改
   一些代�，而这些代�正是为了修�你的问题。

 * 把文件放在一边，然�说明你会在他人回�时��独��。��记得报告�出去�，
   真正�到这一点就�以了。;-)

�供这些东西�能是明智的
~~~~~~~~~~~~~~~~~~~~~~~~~~

根�问题的��，你�能需��供更多的背景数�。这里有一些关于�供什么比较好
的建议：

 * 如果你处�的是内核的“warning��“OOPS�或“panic�，请包�它。如果你�能�制
   粘贴它，试�用netconsole网络终端远程跟踪或者至少�一张�幕的照片。

 * 如果问题�能与你的电脑硬件有关，请说明你使用的是什么系统。例如，如果你的
   显�有问题，请��它的制造商，显�的型�，以�使用的芯片。如果是笔记本电
   脑，请��它的型��称，但尽�确��义明确。例如“戴尔 XPS 13�就�很明确，
   因为它�能是 2012 年的那款，那款除了看起�和现在销售的没有什么��之外，
   两者没有任何共�之处。因此，在这�情况下，�加上准确的型�，例如 2019
   年内推出的 XPS 13 型�为“9380�或“7390�。�“�想 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`` `就是这样一个工具，它是音频/声
   音�系统开�者�供的  <https://www.alsa-project.org/wiki/AlsaInfo>`_ 。

这些例�应该会给你一些知识点，让你知�附上什么数��能是明智的，但你自己也
�想一想，哪些数�对别人会有帮助。��太担心忘记一些东西，因为开�人员会�
求�供他们需�的�外细节。但从一开始就把所有��的东西都�供出�，会增加别
人仔细查看的机会。


��部分：报告的开头
~~~~~~~~~~~~~~~~~~~~~~

现在你已�准备好了报告的详细部分，让我们进入最��的部分：开头几�。现在到
报告的最��，在你刚�写的部分之�加上类似“The detailed description:�（详细
�述）这样的内容，并在最���入两个新行。现在写一个正常长度的段�，大致概
述这个问题。去掉所有枯燥的细节，把�点放在读者需�知�的关键部分，以让人了
解这是怎么回事；如果你认为这个缺陷影�了很多用户，就�一下这点��引大家关
注。

�好这一点�，在顶部��入两行，写一��的摘�，快速解释报告的内容。之�你
�更加抽象，为报告写一个更短的主题/标题。

现在你已�写好了这部分，请花点时间�优化它，因为它是你的报告中最��的部分：
很多人会先读这部分，然��会决定是�值得花时间阅读其他部分。

现在就� :ref:`MAINTAINERS <maintainers>` 维护者文件告诉你的那样��或�交
报告，除�它是��概述的那些“高优先级问题�之一：在这�情况下，请先阅读下一
�节，然����报告。

高优先级问题的特殊处�
~~~~~~~~~~~~~~~~~~~~~~~~

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

**�常严�的缺陷** ：确�在主题或工�标题以�第一段中明显标出 severeness
（�常严�的）。

**回归** ：如果问题是一个回归，请在邮件的主题或缺陷跟踪器的标题中添加
[REGRESSION]。如果您没有进行二分，请至少注明您测试的最新主线版本（比如 5.7）
和出现问题的最新版本（比如 5.8）。如果您�功地进行了二分，请注明导致回归
的�交ID和主题。也请添加该�更的作者到你的报告中；如果您需�将您的缺陷�交
到缺陷跟踪器中，请将报告以�人邮件的形�转�给他，并注明报告�交地点。

**安全问题** ：对于这�问题，你将必须评估：如果细节被公开披露，是�会对其他
用户产生短期风险。如果�会，�需按照所述继续报告问题。如果有此风险，你需�
�微调整一下报告�程。

 * 如果 MAINTAINERS 文件指示您通过邮件报告问题，请��抄�任何公共邮件列表。

 * 如果你应该在缺陷跟踪器中�交问题，请确�将工�标记为“�有�或“安全问题�。
   如果缺陷跟踪器没有�供��报告�密性的方法，那就别想了，把你的报告以�人
   邮件的形���给维护者�。

在这两�情况下，都一定�将报告�到 MAINTAINERS 文件中“安全�络�部分列出的
地�。�想的情况是在��报告的时候直接抄�他们。如果您在缺陷跟踪器中�交了
报告，请将报告的文本转�到这些地�；但请在报告的顶部加上注释，表明您�交了
报告，并附上工�链接。

更多信�请��“Documentation/translations/zh_CN/admin-guide/security-bugs.rst�。


�布报告�的责任
------------------

    *等待别人的�应，继续推进事情，直到你能够接�这样或那样的结果。因此，请
    公开和�时地回应任何询问。测试�出的修�。积�地测试：至少�新测试�个
    新主线版本的首个候选版本（RC），并报告你的结果。如果出现拖延，就�好地
    �醒一下。如果你没有得到任何帮助或者未能满�，请试�自己帮助自己。*

如果你的报告�常优秀，而且你真的很幸�，那么�个开�者�能会立��现导致问
题的原因；然�他们�能会写一个补��修��测试它，并直接��给主线集�，�
时标记它以便以�回溯到需�它的稳定版和长期支�内核。那么你需��的就是回�
一�“Thank you very much�（�常感谢），然�在�布��上修�好的版本。

但这��想状况很少�生。这就是为什么你把报告拿出�之�工作�开始。你��的
事情�视情况而定，但通常会是下�列出的事情。但在深入研究细节之�，这里有几
件��的事情，你需�记�这部分的过程。


关于进一步互动的一般建议
~~~~~~~~~~~~~~~~~~~~~~~~~~

**总是公开回�** ：当你在缺陷跟踪器中�交问题时，一定�在那里回�，���下
�系任何开�者。对于邮件报告，在回�您收到的任何邮件时，总是使用“全部回��
功能。这包括带有任何你�能想�添加到你的报告中的�外数�的邮件：进入邮件应
用程�“已���文件夹，并在邮件上使用“全部回���回�报告。这�方法�以确�
公共邮件列表和其他所有�与者都能�时了解情况；它还能��邮件线程的完整性，
这对于邮件列表将所有相关邮件归为一类是�常��的。

�有两�情况�适�在缺陷跟踪器或“全部回��中�表评论：

 * 有人让你�下�东西。

 * 你被告知���一些东西，但注�到其中包�需��密的�感信�。在这�情况下，
   �以�下��给�求��的开�者。但�在工�或邮件中注明你是这么�的，这
   样其他人就知�你尊�了这个�求。

**在请求解释或帮助之�先研究一下** ：在这部分过程中，有人�能会告诉你用尚未
掌�的技能�一些事情。例如你�能会被�求使用一些你从未�说过的测试工具；或
者你�能会被�求在 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 <https://kernel.org/>`_ 在首页上列出了两个“稳定�版本，
你应该考虑切�到较新的版本，而忘掉较旧的版本：对它的支��能很快就会结�。
然�，它将被标记为“生命周期结��（EOL）。达到这个程度的版本线�然会在
`kernel.org <https://kernel.org/>`_ 首页上被显示一两周，但�适�用于测试和
报告。

�索稳定版邮件列表
~~~~~~~~~~~~~~~~~~~

    *检查Linux稳定版邮件列表中的现有报告。*

也许你所�临的问题已�被�现，并且已�或�将被修�。因此，请在 `Linux 稳定
版邮件列表的档案 <https://lore.kernel.org/stable/>`_ 中�索类似问题的报告。
如果你找到任何匹�的问题，�以考虑加入讨论，除�修�工作已�完�并计划很快
得到应用。

用最新版本�现问题
~~~~~~~~~~~~~~~~~~~

    *从特定的版本线安装最新版本作为纯净内核。确�这个内核没有被污染，并且�
    然存在问题，因为问题�能已�在那里被修�了。*

在投入更多时间到这个过程中之�，你�检查这个问题是�在你关注的版本线的最新
版本中已�得到了修�。这个内核需�是纯净的，在问题�生之��应该被污染，正
如上�已�在测试主线的过程中详细介�过的一样。

您是�是第一次注�到供应商内核的回归？供应商的更改�能会�生�化。你需��新
检查排除�这个问题。当您从5.10.4-vendor.42更新到5.10.5-vendor.43时，记录��
的信�。然�在测试了�一段中所述的最新5.10版本之�，检查Linux 5.10.4的普通版本
是�也�以正常工作。如果问题在那里出现，那就�符�上游回归的�件，您需�切�
回主�步指��报告问题。

报告回归
~~~~~~~~~~

    *�Linux稳定版邮件列表��一个简短的问题报告(stable@vger.kernel.org)。
    大致�述问题，并解释如何�现。讲清楚首个出现问题的版本和最�一个工作正常
    的版本。然�等待进一步的指示。*

当报告在稳定版或长期支�内核线内�生的回归（例如在从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�然存在故障。

�一段基本粗略地概述了“二分�方法。一旦报告出�，您�能会被�求�一个正确的
报告，因为它�许精确地定�导致问题的确切更改（然�很容易被��以快速修�问题）。
因此如果时间�许，考虑立�进行适当的二分。有关如何详细信�，请�阅“对回归的
特别关照�部分和文档“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst�。


“报告仅在旧内核版本线中�生的问题�的�考
----------------------------------------

本节详细介�了如果无法用主线内核�现问题，但希望在旧版本线（�称稳定版内核和
长期支�内核）中修�问题时需�采�的步骤。

有些修�太��
~~~~~~~~~~~~~~~

    *请�好准备，接下�的几个步骤�能无法在旧版本中解决问题：修��能太大或
    太冒险，无法移�到那里。*

�使是微�的�看似明显的代��化，有时也会带�新的�完全�想�到的问题。稳
定版和长期支�内核的维护者�常清楚这一点，因此他们�对这些内核进行符�
“Documentation/translations/zh_CN/process/stable-kernel-rules.rst�中所列出的
规则的修改。

��或有风险的修改�符��件，因此�能应用于主线。其他的修�很容易被回溯到
最新的稳定版和长期支�内核，但是风险太大，无法集�到旧版内核中。所以�注�
你所希望的修��能是那些�会被回溯到你所关心的版本线的修�之一。在这�情况
下，你将别无选择，�么��这个问题，�么切�到一个较新的 Linux 版本，除�你
想自己把修�补�应用到你的内核中。

通用准备
~~~~~~~~~~

    *执行上�“报告仅在旧内核版本线中�生的问题�一节中的�三个步骤。*

您需�执行本指��一节中已��述的几个步骤。这些步骤将让您：

 * 检查内核开�人员是��然维护您关心的Linux内核版本行。

 * 在Linux稳定邮件列表中�索退出的报告。

 * 检查最新版本。


检查代�历�和�索现有的讨论
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    *在Linux内核版本控制系统中�索修�主线问题的更改，因为它的�交消��能
    会告诉你修�是�已�计划好了支�。如果你没有找到，�索适当的邮件列表，
    寻找讨论此类问题或�行评议�能修�的帖�；然�检查讨论是�认为修��适
    �支�。如果支�根本�被考虑，加入最新的讨论，询问是�有�能。*

在许多情况下，你所处�的问题会�生在主线上，但已在主线上得到了解决。修正它
的�交也需�被回溯�能解决这个问题。这就是为什么你��索它或任何相关讨论。

 * 首先�试在存放 Linux 内核�代�的 Git 仓库中找到修�。你�以通过
   `kernel.org 上的网页
   <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_
   或 `GitHub 上的镜� <https://github.com/torvalds/linux>`_ �实现；如果你
   有一个本地克隆，你也�以在命令行用 ``git log --grep=<pattern>`` ��索。

   如果你找到了修�，请查看�交消�的尾部是�包�了类似这样的“稳定版标签�：

          Cc: <stable@vger.kernel.org> # 5.4+

   �上�这行，开�者标记了安全修��以回传到 5.4 �以�的版本。大多数情况
   下，它会在两周内被应用到那里，但有时需�更长的时间。

 * 如果�交没有告诉你任何东西，或者你找�到修�，请�找找关于这个问题的讨论。
   用你最喜欢的�索引擎�索网络，以� `Linux kernel developers mailing
   list 内核开�者邮件列表 <https://lore.kernel.org/lkml/>`_ 的档案。也�以
   阅读上�的 `定�导致问题的内核区域` 一节，然�按照说明找到导致问题的�系
   统：它的缺陷跟踪器或邮件列表存档中�能有你�找的答案。

 * 如果你看到了一个计划的修�，请按上所述在版本控制系统中�索它，因为�交�
   能会告诉你是��以进行回溯。

   * 检查讨论中是�有任何迹象表明，该修�程��能风险太大，无法回溯到你关心
     的版本线。如果是这样的�，你必须��这个问题，或者切�到应用了修�的内
     核版本线。

   * 如果修�的问题未包�稳定版标签，并且没有讨论过回溯问题，请加入讨论：如
     果�适的�，请��你所�对的问题的版本，以�你希望看到它被修�。


请求建议
~~~~~~~~~

    *��的步骤之一应该会给出一个解决方案。如果�未能�功，请��能引起问题
    的�系统的维护人员询问建议；抄�特定�系统的邮件列表以�稳定版邮件列表。*

如果��的三个步骤都没有让你更接近解决方案，那么�剩下一个选择：请求建议。
在你�给�能是问题根�的�系统的维护者的邮件中这样�；抄��系统的邮件列表
以�稳定版邮件列表（stable@vger.kernel.org）。


为什么有些问题在报告�没有任何回应或�未解决？
===============================================

当� Linux 开�者报告问题时，�注��有“高优先级的问题�（回归�安全问题�严
�问题）�一定会得到解决。如果维护者或其他人都失败了，Linus Torvalds 他自己
会确�这一点。他们和其他内核开�者也会解决很多其他问题。但是�知�，有时他
们也会�能或�愿帮忙；有时甚至没有人�报告给他们。

最好的解释就是那些内核开�者常常是在业余时间为 Linux 内核�出贡献。内核中的
�少驱动程�都是由这样的程�员编写的，往往�是因为他们想让自己的硬件�以在
自己喜欢的�作系统上使用。

这些程�员大多数时候会很��修�别人报告的问题。但是没有人�以强迫他们这样
�，因为他们是自愿贡献的。

还有一些情况下，这些开�者真的很想解决一个问题，但��能解决：有时他们缺�
硬件编程文档�解决问题。这�情况往往由于公开的文档太简陋，或者驱动程�是通
过逆�工程编写的。

业余开�者迟早也会��关心�驱动。也许他们的测试硬件�了，被更高级的玩��
代了，或者是太�了以至于�能在计算机�物馆里找到。有时开�者根本就�关心他
们的代�和 Linux 了，因为在他们的生活中一些��的东西�得更��了。在�些情
况下，没有人愿�接手维护者的工作——也没有人�以被强迫，因为对 Linux 内核的贡
献是自愿的。然而被�弃的驱动程��然存在于内核中：它们对人们�然有用，删除
它们�能导致回归。

对于那些为 Linux 内核工作而获得报酬的开�者�说，情况并没有什么��。这些人
现在贡献了大部分的�更。但是他们的雇主迟早也会�止关注他们的代�或者让程�
员专注于其他事情。例如，硬件厂商主�通过销售新硬件�赚钱；因此，他们中的�
少人并没有投入太多时间和精力�维护他们多年�就�止销售的东西的 Linux 内核驱
动。�业级 Linux �行商往往�续维护的时间比较长，但在新版本中往往会把对�旧
和稀有硬件的支�放在一边，以�制范围。一旦公�抛弃了一些代�，往往由业余贡
献者接手，但正如上��到的：他们迟早也会放下代�。

优先级是一些问题没有被修�的�一个原因，因为维护者相当多的时候是被迫设置这
些优先级的，因为在 Linux 上工作的时间是有�的。对于业余时间或者雇主给予他们
的开�人员用于上游内核维护工作的时间也是如此。有时维护人员也会被报告淹没，
�使一个驱动程�几乎完美地工作。为了�被完全缠�，程�员�能别无选择，�能
对问题报告进行优先级排�而拒�其中的一些报告。

�过这些都�用太过担心，很多驱动都有积�的维护者，他们对尽�能多的解决问题
相当感兴趣。


结�语
=======

与其他�费/自由&开�软件（Free/Libre & Open Source Software，FLOSS）相比，
� Linux 内核开�者报告问题是很难的：这个文档的长度和��性以�字里行间的内
涵都说明了这一点。但目�就是这样了。这篇文字的主�作者希望通过记录现状�为
以�改善这�状况打下一些基础。