Add translation zh_CN/admin-guide/reporting-issues.rst, and link it to
zh_CN/admin-guide/index.rst.
Signed-off-by: Wu XiangCheng <bobwxc@xxxxxxxx>
---
.../translations/zh_CN/admin-guide/index.rst | 5 +
.../zh_CN/admin-guide/reporting-issues.rst | 1269 +++++++++++++++++
2 files changed, 1274 insertions(+)
create mode 100644 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
index a716a48c8018..fe2abc3fec86 100644
--- a/Documentation/translations/zh_CN/admin-guide/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/index.rst
@@ -32,6 +32,11 @@ Todolist:
下面的一组文档，针对的是试图跟踪问题和bug的用户。
+.. toctree::
+ :maxdepth: 1
+
+ reporting-issues
+
Todolist:
reporting-bugs
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
new file mode 100644
index 000000000000..2805c1a03cd5
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst
@@ -0,0 +1,1269 @@
+.. 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: :doc:`../../../admin-guide/reporting-issues`
+
+:译者:
+
+ 吴想成 Wu XiangCheng <bobwxc@xxxxxxxx>
+
+.. important::
+
+ 本文档将取代“Documentation/admin-guide/reporting-bugs.rst”。主要的工作
+ 已经完成，你可以自由地按照其指示来向Linux内核开发者报告问题。但请留意，
+ 下面的文字还需要一些润色和校审。现阶段它被合并到Linux内核源代码中，以使
+ 这个过程更容易，并增加文本的可见性。
+
+ 因此，任何文本改进或其他反馈都是非常受欢迎的。请将它发送到“Thorsten
+ Leemhuis <linux@xxxxxxxxxxxxx>”和“Jonathan Corbet <corbet@xxxxxxx>”，
+ 最好抄送“Linux内核邮件列表（LKML） <linux-kernel@xxxxxxxxxxxxxxx> ”和
+ “Linux内核文档列表 <linux-doc@xxxxxxxxxxxxxxx>”。
+
+ 文本中仍需改进或讨论的区域包含了指出剩余问题的提示；它们都以“FIXME”开头，
+ 这样更容易找到。（译者注：此注释皆指英文文本）
+
+
+报告问题
++++++++++
+
+
+简明指南（亦即 太长不看）
+==========================
+
+如果您同时面临多个Linux内核的问题，请分别向开发人员报告每个问题。请尽力尝试
+猜测哪个内核部分可能导致问题。查看 :ref:`MAINTAINERS <maintainers>` 文件，
+了解开发人员希望如何被告知有关问题。请注意 `bugzilla.kernel.org
+<https://bugzilla.kernel.org/>`_ 很少用到，因为几乎在所有情况下，报告都需要
+通过电子邮件发送!
+
+请彻底检查目标是否已有此报告；也请搜索LKML（内核邮件列表）档案和网络。如果
+找到匹配的，请加入现有的讨论。如果没有找到，请安装 `最新的Linux主线内核
+<https://kernel.org/>`_ 。确保其是纯净的，也就是没有打补丁或使用附加的内核
+模块。还要确保内核运行在一个正常的环境中，并且在问题发生之前没有受到污染。
+
+如果您可以用主线内核复现您的问题，那么请向您之前确定的目标发送一个报告。确
+保它包括所有相关信息，在导致回归（regression）的情况下应该提到导致它的变化，
+这通常可以通过二分法找到。还要确保报告能够送达给所有需要了解它的人，例如
+安全团队、稳定版维护者或导致回归的补丁开发人员。一旦发送报告，请回答可能出
+现的任何问题，并尽可能提供帮助。这包括继续工作：每次发布新的rc1主线内核时，
+检查这个问题是否仍然存在，并在初始报告中添加状态更新。
+
+如果你无法在主线内核中复现这个问题，那么请考虑继续使用它；如果您想使用较旧
+的版本线，并希望看到它在那里得到修复，那么首先要确定它仍受支持。将其最新版
+本安装为纯净内核。如果你不能在那里复现这个问题，试着在主线中或之前的任何讨
+论中找到修复它的提交：这些讨论经常会提到是否有计划支持或认为支持太复杂。如
+果没有讨论支持，可询问是否有可能。如果您没有发现任何提交或之前的讨论，请参
+阅Linux-stable邮件列表存档中现有的报告，因为它可能是特定版本线的回归。如果
+是，就像在主线中报告问题一样报告它（包括二分结果）。
+
+如果仍没有解决方案，请在子系统的邮件列表中寻求建议。
+
+
+如何向内核维护人员报告问题的逐步指南
+=====================================
+
+上面的简明指南概述了如何向Linux内核开发人员报告问题。对于已经熟悉向自由和开
+源软件（FLOSS）项目报告问题的人来说，这可能是他们所需要的全部内容。对于其他
+人，本部分更为详细，并一步一步地描述。为了便于阅读，它仍然尽量简洁，并省略
+了许多细节；这些在逐步指南后的参考章节中进行了描述，该章节更详细地解释了每
+个步骤。
+
+注意：本节涉及的方面比简明指南多，顺序也稍有不同。这符合你的利益，以确保您
+尽早意识到看起来像Linux内核毛病的问题可能实际上是由其他原因引起的。这些步骤
+可以确保你最终不会觉得在这一过程中投入的时间是浪费：
+
+ * 停止阅读本文档并将问题报告给您的供应商，除非您已经运行了最新的主线内核或
+ 愿意安装它。这个内核不能以任何方式被修改或增强，因此被认为是“纯净的”。
+
+ * 看看你正在处理的问题是否为回归问题、安全问题或非常严重的问题：这些都是需
+ 要在接下来的一些步骤中特别处理的“高优先级问题”。
+
+ * 当问题发生时，检查您的内核是否被“污染”，因为使内核设置这个标志的事件可能
+ 会导致您面临的问题。
+
+ * 定位可能引起问题的驱动程序或内核子系统。找出其开发人员期望的报告的方式和
+ 位置。注意：大多数情况下不会是 bugzilla.kernel.org，因为问题通常需要通
+ 过邮件发送给维护人员和公共邮件列表。
+
+ * 在缺陷追踪器或问题相关邮件列表的存档中彻底搜索可能与您的问题匹配的报告。
+ 还要检查您是否能在您喜爱的网络搜索引擎或Linux内核邮件列表（LKML）存档中
+ 找到一些信息。如果您发现了什么，请加入讨论，而不是发送新的报告。
+
+ * 创建一个新的备份，并将系统修复和恢复工具放在手边。
+
+ * 确保您的系统不会通过动态构建额外的内核模块来增强其内核，像DKMS这样的解决
+ 方案可能在您不知情的情况下就在本地进行了这样的工作。
+
+ * 确保不是内核环境导致了您面临的问题。
+
+ * 粗略地写下如何重现这个问题。如果您同时处理多个问题，请为每个问题单独写注
+ 释，并确保它们在新启动的系统上独立出现。这是必要的，因为每个问题都需要分
+ 别报告给内核开发人员，除非它们严重纠缠在一起。
+
+在完成这些准备之后，你将进入主要部分：
+
+ * 安装最新的Linux主线内核：这是所有问题首先得到修复的地方，因为它是内核开
+ 发人员主要关注的版本线。在某些情况下，使用最新的Linux稳定版内核进行测试
+ 和报告也是一个可以接受的替代方案，例如在合并窗口期间；但在这段时间里，你
+ 可能想要暂停努力直到它结束。
+
+ * 确保您刚刚安装的内核在运行时不会“污染”自己。
+
+ * 在您刚刚安装的内核中复现这个问题。如果它没有出现，请查看只发生在稳定版和
+ 长期支持内核的问题的说明。
+
+ * 优化你的笔记：试着找到并写出最直接的复现问题的方法。确保最终结果包含所有
+ 重要的细节，同时让第一次听说的人容易阅读和理解。如果您在此过程中学到了一
+ 些东西，请考虑再次搜索关于该问题的现有报告。
+
+ * 如果失败包含堆栈转储（stack dump），例如Oops所做的，则请考虑对其进行解码
+ 以找到出错的代码行。
+
+ * 如果您的问题是回归问题，请尽可能缩小引入问题时的范围。
+
+ * 通过详细描述问题来开始编写报告。记得包括以下条目：您为复现而安装的最新内
+ 核版本、使用的Linux发行版以及关于如何复现该问题的说明。如果可能，将内核
+ 构建配置（.config）和 ``dmesg`` 的输出放在网上的某个地方，并链接到它。包
+ 含或上传所有其他可能相关的信息，如Oops的输出/截图或来自 ``lspci`` 的输出
+ 。一旦你写完了这个主要部分，请在上方插入一个正常长度的段落快速概述问题和
+ 影响。再在此之上添加一个简单描述问题的句子，以得到人们的阅读。现在给出一
+ 个更短的描述性标题或主题。然后就可以像MAINTAINERS文件告诉你的那样发送或
+ 提交报告了，除非你在处理一个“高优先级问题”：它们需要按照下面“高优先级问
+ 题的特殊处理”所述特别关照。
+
+ * 等待别人的反应，继续推进事情，直到你能够接受这样或那样的结果。因此，请公
+ 开和及时地回应任何询问。测试提出的修复。积极地测试：至少重新测试每个新主
+ 线版本的首个候选版本（RC），并报告你的结果。如果出现拖延，就友好地提醒一
+ 下。如果你没有得到任何帮助或者未能满意，请试着自己帮助自己。
+
+
+报告只发生在较旧内核版本线的问题
+----------------------------------
+
+如果您尝试了如上所述的最新主线内核，但未能重现您的问题，那么本节是为您准备
+的；若您同时希望看到在旧版本线或定期根据新的稳定或长期发行版重新编写的供应
+商内核中修复这个问题，请遵循以下步骤：
+
+ * 请做好准备，接下来的几个步骤可能无法在旧版本中解决问题：修复可能太大或太
+ 冒险，无法移植到那里。
+
+ * 检查内核开发人员是否仍然维护你关心的Linux内核版本线：去 `kernel.org
+ <https://kernel.org/>`_ 的首页，确保此特定版本线的最新版没有“[EOL]”标记。
+
+ * 检查Linux稳定版邮件列表中的现有报告。
+
+ * 从特定的版本线安装最新版本作为纯净内核。确保这个内核没有被污染，并且仍然
+ 存在问题，因为问题可能已经在那里被修复了。
+
+ * 在Linux内核版本控制系统中搜索修复主线问题的更改，因为它的提交消息可能会
+ 告诉你修复是否已经计划好了支持。如果你没有找到，搜索适当的邮件列表，寻找
+ 讨论此类问题或同行评议可能修复的帖子；然后检查讨论是否认为修复不适合支持。
+ 如果支持根本不被考虑，加入最新的讨论，询问是否有可能。
+
+ * 通过安装您所关心的版本线的首个发行版，检查您是否正在处理主线中从未出现过
+ 的回归。如果这个问题没有出现，你基本上需要用此版本来报告这个问题，就像你
+ 用主线报告一个问题一样（见上面）。理想情况下，在该主题和两个相关提交ID的
+ 帮助下，通过对网上现有报告的搜索，将能二分问题。如果还是一无所获，那就写
+ 份报告；将报告抄送或转发给稳定版维护者、稳定版邮件列表和编写更改的人。如
+ 果您发现了导致问题的更改，请包含缩短的提交ID。
+
+ * 前面的步骤之一应该会给出一个解决方案。如果仍未能成功，请向可能引起问题的
+ 子系统的维护人员询问建议；抄送特定子系统的邮件列表以及稳定版邮件列表
+
+
+参考章节：向内核维护者报告问题
+===============================
+
+上面的详细指南简要地列出了所有主要步骤，这对大多数人来说应该足够了。但有时，
+即使是有经验的用户也可能想知道如何实际执行这些步骤之一。这就是本节的目的，
+因为它将提供关于上述每个步骤的更多细节。请将此作为参考文档：可以从头到尾
+阅读它。但它主要是为了浏览和查找如何实际执行这些步骤的详细信息。
+
+在深入挖掘细节之前，我想先给你一些一般性建议：
+
+ * 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内核开发人员不喜欢花时间处理他们维护的源代码中根本
+不会发生的问题的报告：这只会浪费每个人的时间，包括您的时间。这就是为什么你
+之后必须用最新的“纯净”内核来测试你的问题：一个直接从 `kernel.org
+<https://kernel.org/>`_ 上获取的Linux源代码构建的内核，没有以任何方式进行修
+改或增强。
+
+从内核开发的角度来看，几乎所有设备（计算机、笔记本电脑、智能手机、路由器……）
+使用的内核和大多数Linux发行版提供的内核都很古老，并且经过了大量修改。因此，
+它们不具备向Linux内核开发人员报告问题的资格：您在此类内核中面临的问题可能
+已经修复，或者是由更改或添加引起的，即使它们看起来很小或完全不相关。这就是
+为什么这些内核的问题需要报告给分发它的供应商。它的开发人员应该查看报告，如
+若发现是上游问题，直接向上游修复它或在那里报告它。在实践中，这有时行不通。
+如果是这种情况，您可能想要绕过供应商，自己安装最新的主线内核，并报告本文档
+中概述的问题；只是要确保使用真正新鲜的内核（见下文）。
+
+
+.. note::
+
+ FIXME：我们应该接受与“纯净内核”映像非常接近的问题报告吗？但是什么时候它
+ 们足够接近，又该如何用文字表达呢？也许像这样？
+
+ *注意：一些Linux内核开发人员接受来自已知接近上游的供应商内核的报告。例
+ 如Debian GNU/Linux Sid或Fedora Rawhide的内核，它们通常紧跟主线，只携带
+ 几个补丁。因此，其中之一的报告可能会被需要处理它的开发人员所接受。但如
+ 果他们真的这么做了，很大程度上取决于单个开发人员和手头的问题。这就是为
+ 什么安装主线纯净内核是安全的选择。*
+
+ *Arch Linux，其他Fedora发行版，以及openSUSE Tumbleweed通常使用非常接近
+ 上游的稳定版内核。一些开发人员也会从他们那里接受缺陷报告。但请注意，通
+ 常应该避免使用稳定版内核来报告问题，而应使用主线内核（见下文）。*
+
+ 还有其他主要的Linux发行版应该在这里提到吗？
+
+
+高优先级的问题？
+-----------------
+
+ *看看你正在处理的问题是否是回归问题、安全问题或非常严重的问题：这些都是
+ 需要在接下来的一些步骤中特别处理的“高优先级问题”。*
+
+Linus Torvalds和主要的Linux内核开发人员希望看到一些问题尽快得到解决，因此在
+报告过程中有一些“高优先级问题”的处理略有不同。有三种情况符合条件:回归、安全
+问题和非常严重的问题。
+
+如果在旧版本的Linux内核中工作的东西不能在新版本的Linux内核中工作，或者某种
+程度上在新版本的Linux内核中工作得更差，那么你就需要处理“回归”。因此，当一个
+在Linux 5.7中表现良好的WiFi驱动程序在5.8中表现不佳或根本不能工作时，这是一
+种回归。如果应用程序在新的内核中出现不稳定的现象，这也是一种回归，这可能是
+由于内核和用户空间之间的接口（如procfs和sysfs）发生不兼容的更改造成的。显著
+的性能降低或功耗增加也可以称为回归。但是请记住:新内核需要使用与旧内核相似的
+配置来构建（参见下面如何实现这一点）。这是因为内核开发人员在实现新特性时有
+时无法避免不兼容性；但是为了避免回归，这些特性必须在构建配置期间显式地启用。
+
+什么是安全问题留给您自己判断。在继续之前，请考虑阅读
+“Documentation/admin-guide/security-bugs.rst”，因为它提供了如何最恰当地处理
+安全问题的额外细节。
+
+当发生了完全无法接受的糟糕事情时，此问题就是一个“非常严重的问题”。例如，
+Linux内核破坏了它处理的数据或损坏了它运行的硬件。当内核突然显示错误消息
+（“kernel panic”）并停止工作，或者根本没有任何停止信息时，您也在处理一个严重
+的问题。注意：不要混淆“panic”（内核停止自身的致命错误）和“Oops”（可恢复错误），
+因为显示后者之后内核仍然在运行。
+
+
+检查“污染”标志
+----------------
+
+ *当问题发生时，检查您的内核是否被“污染”，因为使内核设置这个标志的事件可
+ 能会导致您面临的问题。*
+
+当某些可能会导致看起来完全不相关的后续错误的事情发生时，内核会用“污染
+（taint）”标志标记自己。如果您的内核受到污染，那么您面临的可能是这样的错误。
+因此在投入更多时间到这个过程中之前，尽早排除此情况可能对你有好处。这是这个
+步骤出现在这里的唯一原因，因为这个过程稍后会告诉您安装最新的主线内核；然后
+您将需要再次检查污染标志，因为当它出问题的时候内核报告会关注它。
+
+在正在运行的系统上检查内核是否污染非常容易：如果 ``cat /proc/sys/kernel/tainted``
+返回“0”，那么内核没有被污染，一切正常。在某些情况下无法检查该文件；这就是
+为什么当内核报告内部问题（“kernel bug”）、可恢复错误（“kernel Oops”）或停止
+操作前不可恢复的错误（“kernel panic”）时，它也会提到污染状态。当其中一个错
+误发生时，查看打印的错误消息的顶部，搜索以“CPU:”开头的行。如果发现问题时内
+核未被污染，那么它应该以“Not infected”结束；如果你看到“Tainted:”且后跟一些
+空格和字母，那就被污染了。
+
+如果你的内核被污染了，请阅读“Documentation/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”）。
+
+
+定位导致问题的内核区域
+------------------------
+
+ *定位可能引起问题的驱动程序或内核子系统。找出其开发人员期望的报告的方式
+ 和位置。注意：大多数情况下不会是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@xxxxxxxxxxx>
+ Mailing list: ath10k@xxxxxxxxxxxxxxxxxxx
+ 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。
+
+
+.. note::
+
+ FIXME: 旧的文本对 bugzilla.kernel.org 采取了完全不同的方法，因为提到它是
+ 发布人们不知道如何联系相关人员的问题的地方。新的文本很少提到它；而当它像
+ 这里一样提到时，是为了警告用户这往往是一个错误的地方。
+
+ 之所以选择这种方法，是因为本文的主要作者注意到有不少（甚至很多？）用户在
+ bugzilla 上提交的 bug 没有得到回复。这也是意料之中的事情，因为不少（很多？
+ 大多数？）维护者甚至在他们的子系统有报告提交时都没有得到通知。而报告得
+ 不到任何回复让用户非常烦恼，甚至可能会让他们生气。改进 bugzilla.k.o 确实
+ 是一个选择，但在 2017 年的内核和维护者峰会上，大家一致同意先走这条路（很
+ 抱歉花了这么长时间）：这更容易实现，争议也更小，因为给已经超负荷工作的维
+ 护者增加额外的负担不太可能得到好的效果。
+
+
+在这种情况下，你必须寻找以“Mail:”开头的行。这些行提到了特定代码的维护者的名
+字和电子邮件地址。也可以查找以“Mailing list:”开头的行，它告诉你开发代码的公
+共邮件列表。你的报告之后需要通过邮件发到这些地址。另外，对于所有通过电子邮
+件发送的问题报告，一定要抄送 Linux Kernel Mailing List（LKML）
+<linux-kernel@xxxxxxxxxxxxxxx>。在以后通过邮件发送问题报告时，不要遗漏任何
+一个邮件列表!维护者都是大忙人，可能会把一些工作留给子系统特定列表上的其他开
+发者；而 LKML 很重要，因为需要一个可以找到所有问题报告的地方。
+
+
+.. note::
+
+ FIXME: 上面一节告诉用户一定要抄送 LKML。如今，它是一种“万能的”列表，几乎
+ 没有人密切关注它。因此，似乎应该“全入”，让人们把他们的报告发到这里来，因
+ 为所有的东西（报告、修正......）都可以在同一个地方找到（至少对于所有通过
+ 邮件发送的报告和所有抄送 LKML 的子系统）。
+
+ 相关信息：我们是否应该建立一个类似“linux-issues@xxxxxxxxxxxxxxx”的邮件列
+ 表，并告诉上述的用户在报告问题时一定要抄送？这样一来，报告者就可以在一个
+ 中心化的位置搜索现有的报告（至少是通过邮件报告的问题），而不会把常规的
+ 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@xxxxxxxxxxx> (supporter:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
+ Another S. Human <asomehuman@xxxxxxxxxxx> (maintainer:NETWORKING DRIVERS)
+ ath10k@xxxxxxxxxxxxxxxxxxx (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
+ linux-wireless@xxxxxxxxxxxxxxx (open list:NETWORKING DRIVERS (WIRELESS))
+ netdev@xxxxxxxxxxxxxxx (open list:NETWORKING DRIVERS)
+ linux-kernel@xxxxxxxxxxxxxxx (open list)
+
+不要把你的报告发给所有的人。发送给维护者，脚本称之为“supporter:”；另外抄送
+代码最相关的邮件列表，以及 Linux 内核邮件列表（LKML）。在此例中，你需要将报
+告发送给 “Some Human <shuman@xxxxxxxxxxx>” ，并抄送
+“ath10k@xxxxxxxxxxxxxxxxxxx”和“linux-kernel@xxxxxxxxxxxxxxx”。
+
+注意：如果你用 git 克隆了 Linux 源代码，你可能需要用--git 再次调用
+get_maintainer.pl。脚本会查看提交历史，以找到最近哪些人参与了相关代码的编写，
+因为他们可能会提供帮助。但要小心使用这些结果，因为它很容易让你误入歧途。
+例如，这种情况常常会发生在很少被修改的地方（比如老旧的或未维护的驱动程序）：
+有时这样的代码会在树级清理期间被根本不关心此驱动程序的开发者修改。
+
+
+搜索现有报告
+-------------
+
+ *在缺陷追踪器或问题相关邮件列表的存档中彻底搜索可能与您的问题匹配的报告。
+ 还要检查您是否能在您喜爱的网络搜索引擎或Linux内核邮件列表（LKML）存档
+ 中找到一些信息。如果您发现了什么，请加入讨论，而不是发送新的报告。*
+
+报告一个别人已经提出的问题，对每个人来说都是浪费时间，尤其是作为报告人的你。
+所以彻底检查是否有人已经报告了这个问题，这对你自己是有利的。因此，不要草
+草完成报告过程中的这一步。请先花 30 到 60 分钟甚至更多的时间，来为你和他人
+节省更多时间和减少麻烦麻烦。
+
+搜索的最佳之处是缺陷跟踪器或者你需要提交报告的邮件列表。你可以在
+`lore.kernel.org <https://lore.kernel.org/>`_ 上找到很多这样的列表，但是有
+些在其他的地方。例如上一步中使用的 ath10k WiFi 驱动就是如此。但是你可以在网
+上很容易找到这些列表的存档。例如搜索“archive ath10k@xxxxxxxxxxxxxxxxxxx”，
+很快就能找到 `Info page for the ath10k mailing list（ath10k邮件列表信息页
+面） <https://lists.infradead.org/mailman/listinfo/ath10k>`_ 邮件列表的信息
+页面，在顶部链接到它的 `list archives（列表存档）
+<https://lists.infradead.org/pipermail/ath10k/>`_ 。
+
+遗憾的是，这个列表和其他不少列表都缺少搜索存档的功能。在这种情况下，使用纯
+净的互联网搜索引擎，并添加类似“site:lists.infadead.org/pipermail/ath10k/”这
+样的搜索条件，这会把结果限制在该链接中的档案。
+
+也请进一步搜索网络和 `Linux Kernel Mailing List (LKML) archives
+<https://lore.kernel.org/lkml/>`_ ，因为真正的罪魁祸首可能在其他子系统中。
+在 `bugzilla.kernel.org <https://bugzilla.kernel.org/>`_ 中搜索也是一个好
+主意，但是如果你在那里发现了什么，请知晓：大多数子系统期望得到报告的地方不
+同，因此你在那里发现的那些可能还没有到达负责相关子系统的人手中。尽管如此，
+那里的数据可能会提供有价值的见解。
+
+如果搜索结果实在太多，可以考虑让你的搜索引擎将搜索时间范围限制在过去的一个
+月或一年。而且无论你在哪里搜索，一定要用恰当的搜索关键词；也要变化几次关键
+词。同时，试着从别人的角度看问题：这将帮助你想出其他的关键词。另外，一定不
+要同时使用过多的关键词。记住搜索时要同时尝试包含和不包含内核驱动程序的名称
+或受影响的硬件组件的名称等信息。但其确切的品牌名称（比如说“华硕红魔 Radeon
+RX 5700 XT Gaming OC”）往往帮助不大，因为它太具体了。相反，尝试搜索术语，如
+型号（Radeon 5700 或 Radeon 5000）和核心代号（“Navi”或“Navi10”），以及包含
+和不包含其制造商（“AMD”）。
+
+如果你发现了关于你的问题的现有报告，请加入讨论，因为你可能会提供有价值的额
+外信息。这一点很重要，即使是在修复程序已经准备好或处于最后阶段，因为开发人
+员可能会寻找能够提供额外信息或测试建议修复程序的人。跳到“发布报告后的责任”
+一节，了解有关如何正确参与的细节。
+
+
+为紧急情况做好准备
+-------------------
+
+ *创建一个全新的备份，并将系统修复和还原工具放在手边*
+
+我得提醒您，您正在和计算机打交道，计算机有时会出现意想不到的事情，尤其是当
+您折腾其操作系统的内核等关键部件时。而这就是你在这个过程中要做的事情。因此，
+一定要创建一个全新的备份；还要确保你手头有修复或重装操作系统的所有工具，
+以及恢复备份所需的一切。
+
+
+确保你的内核不会被增强
+------------------------
+
+ *确保您的系统不会通过动态构建额外的内核模块来增强其内核，像DKMS这样的解
+ 决方案可能在您不知情的情况下就在本地进行了这样的工作。*
+
+当报告一个问题时，你的内核必须是“纯净的”，一旦加载了一个不是从编译内核映像
+的源代码构建的内核模块，它就不再是纯净的内核了。这就是为什么你需要通过移除
+或禁用像 akmods 和 DKMS 这样的机制来确保你的 Linux 内核保持纯净：这些机制可
+能会自动构建额外的内核模块，例如当你首次启动到一个新安装的 Linux 内核时。在
+删除它们和它们安装的任何模块后重新启动。
+
+注意，你可能不知道你的系统正在使用这些解决方案之一：当你安装 Nvidia 专有图
+形驱动程序、VirtualBox 或其他需要 Linux 内核以外的模块支持的软件时，它们通
+常会静默设置。这就是为什么你可能需要卸载这些软件的软件包，以摆脱任何第三方
+内核模块。
+
+
+确保环境健康
+--------------
+
+ *确保不是内核所处环境导致了你所面临的问题。*
+
+看起来很像内核问题的问题有时是由构建或运行时环境引起的。很难完全排除这种问
+题，但你应该尽量减少这种问题：
+
+ * 构建内核时，请使用经过验证的工具，因为编译器或二进制文件中的错误可能会导
+ 致内核出现错误行为。
+
+ * 确保您的计算机组件在其设计规范内运行；这对处理器、内存和主板尤为重要。因
+ 此，当面临潜在的内核问题时，停止低电压或超频。
+
+ * 尽量确保不是硬件故障导致了你的问题。例如，内存损坏会导致大量的问题，这些
+ 问题会表现为看起来像内核问题。
+
+ * 如果你正在处理一个文件系统问题，你可能需要用 ``fsck`` 检查一下文件系统，
+ 因为它可能会以某种方式被损坏，从而导致无法预期的内核行为。
+
+ * 在处理回归问题时，要确保没有在更新内核的同时发生了其他变化。例如，这个问
+ 题可能是由同时更新的其他软件引起的。也有可能是在你第一次重启进入新内核时，
+ 某个硬件巧合地坏了。更新系统 BIOS 或改变 BIOS 设置中的某些内容也会导致
+ 一些看起来很像内核回归的问题。
+
+
+记录如何重现问题
+------------------
+
+ *粗略地写下如何重现这个问题。如果您同时处理多个问题，请为每个问题单独写
+ 注释，并确保它们在新启动的系统上独立出现。这是必要的，因为每个问题都需
+ 要分别报告给内核开发人员，除非它们严重纠缠在一起。*
+
+如果你同时处理多个问题，必须分别报告每个问题，因为它们可能由不同的开发人员
+处理。在一份报告中描述多种问题，也会让其他人难以将其分开。因此只有在问题严
+重纠缠的情况下，才能将问题合并在一份报告中。
+
+此外，在报告过程中，你必须测试该问题是否发生在其他内核版本上。因此，如果您
+知道如何在一个新启动的系统上快速重现问题，将使您的工作更加轻松。
+
+注意：报告只发生过一次的问题往往是没有结果的，因为它们可能是由于宇宙辐射导
+致的位翻转。所以你应该尝试通过重现问题来排除这种情况，然后再继续。如果你有
+足够的经验来区分由于硬件故障引起的一次性错误和难以重现的罕见内核问题，可以
+忽略这个建议。
+
+
+安装一个新的内核进行测试
+--------------------------
+
+ *安装最新的Linux主线内核：这是所有问题首先得到修复的地方，因为它是内核
+ 开发人员主要关注的版本线。在某些情况下，使用最新的Linux稳定版内核进行测
+ 试和报告也是一个可以接受的替代方案，例如在合并窗口期间；但在这段时间里，
+ 你可能想要暂停努力直到它结束。*
+
+向 Linux 内核开发者报告一个他们几周或几个月前就已经解决的问题是很烦人的，还
+浪费了他们和你的时间。这就是为什么在报告之前要先检查一下这个问题是否发生在
+最新的代码库中，这对大家都有好处。
+
+在 Linux 内核的范畴内，术语“latest最新”意味着：一个最近从开发主线中创建的内
+核版本，因为这个“主线”树是开发者首先应用修复的地方；只有在那之后，它们才被
+允许被移植回更老的仍然受支持的版本线，即“稳定版”和“长期支持”内核。这就是为
+什么你应该检查最近的主线内核，即使你处理的是一个你只想在旧版本线中看到修复
+的问题。另一个原因是：有些修复只应用于主线或最近的版本新，因为将它们回溯到
+旧版本太难或风险太大。如果是这样，再次报告问题不太可能改变什么。
+
+因此，长期支持内核（有时也被称为“LTS 内核”）不适合进行测试，它们与当前的开
+发相距太远。即使是最新的 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 因为某些原因
+不无法正常工作，那么使用它也是可以接受的。总的来说：用它来重现问题也比完全
+不报告问题要好。
+
+如何获得新的 Linux 内核
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+你可以使用预编译或自编译的内核进行测试；如果你选择后者，可以使用 git 获取源
+代码，或者下载其 tar 存档包。
+
+使用预编译的内核进行测试往往是最快速、最简单、最安全的方法——尤其是在你不熟
+悉 Linux 内核的情况下。但它需要是一个纯净内核，这可能很难直接得到。如果你使
+用的是流行的 Linux 发行版，那么你是幸运的：在网络上，你会发现不少发行版都有
+包含最新的主线或稳定版内核的软件包。使用这些包是完全没问题的，只要从仓库的
+文档中确认它们真的是纯净的。并且确保这些软件包是 `kernel.org
+<https://kernel.org/>`_ 上提供的最新版本；如果软件包的时间超过了一周，那么
+可能就不合适了，因为新的主线和稳定版内核通常至少一周发布一次。需要注意的是，
+在帮助测试修复的时候，你可能无论如何都得自己构建内核，这一点在本文后面会
+有介绍。
+
+熟悉 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`` 来做，它将尝试获
+取你当前内核的配置，然后根据你的系统进行一些调整。这样做并不能使编译出来的
+内核更好，但可以更快地编译。
+
+
+检查“污染”标志
+----------------
+
+ *确保您刚刚安装的内核在运行时不会“污染”自己。*
+
+正如上面已经详细介绍过的：当发生一些可能会导致一些看起来完全不相关的后续错
+误的事情时，内核会设置一个“污染”标志。这就是为什么你需要检查你刚刚安装的内
+核是否有设置此标志。如果有的话，几乎在任何情况下你都需要在报告问题之前先消
+除它。详细的操作方法请看上面的章节。
+
+
+用新内核重现问题
+------------------
+
+ *在您刚刚安装的内核中复现这个问题。如果它没有出现，请查看只发生在稳定版
+ 和长期支持内核的问题的说明。*
+
+检查这个问题是否发生在你刚刚安装的新 Linux 内核版本上。如果新内核已经修复了，
+可以考虑使用此版本线，放弃报告问题。但是请记住，只要它没有在 `kernel.org
+<https://kernel.org/>`_ 的稳定版和长期版（以及由这些版本衍生出来的厂商内核）
+中得到修复，其他用户可能仍然会受到它的困扰。如果你喜欢使用其中的一个，或
+者只是想帮助它们的用户，请前往下面的“报告只发生在较旧内核版本线的问题”一节。
+
+
+优化复现问题的描述
+--------------------
+
+ *优化你的笔记：试着找到并写出最直接的复现问题的方法。确保最终结果包含所
+ 有重要的细节，同时让第一次听说的人容易阅读和理解。如果您在此过程中学到
+ 了一些东西，请考虑再次搜索关于该问题的现有报告。*
+
+过于复杂的报告会让别人很难理解。因此请尽量找到一个可以直接描述、易于以书面
+形式理解的再现方法。包含所有重要的细节，但同时也要尽量保持简短。
+
+在这在前面的步骤中，你很可能已经了解了一些关于你所面临的问题的点。利用这些
+知识，再次搜索可以转而加入的现有报告。
+
+
+解码失败信息
+-------------
+
+.. note::
+
+ FIXME: 本节文字暂时是占位符，与目前
+ “Documentation/admin-guide/reporting-bugs.rst”中的旧文字非常相似。它和它
+ 所引用的文档已经过时，因此需要重新审视。因此，请将此说明视为一个求助：如
+ 果你熟悉这个主题，请写几行适合这里的文字。或者只需向本文件的主要作者（见
+ 导言）大致概述一下当前的情况，因为他们也许能写出一些东西来。
+
+ 最后这部分应该回答“什么时候真正需要这个”、“理想的情况下，早一点设置哪些
+ .config 选项会让这一步变得简单或不必要？”这样的问题（可能是类似
+ CONFIG_UNWINDER_ORC，要不是CONFIG_UNWINDER_FRAME_POINTER；还有其它什么是
+ 需要的吗？）。
+
+..
+
+ *如果失败包含堆栈转储（stack dump），例如Oops所做的，则请考虑对其进行解
+ 码以找到出错的代码行。*
+
+当内核检测到错误时，它将打印一个堆栈转储以便于确定问题发生的确切代码行。但
+是这些信息有时需要解码后才能阅读，这在
+“Documentation/admin-guide/bug-hunting.rst”中有介绍。
+
+
+对回归的特别关照
+-----------------
+
+ *如果您的问题是回归问题，请尽可能缩小引入问题时的范围。*
+
+Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这就是为什么他
+认为回归是不可接受的，并希望看到它们被迅速修复。这就是为什么引入了回归的改
+动导致的问题若无法通过其他方式快速解决，通常会被迅速撤销。因此，报告回归有
+点像“王炸”，会迅速得到修复。但要做到这一点，需要知道导致回归的变化。通常情
+况下，要由报告者来追查罪魁祸首，因为维护者往往没有时间或手头设置不便来自行
+重现它。
+
+有一个叫做“二分”的过程可以来寻找变化，这在
+“Documentation/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@xxxxxxxxxxx) (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/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，
+因此你仍然可以自己帮助自己。例如，你可以试着找到其他受影响的人，和他们一
+起合作来解决这个问题。这样的团队可以一起准备一份新的报告，提到团队有多少人，
+为什么你们认为这是应该得到解决的事情。也许你们还可以一起缩小确切原因或引
+入回归的变化，这往往会使修复更容易。而且如果运气好的话，团队中可能会有懂点
+编程的人，也许能写出一个修复方案。
+
+
+报告仅在旧内核版本线中发生的问题的细节
+----------------------------------------
+
+本节提供了关于：如果你不能在主线内核上重现你的问题，但又想看到它在旧的版本
+线（也就是稳定版和长期支持内核）上得到修复时，需要采取的步骤之细节。
+
+有些修复太复杂
+~~~~~~~~~~~~~~~
+
+ *请做好准备，接下来的几个步骤可能无法在旧版本中解决问题：修复可能太大或
+ 太冒险，无法移植到那里。*
+
+即使是微小的、看似明显的代码变化，有时也会带来新的、完全意想不到的问题。稳
+定版和长期支持内核的维护者非常清楚这一点，因此他们只对这些内核进行符合
+“Documentation/translations/zh_CN/process/stable-kernel-rules.rst”中所列出的
+规则的修改。
+
+复杂或有风险的修改不符合条件，因此只能应用于主线。其他的修复很容易被回溯到
+最新的稳定版和长期支持内核，但是风险太大，无法集成到旧版内核中。所以要注意
+你所希望的修复可能是那些不会被回溯到你所关心的版本线的修复之一。在这种情况
+下，你将别无选择，要么忍受这个问题，要么切换到一个较新的 Linux 版本，除非你
+想自己把修复补丁应用到你的内核中。
+
+确保特定版本线仍然受支持
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *检查内核开发人员是否仍然维护你关心的Linux内核版本线：去 kernel.org 的
+ 首页，确保此特定版本线的最新版没有“[EOL]”标记。*
+
+大多数内核版本线只支持三个月左右，因为延长维护时间会带来相当多的工作。因此，
+每年只会选择一个版本来支持至少两年（通常是六年）。这就是为什么你需要检查
+内核开发者是否还支持你关心的版本线。
+
+注意，如果 `kernel.org <https://kernel.org/>`_ 在首页上列出了两个“稳定”版本，
+你应该考虑切换到较新的版本，而忘掉较旧的版本：对它的支持可能很快就会结束。
+然后，它将被标记为“生命周期结束”（EOL）。达到这个程度的版本线仍然会在
+`kernel.org <https://kernel.org/>`_ 首页上被显示一两周，但不适合用于测试和
+报告。
+
+搜索稳定版邮件列表
+~~~~~~~~~~~~~~~~~~~
+
+ *检查Linux稳定版邮件列表中的现有报告。*
+
+也许你所面临的问题已经被发现，并且已经或即将被修复。因此，请在 `Linux 稳定
+版邮件列表的档案 <https://lore.kernel.org/stable/>`_ 中搜索类似问题的报告。
+如果你找到任何匹配的问题，可以考虑加入讨论，除非修复工作已经完成并计划很快
+得到应用。
+
+用最新版本复现问题
+~~~~~~~~~~~~~~~~~~~
+
+ *从特定的版本线安装最新版本作为纯净内核。确保这个内核没有被污染，并且仍
+ 然存在问题，因为问题可能已经在那里被修复了。*
+
+在投入更多时间到这个过程中之前，你要检查这个问题是否在你关注的版本线的最新
+版本中已经得到了修复。这个内核需要是纯净的，在问题发生之前不应该被污染，正
+如上面已经在测试主线的过程中详细介绍过的一样。
+
+检查代码历史和搜索现有的讨论
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *在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@xxxxxxxxxxxxxxx> # 5.4+
+
+ 像上面这行，开发者标记了安全修复可以回传到 5.4 及以后的版本。大多数情况
+ 下，它会在两周内被应用到那里，但有时需要更长的时间。
+
+ * 如果提交没有告诉你任何东西，或者你找不到修复，请再找找关于这个问题的讨论。
+ 用你最喜欢的搜索引擎搜索网络，以及 `Linux kernel developers mailing
+ list 内核开发者邮件列表 <https://lore.kernel.org/lkml/>`_ 的档案。也可以
+ 阅读上面的 `定位导致问题的内核区域` 一节，然后按照说明找到导致问题的子系
+ 统：它的缺陷跟踪器或邮件列表存档中可能有你要找的答案。
+
+ * 如果你看到了一个计划的修复，请按上所述在版本控制系统中搜索它，因为提交可
+ 能会告诉你是否可以进行回溯。
+
+ * 检查讨论中是否有任何迹象表明，该修复程序可能风险太大，无法回溯到你关心
+ 的版本线。如果是这样的话，你必须忍受这个问题，或者切换到应用了修复的内
+ 核版本线。
+
+ * 如果修复的问题未包含稳定版标签，并且没有讨论过回溯问题，请加入讨论：如
+ 果合适的话，请提及你所面对的问题的版本，以及你希望看到它被修复。
+
+检查是否是稳定版内核或长期支持内核特有的回归。
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *通过安装您所关心的版本线的首个发行版，检查您是否正在处理主线中从未出现
+ 过的回归。如果这个问题没有出现，你基本上需要用此版本来报告这个问题，就
+ 像你用主线报告一个问题一样（见上面）。理想情况下，在该主题和两个相关提
+ 交ID的帮助下，通过对网上现有报告的搜索，将能二分问题。如果还是一无所获，
+ 那就写份报告；将报告抄送或转发给稳定版维护者、稳定版邮件列表和编写更
+ 改的人。如果您发现了导致问题的更改，请包含缩短的提交ID。*
+
+有时你在上一步中不会发现任何东西：你所面临的问题可能从未在主线中发生过，因
+为它是由一些不完整或未正确应用的更改引起的。要检查这一点，安装你关注的版本
+线的首个版本，例如如果你关注 5.4.x 就安装 5.4。
+
+如果问题没有在那显示出来，那就是特定版本线的回归。在这种情况下，你需要像在
+主线中发生的问题一样报告它，就像上面大纲中主线部分的最后几步。
+
+在这种情况下，强烈建议你做二分处理。找到罪魁祸首后，再在网上搜索现有的报告：
+不仅要搜索准确的主题和变更的提交ID（完整的与12个字符的缩短版），还要搜索
+提交信息中提到的“上游提交”的提交ID（完整的，缩短的）。
+
+撰写报告；只要记住几个点就可以了：把报告抄送或转发给稳定版维护者、稳定版邮
+件列表，:ref:`MAINTAINERS <maintainers>` 文件在“STABLE BRANCH”一节中提到了
+这一点。如果你执行了一个成功的二分，请抄送提交的作者，并包含它的主题和缩短
+的提交ID。
+
+请求建议
+~~~~~~~~~
+
+ *前面的步骤之一应该会给出一个解决方案。如果仍未能成功，请向可能引起问题
+ 的子系统的维护人员询问建议；抄送特定子系统的邮件列表以及稳定版邮件列表。*
+
+如果前面的三个步骤都没有让你更接近解决方案，那么只剩下一个选择：请求建议。
+在你发给可能是问题根源的子系统的维护者的邮件中这样做；抄送子系统的邮件列表
+以及 :ref:`MAINTAINERS <maintainers>` 文件在“STABLE BRANCH”一节中提到的稳定
+邮件列表。
+
+
+为什么有些问题在报告后没有任何回应或仍未解决？
+===============================================
+
+当向 Linux 开发者报告问题时，要注意只有“高优先级的问题”（回归、安全问题、严
+重问题）才一定会得到解决。如果维护者或其他人都失败了，Linus Torvalds 他自己
+会确保这一点。他们和其他内核开发者也会解决很多其他问题。但是要知道，有时他
+们也会不能或不愿帮忙；有时甚至没有人发报告给他们。
+
+最好的解释就是那些内核开发者常常是在业余时间为 Linux 内核做出贡献。内核中的
+不少驱动程序都是由这样的程序员编写的，往往只是因为他们想让自己的硬件可以在
+自己喜欢的操作系统上使用。
+
+这些程序员大多数时候会很乐意修复别人报告的问题。但是没有人可以强迫他们这样
+做，因为他们是自愿贡献的。
+
+还有一些情况下，这些开发者真的很想解决一个问题，但却不能解决：有时他们缺乏
+硬件编程文档来解决问题。这种情况往往由于公开的文档太简陋，或者驱动程序是通
+过逆向工程编写的。
+
+业余开发者迟早也会不再关心某驱动。也许他们的测试硬件坏了，被更高级的玩意取
+代了，或者是太老了以至于只能在计算机博物馆里找到。有时开发者根本就不关心他
+们的代码和 Linux 了，因为在他们的生活中一些不同的东西变得更重要了。在某些情
+况下，没有人愿意接手维护者的工作——也没有人可以被强迫，因为对 Linux 内核的贡
+献是自愿的。然而被遗弃的驱动程序仍然存在于内核中：它们对人们仍然有用，删除
+它们可能导致回归。
+
+对于那些为 Linux 内核工作而获得报酬的开发者来说，情况并没有什么不同。这些人
+现在贡献了大部分的变更。但是他们的雇主迟早也会停止关注他们的代码或者让程序
+员专注于其他事情。例如，硬件厂商主要通过销售新硬件来赚钱；因此，他们中的不
+少人并没有投入太多时间和精力来维护他们多年前就停止销售的东西的 Linux 内核驱
+动。企业级 Linux 发行商往往持续维护的时间比较长，但在新版本中往往会把对老旧
+和稀有硬件的支持放在一边，以限制范围。一旦公司抛弃了一些代码，往往由业余贡
+献者接手，但正如上面提到的：他们迟早也会放下代码。
+
+优先级是一些问题没有被修复的另一个原因，因为维护者相当多的时候是被迫设置这
+些优先级的，因为在 Linux 上工作的时间是有限的。对于业余时间或者雇主给予他们
+的开发人员用于上游内核维护工作的时间也是如此。有时维护人员也会被报告淹没，
+即使一个驱动程序几乎完美地工作。为了不被完全缠住，程序员可能别无选择，只能
+对问题报告进行优先级排序而拒绝其中的一些报告。
+
+不过这些都不用太过担心，很多驱动都有积极的维护者，他们对尽可能多的解决问题
+相当感兴趣。
+
+
+结束语
+=======
+
+与其他免费/自由&开源软件（Free/Libre & Open Source Software，FLOSS）相比，
+向 Linux 内核开发者报告问题是很难的：这个文档的长度和复杂性以及字里行间的内
+涵都说明了这一点。但目前就是这样了。这篇文字的主要作者希望通过记录现状来为
+以后改善这种状况打下一些基础。
--
2.20.1
