diff options
| author | Wu XiangCheng <bobwxc@email.cn> | 2021-04-13 15:29:36 +0800 |
|---|---|---|
| committer | Jonathan Corbet <corbet@lwn.net> | 2021-04-13 15:07:30 -0600 |
| commit | 7eb33bdece299f3ec4ce5beb254e473a01df336b (patch) | |
| tree | f494a5f0f3890c2cc6e167ad83151b07985a8f57 /Documentation/translations | |
| parent | e18f54f9bfdbcfc02c5e0b93888bcfe1f2174bd2 (diff) | |
docs/zh_CN: sync reporting-issues.rst
Sync zh translation reporting-issues.rst to
commit 58c539453b71 ("docs: reporting-issues: reduce quoting and assorted
fixes")
Drop reporting-bug.rst
Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
Reviewed-by: Alex Shi <alexs@kernel.org>
Link: https://lore.kernel.org/r/20210413072934.GA2674@bobwxc.top
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/translations')
| -rw-r--r-- | Documentation/translations/zh_CN/admin-guide/reporting-issues.rst | 790 |
1 files changed, 428 insertions, 362 deletions
diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst index 2805c1a03cd5..6b4988da2c5a 100644 --- a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst +++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst @@ -11,27 +11,12 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :doc:`../../../admin-guide/reporting-issues` +:Original: Documentation/admin-guide/reporting-issues.rst :译者: 吴想成 Wu XiangCheng <bobwxc@email.cn> -.. important:: - - 本文档将取代“Documentation/admin-guide/reporting-bugs.rst”。主要的工作 - 已经完成，你可以自由地按照其指示来向Linux内核开发者报告问题。但请留意， - 下面的文字还需要一些润色和校审。现阶段它被合并到Linux内核源代码中，以使 - 这个过程更容易，并增加文本的可见性。 - - 因此，任何文本改进或其他反馈都是非常受欢迎的。请将它发送到“Thorsten - Leemhuis <linux@leemhuis.info>”和“Jonathan Corbet <corbet@lwn.net>”， - 最好抄送“Linux内核邮件列表（LKML） <linux-kernel@vger.kernel.org> ”和 - “Linux内核文档列表 <linux-doc@vger.kernel.org>”。 - - 文本中仍需改进或讨论的区域包含了指出剩余问题的提示；它们都以“FIXME”开头， - 这样更容易找到。 - 报告问题 +++++++++ @@ -40,33 +25,33 @@ 简明指南（亦即 太长不看） ========================== -如果您同时面临多个Linux内核的问题，请分别向开发人员报告每个问题。请尽力尝试 -猜测哪个内核部分可能导致问题。查看 :ref:`MAINTAINERS <maintainers>` 文件， -了解开发人员希望如何被告知有关问题。请注意 `bugzilla.kernel.org -<https://bugzilla.kernel.org/>`_ 很少用到，因为几乎在所有情况下，报告都需要 -通过电子邮件发送! +您面临的是否为同系列稳定版或长期支持内核的普通内核的回归？是否仍然受支持？ +请搜索 `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/>`_ 。如果仍存在问题，请发送报告。 -请彻底检查目标是否已有此报告；也请搜索LKML（内核邮件列表）档案和网络。如果 -找到匹配的，请加入现有的讨论。如果没有找到，请安装 `最新的Linux主线内核 -<https://kernel.org/>`_ 。确保其是纯净的，也就是没有打补丁或使用附加的内核 -模块。还要确保内核运行在一个正常的环境中，并且在问题发生之前没有受到污染。 +问题已经解决了，但是您希望看到它在一个仍然支持的稳定版或长期支持系列中得到 +解决？请安装其最新版本。如果它出现了问题，那么在主线中搜索修复它的更改，并 +检查是否正在回传（backporting）或者已放弃；如果两者都没有，那么可询问处理 +更改的人员。 -如果您可以用主线内核复现您的问题，那么请向您之前确定的目标发送一个报告。确 -保它包括所有相关信息，在导致回归（regression）的情况下应该提到导致它的变化， -这通常可以通过二分法找到。还要确保报告能够送达给所有需要了解它的人，例如 -安全团队、稳定版维护者或导致回归的补丁开发人员。一旦发送报告，请回答可能出 -现的任何问题，并尽可能提供帮助。这包括继续工作：每次发布新的rc1主线内核时， -检查这个问题是否仍然存在，并在初始报告中添加状态更新。 +**通用提醒** ：当安装和测试上述内核时，请确保它是普通的（即：没有补丁，也没 +有使用附加模块）。还要确保它是在一个正常的环境中构建和运行，并且在问题发生 +之前没有被污染（tainted）。 -如果你无法在主线内核中复现这个问题，那么请考虑继续使用它；如果您想使用较旧 -的版本线，并希望看到它在那里得到修复，那么首先要确定它仍受支持。将其最新版 -本安装为纯净内核。如果你不能在那里复现这个问题，试着在主线中或之前的任何讨 -论中找到修复它的提交：这些讨论经常会提到是否有计划支持或认为支持太复杂。如 -果没有讨论支持，可询问是否有可能。如果您没有发现任何提交或之前的讨论，请参 -阅Linux-stable邮件列表存档中现有的报告，因为它可能是特定版本线的回归。如果 -是，就像在主线中报告问题一样报告它（包括二分结果）。 +在编写报告时，要涵盖与问题相关的所有信息，如使用的内核和发行版。在碰见回归时， +尝试给出引入它的更改的提交ID，二分可以找到它。如果您同时面临Linux内核的多个 +问题，请分别报告每个问题。 -如果仍没有解决方案，请在子系统的邮件列表中寻求建议。 +一旦报告发出，请回答任何出现的问题，并尽可能地提供帮助。这包括通过不时重新 +测试新版本并发送状态更新来推动进展。 如何向内核维护人员报告问题的逐步指南 @@ -82,52 +67,60 @@ 尽早意识到看起来像Linux内核毛病的问题可能实际上是由其他原因引起的。这些步骤 可以确保你最终不会觉得在这一过程中投入的时间是浪费： - * 停止阅读本文档并将问题报告给您的供应商，除非您已经运行了最新的主线内核或 - 愿意安装它。这个内核不能以任何方式被修改或增强，因此被认为是“纯净的”。 + * 您是否面临硬件或软件供应商提供的Linux内核的问题？那么基本上您最好停止阅读 + 本文档，转而向您的供应商报告问题，除非您愿意自己安装最新的Linux版本。寻找 + 和解决问题往往需要后者。 + + * 使用您喜爱的网络搜索引擎对现有报告进行粗略搜索；此外，请检查 + `Linux内核邮件列表（LKML） <https://lore.kernel.org/lkml/>`_ 的存档。如果 + 找到匹配的报告，请加入讨论而不是发送新报告。 * 看看你正在处理的问题是否为回归问题、安全问题或非常严重的问题：这些都是需 要在接下来的一些步骤中特别处理的“高优先级问题”。 - * 当问题发生时，检查您的内核是否被“污染”，因为使内核设置这个标志的事件可能 - 会导致您面临的问题。 - - * 定位可能引起问题的驱动程序或内核子系统。找出其开发人员期望的报告的方式和 - 位置。注意：大多数情况下不会是 bugzilla.kernel.org，因为问题通常需要通 - 过邮件发送给维护人员和公共邮件列表。 - - * 在缺陷追踪器或问题相关邮件列表的存档中彻底搜索可能与您的问题匹配的报告。 - 还要检查您是否能在您喜爱的网络搜索引擎或Linux内核邮件列表（LKML）存档中 - 找到一些信息。如果您发现了什么，请加入讨论，而不是发送新的报告。 + * 确保不是内核环境导致了您面临的问题。 * 创建一个新的备份，并将系统修复和恢复工具放在手边。 * 确保您的系统不会通过动态构建额外的内核模块来增强其内核，像DKMS这样的解决 方案可能在您不知情的情况下就在本地进行了这样的工作。 - * 确保不是内核环境导致了您面临的问题。 + * 当问题发生时，检查您的内核是否被“污染”，因为使内核设置这个标志的事件可能 + 会导致您面临的问题。 * 粗略地写下如何重现这个问题。如果您同时处理多个问题，请为每个问题单独写注 释，并确保它们在新启动的系统上独立出现。这是必要的，因为每个问题都需要分 别报告给内核开发人员，除非它们严重纠缠在一起。 + * 如果您正面临稳定版或长期支持版本线的回归（例如从5.10.4更新到5.10.5时出现 + 故障），请查看后文“报告稳定版和长期支持内核线的回归”小节。 + + * 定位可能引起问题的驱动程序或内核子系统。找出其开发人员期望的报告的方式和 + 位置。注意：大多数情况下不会是 bugzilla.kernel.org，因为问题通常需要通 + 过邮件发送给维护人员和公共邮件列表。 + + * 在缺陷追踪器或问题相关邮件列表的存档中彻底搜索可能与您的问题匹配的报告。 + 如果你发现了一些相关讨论，请加入讨论而不是发送新的报告。 + 在完成这些准备之后，你将进入主要部分： - * 安装最新的Linux主线内核：这是所有问题首先得到修复的地方，因为它是内核开 - 发人员主要关注的版本线。在某些情况下，使用最新的Linux稳定版内核进行测试 - 和报告也是一个可以接受的替代方案，例如在合并窗口期间；但在这段时间里，你 - 可能想要暂停努力直到它结束。 + * 除非您已经在运行最新的“主线”Linux内核，否则最好在报告流程前安装它。在某些 + 情况下，使用最新的“稳定版”Linux进行测试和报告也是可以接受的替代方案；在 + 合并窗口期间，这实际上可能是最好的方法，但在开发阶段最好还是暂停几天。无论 + 你选择什么版本，最好使用“普通”构建。忽略这些建议会大大增加您的报告被拒绝 + 或忽略的风险。 * 确保您刚刚安装的内核在运行时不会“污染”自己。 - * 在您刚刚安装的内核中复现这个问题。如果它没有出现，请查看只发生在稳定版和 - 长期支持内核的问题的说明。 + * 在您刚刚安装的内核中复现这个问题。如果它没有出现，请查看下方只发生在 + 稳定版和长期支持内核的问题的说明。 * 优化你的笔记：试着找到并写出最直接的复现问题的方法。确保最终结果包含所有 重要的细节，同时让第一次听说的人容易阅读和理解。如果您在此过程中学到了一 些东西，请考虑再次搜索关于该问题的现有报告。 - * 如果失败包含堆栈转储（stack dump），例如Oops所做的，则请考虑对其进行解码 - 以找到出错的代码行。 + * 如果失败涉及“panic”、“Oops”、“warning”或“BUG”，请考虑解码内核日志以查找触 + 发错误的代码行。 * 如果您的问题是回归问题，请尽可能缩小引入问题时的范围。 @@ -147,39 +140,51 @@ 下。如果你没有得到任何帮助或者未能满意，请试着自己帮助自己。 +报告稳定版和长期支持内核线的回归 +---------------------------------- + +如果您发现了稳定版或长期支持内核版本线中的回归问题并按上述流程跳到这里，那么 +请阅读本小节。即例如您在从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内核版本线：去 `kernel.org - <https://kernel.org/>`_ 的首页，确保此特定版本线的最新版没有“[EOL]”标记。 - - * 检查Linux稳定版邮件列表中的现有报告。 - - * 从特定的版本线安装最新版本作为纯净内核。确保这个内核没有被污染，并且仍然 - 存在问题，因为问题可能已经在那里被修复了。 + * 执行前节“报告稳定版和长期支持内核线的回归”中的前三个步骤。 * 在Linux内核版本控制系统中搜索修复主线问题的更改，因为它的提交消息可能会 告诉你修复是否已经计划好了支持。如果你没有找到，搜索适当的邮件列表，寻找 讨论此类问题或同行评议可能修复的帖子；然后检查讨论是否认为修复不适合支持。 如果支持根本不被考虑，加入最新的讨论，询问是否有可能。 - * 通过安装您所关心的版本线的首个发行版，检查您是否正在处理主线中从未出现过 - 的回归。如果这个问题没有出现，你基本上需要用此版本来报告这个问题，就像你 - 用主线报告一个问题一样（见上面）。理想情况下，在该主题和两个相关提交ID的 - 帮助下，通过对网上现有报告的搜索，将能二分问题。如果还是一无所获，那就写 - 份报告；将报告抄送或转发给稳定版维护者、稳定版邮件列表和编写更改的人。如 - 果您发现了导致问题的更改，请包含缩短的提交ID。 - * 前面的步骤之一应该会给出一个解决方案。如果仍未能成功，请向可能引起问题的 子系统的维护人员询问建议；抄送特定子系统的邮件列表以及稳定版邮件列表 +下面的参考章节部分详细解释了这些步骤中的每一步。 + 参考章节：向内核维护者报告问题 =============================== @@ -213,42 +218,73 @@ 确保您使用的是上游Linux内核 ---------------------------- - *停止阅读本文档，并将问题报告给您的供应商，除非您已经运行了最新的主线内 - 核或愿意安装它。这个内核不能以任何方式被修改或增强，因此被认为是“纯净的”。* - -像大多数程序员一样，Linux内核开发人员不喜欢花时间处理他们维护的源代码中根本 -不会发生的问题的报告：这只会浪费每个人的时间，包括您的时间。这就是为什么你 -之后必须用最新的“纯净”内核来测试你的问题：一个直接从 `kernel.org -<https://kernel.org/>`_ 上获取的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 Turboweed。但是请记住，您最好使用主线Linux，并避免在此流程中使用 +稳定版内核，如“安装一个新的内核进行测试”一节中所详述。 + +当然，您可以忽略所有这些建议，并向上游Linux开发人员报告旧的或经过大量修改的 +供应商内核的问题。但是注意，这样的报告经常被拒绝或忽视，所以自行小心考虑一下。 +不过这还是比根本不报告问题要好：有时候这样的报告会直接或间接地帮助解决之后的 +问题。 + + +搜索现有报告（第一部分） +------------------------- + + *使用您喜爱的网络搜索引擎对现有报告进行粗略搜索；此外，请检查Linux内核 + 邮件列表（LKML）的存档。如果找到匹配的报告，请加入讨论而不是发送新报告。* -.. note:: - - FIXME：我们应该接受与“纯净内核”映像非常接近的问题报告吗？但是什么时候它 - 们足够接近，又该如何用文字表达呢？也许像这样？ +报告一个别人已经提出的问题，对每个人来说都是浪费时间，尤其是作为报告人的你。 +所以彻底检查是否有人已经报告了这个问题，这对你自己是有利的。在流程中的这一步， +可以只执行一个粗略的搜索：一旦您知道您的问题需要报告到哪里，稍后的步骤将告诉 +您如何详细搜索。尽管如此，不要仓促完成这一步，它可以节省您的时间和减少麻烦。 - *注意：一些Linux内核开发人员接受来自已知接近上游的供应商内核的报告。例 - 如Debian GNU/Linux Sid或Fedora Rawhide的内核，它们通常紧跟主线，只携带 - 几个补丁。因此，其中之一的报告可能会被需要处理它的开发人员所接受。但如 - 果他们真的这么做了，很大程度上取决于单个开发人员和手头的问题。这就是为 - 什么安装主线纯净内核是安全的选择。* +只需先用你最喜欢的搜索引擎在互联网上搜索。然后再搜索Linux内核邮件列表（LKML） +存档。 - *Arch Linux，其他Fedora发行版，以及openSUSE Tumbleweed通常使用非常接近 - 上游的稳定版内核。一些开发人员也会从他们那里接受缺陷报告。但请注意，通 - 常应该避免使用稳定版内核来报告问题，而应使用主线内核（见下文）。* +如果搜索结果实在太多，可以考虑让你的搜索引擎将搜索时间范围限制在过去的一个 +月或一年。而且无论你在哪里搜索，一定要用恰当的搜索关键词；也要变化几次关键 +词。同时，试着从别人的角度看问题：这将帮助你想出其他的关键词。另外，一定不 +要同时使用过多的关键词。记住搜索时要同时尝试包含和不包含内核驱动程序的名称 +或受影响的硬件组件的名称等信息。但其确切的品牌名称（比如说“华硕红魔 Radeon +RX 5700 XT Gaming OC”）往往帮助不大，因为它太具体了。相反，尝试搜索术语，如 +型号（Radeon 5700 或 Radeon 5000）和核心代号（“Navi”或“Navi10”），以及包含 +和不包含其制造商（“AMD”）。 - 还有其他主要的Linux发行版应该在这里提到吗？ +如果你发现了关于你的问题的现有报告，请加入讨论，因为你可能会提供有价值的额 +外信息。这一点很重要，即使是在修复程序已经准备好或处于最后阶段，因为开发人 +员可能会寻找能够提供额外信息或测试建议修复程序的人。跳到“发布报告后的责任” +一节，了解有关如何正确参与的细节。 +注意，搜索 `bugzilla.kernel.org <https://bugzilla.kernel.org/>`_ 网站可能 +也是一个好主意，因为这可能会提供有价值的见解或找到匹配的报告。如果您发现后者， +请记住：大多数子系统都希望在不同的位置报告，如下面“你需要将问题报告到何处” +一节中所述。因此本应处理这个问题的开发人员甚至可能不知道bugzilla的工单。所以 +请检查工单中的问题是否已经按照本文档所述得到报告，如果没有，请考虑这样做。 高优先级的问题？ ----------------- @@ -270,8 +306,8 @@ Linus Torvalds和主要的Linux内核开发人员希望看到一些问题尽快 时无法避免不兼容性；但是为了避免回归，这些特性必须在构建配置期间显式地启用。 什么是安全问题留给您自己判断。在继续之前，请考虑阅读 -“Documentation/admin-guide/security-bugs.rst”，因为它提供了如何最恰当地处理 -安全问题的额外细节。 +“Documentation/translations/zh_CN/admin-guide/security-bugs.rst”， +因为它提供了如何最恰当地处理安全问题的额外细节。 当发生了完全无法接受的糟糕事情时，此问题就是一个“非常严重的问题”。例如， Linux内核破坏了它处理的数据或损坏了它运行的硬件。当内核突然显示错误消息 @@ -280,6 +316,60 @@ Linux内核破坏了它处理的数据或损坏了它运行的硬件。当内核 因为显示后者之后内核仍然在运行。 +确保环境健康 +-------------- + + *确保不是内核所处环境导致了你所面临的问题。* + +看起来很像内核问题的问题有时是由构建或运行时环境引起的。很难完全排除这种问 +题，但你应该尽量减少这种问题： + + * 构建内核时，请使用经过验证的工具，因为编译器或二进制文件中的错误可能会导 + 致内核出现错误行为。 + + * 确保您的计算机组件在其设计规范内运行；这对处理器、内存和主板尤为重要。因 + 此，当面临潜在的内核问题时，停止低电压或超频。 + + * 尽量确保不是硬件故障导致了你的问题。例如，内存损坏会导致大量的问题，这些 + 问题会表现为看起来像内核问题。 + + * 如果你正在处理一个文件系统问题，你可能需要用 ``fsck`` 检查一下文件系统， + 因为它可能会以某种方式被损坏，从而导致无法预期的内核行为。 + + * 在处理回归问题时，要确保没有在更新内核的同时发生了其他变化。例如，这个问 + 题可能是由同时更新的其他软件引起的。也有可能是在你第一次重启进入新内核时， + 某个硬件巧合地坏了。更新系统 BIOS 或改变 BIOS 设置中的某些内容也会导致 + 一些看起来很像内核回归的问题。 + + +为紧急情况做好准备 +------------------- + + *创建一个全新的备份，并将系统修复和还原工具放在手边* + +我得提醒您，您正在和计算机打交道，计算机有时会出现意想不到的事情，尤其是当 +您折腾其操作系统的内核等关键部件时。而这就是你在这个过程中要做的事情。因此， +一定要创建一个全新的备份；还要确保你手头有修复或重装操作系统的所有工具， +以及恢复备份所需的一切。 + + +确保你的内核不会被增强 +------------------------ + + *确保您的系统不会通过动态构建额外的内核模块来增强其内核，像DKMS这样的解 + 决方案可能在您不知情的情况下就在本地进行了这样的工作。* + +如果内核以任何方式得到增强，那么问题报告被忽略或拒绝的风险就会急剧增加。这就 +是为什么您应该删除或禁用像akmods和DKMS这样的机制：这些机制会自动构建额外内核 +模块，例如当您安装新的Linux内核或第一次引导它时。也要记得同时删除他们可能安装 +的任何模块。然后重新启动再继续。 + +注意，你可能不知道你的系统正在使用这些解决方案之一：当你安装 Nvidia 专有图 +形驱动程序、VirtualBox 或其他需要 Linux 内核以外的模块支持的软件时，它们通 +常会静默设置。这就是为什么你可能需要卸载这些软件的软件包，以摆脱任何第三方 +内核模块。 + + 检查“污染”标志 ---------------- @@ -300,7 +390,7 @@ Linux内核破坏了它处理的数据或损坏了它运行的硬件。当内核 核未被污染，那么它应该以“Not infected”结束；如果你看到“Tainted:”且后跟一些 空格和字母，那就被污染了。 -如果你的内核被污染了，请阅读“Documentation/admin-guide/tainted-kernels.rst” +如果你的内核被污染了，请阅读“Documentation/translations/zh_CN/admin-guide/tainted-kernels.rst” 以找出原因。设法消除污染因素。通常是由以下三种因素之一引起的： 1. 发生了一个可恢复的错误（“kernel Oops”），内核污染了自己，因为内核知道在 @@ -331,7 +421,39 @@ Linux内核破坏了它处理的数据或损坏了它运行的硬件。当内核 问题的模块名替换“foo”）。 -定位导致问题的内核区域 +记录如何重现问题 +------------------ + + *粗略地写下如何重现这个问题。如果您同时处理多个问题，请为每个问题单独写 + 注释，并确保它们在新启动的系统上独立出现。这是必要的，因为每个问题都需 + 要分别报告给内核开发人员，除非它们严重纠缠在一起。* + +如果你同时处理多个问题，必须分别报告每个问题，因为它们可能由不同的开发人员 +处理。在一份报告中描述多种问题，也会让其他人难以将其分开。因此只有在问题严 +重纠缠的情况下，才能将问题合并在一份报告中。 + +此外，在报告过程中，你必须测试该问题是否发生在其他内核版本上。因此，如果您 +知道如何在一个新启动的系统上快速重现问题，将使您的工作更加轻松。 + +注意：报告只发生过一次的问题往往是没有结果的，因为它们可能是由于宇宙辐射导 +致的位翻转。所以你应该尝试通过重现问题来排除这种情况，然后再继续。如果你有 +足够的经验来区分由于硬件故障引起的一次性错误和难以重现的罕见内核问题，可以 +忽略这个建议。 + + +稳定版或长期支持内核的回归？ +----------------------------- + + *如果您正面临稳定版或长期支持版本线的回归（例如从5.10.4更新到5.10.5时出现 + 故障），请查看后文“报告稳定版和长期支持内核线的回归”小节。* + +稳定版和长期支持内核版本线中的回归是Linux开发人员非常希望解决的问题，这样的 +问题甚至比主线开发分支中的回归更不应出现，因为它们会很快影响到很多人。开发人员 +希望尽快了解此类问题，因此有一个简化流程来报告这些问题。注意，使用更新内核版 +本线的回归（比如从5.9.15切换到5.10.5时出现故障）不符合条件。 + + +你需要将问题报告到何处 ------------------------ *定位可能引起问题的驱动程序或内核子系统。找出其开发人员期望的报告的方式 @@ -408,44 +530,15 @@ PCI/PCIe总线上的设备和驱动它的内核模块:: 内核的开发完全是由邮件驱动的。很少有子系统使用缺陷跟踪器，且其中只有一部分 依赖于 bugzilla.kernel.org。 - -.. note:: - - FIXME: 旧的文本对 bugzilla.kernel.org 采取了完全不同的方法，因为提到它是 - 发布人们不知道如何联系相关人员的问题的地方。新的文本很少提到它；而当它像 - 这里一样提到时，是为了警告用户这往往是一个错误的地方。 - - 之所以选择这种方法，是因为本文的主要作者注意到有不少（甚至很多？）用户在 - bugzilla 上提交的 bug 没有得到回复。这也是意料之中的事情，因为不少（很多？ - 大多数？）维护者甚至在他们的子系统有报告提交时都没有得到通知。而报告得 - 不到任何回复让用户非常烦恼，甚至可能会让他们生气。改进 bugzilla.k.o 确实 - 是一个选择，但在 2017 年的内核和维护者峰会上，大家一致同意先走这条路（很 - 抱歉花了这么长时间）：这更容易实现，争议也更小，因为给已经超负荷工作的维 - 护者增加额外的负担不太可能得到好的效果。 - - -在这种情况下，你必须寻找以“Mail:”开头的行。这些行提到了特定代码的维护者的名 -字和电子邮件地址。也可以查找以“Mailing list:”开头的行，它告诉你开发代码的公 -共邮件列表。你的报告之后需要通过邮件发到这些地址。另外，对于所有通过电子邮 -件发送的问题报告，一定要抄送 Linux Kernel Mailing List（LKML） +在这种以及其他很多情况下，你必须寻找以“Mail:”开头的行。这些行提到了特定代码 +的维护者的名字和电子邮件地址。也可以查找以“Mailing list:”开头的行，它告诉你 +开发代码的公共邮件列表。你的报告之后需要通过邮件发到这些地址。另外，对于所有 +通过电子邮件发送的问题报告，一定要抄送 Linux Kernel Mailing List（LKML） <linux-kernel@vger.kernel.org>。在以后通过邮件发送问题报告时，不要遗漏任何 一个邮件列表!维护者都是大忙人，可能会把一些工作留给子系统特定列表上的其他开 发者；而 LKML 很重要，因为需要一个可以找到所有问题报告的地方。 -.. note:: - - FIXME: 上面一节告诉用户一定要抄送 LKML。如今，它是一种“万能的”列表，几乎 - 没有人密切关注它。因此，似乎应该“全入”，让人们把他们的报告发到这里来，因 - 为所有的东西（报告、修正......）都可以在同一个地方找到（至少对于所有通过 - 邮件发送的报告和所有抄送 LKML 的子系统）。 - - 相关信息：我们是否应该建立一个类似“linux-issues@vger.kernel.org”的邮件列 - 表，并告诉上述的用户在报告问题时一定要抄送？这样一来，报告者就可以在一个 - 中心化的位置搜索现有的报告（至少是通过邮件报告的问题），而不会把常规的 - LKML 流量混入结果中。 - - 借助脚本找到维护者 ~~~~~~~~~~~~~~~~~~~~ @@ -479,154 +572,62 @@ get_maintainer.pl。脚本会查看提交历史，以找到最近哪些人参与 有时这样的代码会在树级清理期间被根本不关心此驱动程序的开发者修改。 -搜索现有报告 -------------- +搜索现有报告（第二部分） +-------------------------- *在缺陷追踪器或问题相关邮件列表的存档中彻底搜索可能与您的问题匹配的报告。 - 还要检查您是否能在您喜爱的网络搜索引擎或Linux内核邮件列表（LKML）存档 - 中找到一些信息。如果您发现了什么，请加入讨论，而不是发送新的报告。* - -报告一个别人已经提出的问题，对每个人来说都是浪费时间，尤其是作为报告人的你。 -所以彻底检查是否有人已经报告了这个问题，这对你自己是有利的。因此，不要草 -草完成报告过程中的这一步。请先花 30 到 60 分钟甚至更多的时间，来为你和他人 -节省更多时间和减少麻烦麻烦。 - -搜索的最佳之处是缺陷跟踪器或者你需要提交报告的邮件列表。你可以在 -`lore.kernel.org <https://lore.kernel.org/>`_ 上找到很多这样的列表，但是有 -些在其他的地方。例如上一步中使用的 ath10k WiFi 驱动就是如此。但是你可以在网 -上很容易找到这些列表的存档。例如搜索“archive ath10k@lists.infradead.org”， -很快就能找到 `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/”这 + 如果找到匹配的报告，请加入讨论而不是发送新报告。* + +如前所述：报告一个别人已经提出的问题，对每个人来说都是浪费时间，尤其是作为报告 +人的你。这就是为什么你应该再次搜索现有的报告。现在你已经知道问题需要报告到哪里。 +如果是邮件列表，那么一般在 `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/”这 样的搜索条件，这会把结果限制在该链接中的档案。 -也请进一步搜索网络和 `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这样的解 - 决方案可能在您不知情的情况下就在本地进行了这样的工作。* +也请进一步搜索网络、LKML和bugzilla.kernel.org网站。 -当报告一个问题时，你的内核必须是“纯净的”，一旦加载了一个不是从编译内核映像 -的源代码构建的内核模块，它就不再是纯净的内核了。这就是为什么你需要通过移除 -或禁用像 akmods 和 DKMS 这样的机制来确保你的 Linux 内核保持纯净：这些机制可 -能会自动构建额外的内核模块，例如当你首次启动到一个新安装的 Linux 内核时。在 -删除它们和它们安装的任何模块后重新启动。 +有关如何搜索以及在找到匹配报告时如何操作的详细信息，请参阅上面的“搜索现有报告 +（第一部分）”。 -注意，你可能不知道你的系统正在使用这些解决方案之一：当你安装 Nvidia 专有图 -形驱动程序、VirtualBox 或其他需要 Linux 内核以外的模块支持的软件时，它们通 -常会静默设置。这就是为什么你可能需要卸载这些软件的软件包，以摆脱任何第三方 -内核模块。 - - -确保环境健康 --------------- - - *确保不是内核所处环境导致了你所面临的问题。* - -看起来很像内核问题的问题有时是由构建或运行时环境引起的。很难完全排除这种问 -题，但你应该尽量减少这种问题： - - * 构建内核时，请使用经过验证的工具，因为编译器或二进制文件中的错误可能会导 - 致内核出现错误行为。 - - * 确保您的计算机组件在其设计规范内运行；这对处理器、内存和主板尤为重要。因 - 此，当面临潜在的内核问题时，停止低电压或超频。 - - * 尽量确保不是硬件故障导致了你的问题。例如，内存损坏会导致大量的问题，这些 - 问题会表现为看起来像内核问题。 - - * 如果你正在处理一个文件系统问题，你可能需要用 ``fsck`` 检查一下文件系统， - 因为它可能会以某种方式被损坏，从而导致无法预期的内核行为。 - - * 在处理回归问题时，要确保没有在更新内核的同时发生了其他变化。例如，这个问 - 题可能是由同时更新的其他软件引起的。也有可能是在你第一次重启进入新内核时， - 某个硬件巧合地坏了。更新系统 BIOS 或改变 BIOS 设置中的某些内容也会导致 - 一些看起来很像内核回归的问题。 - - -记录如何重现问题 ------------------- - - *粗略地写下如何重现这个问题。如果您同时处理多个问题，请为每个问题单独写 - 注释，并确保它们在新启动的系统上独立出现。这是必要的，因为每个问题都需 - 要分别报告给内核开发人员，除非它们严重纠缠在一起。* - -如果你同时处理多个问题，必须分别报告每个问题，因为它们可能由不同的开发人员 -处理。在一份报告中描述多种问题，也会让其他人难以将其分开。因此只有在问题严 -重纠缠的情况下，才能将问题合并在一份报告中。 - -此外，在报告过程中，你必须测试该问题是否发生在其他内核版本上。因此，如果您 -知道如何在一个新启动的系统上快速重现问题，将使您的工作更加轻松。 - -注意：报告只发生过一次的问题往往是没有结果的，因为它们可能是由于宇宙辐射导 -致的位翻转。所以你应该尝试通过重现问题来排除这种情况，然后再继续。如果你有 -足够的经验来区分由于硬件故障引起的一次性错误和难以重现的罕见内核问题，可以 -忽略这个建议。 +不要急着完成报告过程的这一步：花30到60分钟甚至更多的时间可以为你和其他人节省 / +减少相当多的时间和麻烦。 安装一个新的内核进行测试 -------------------------- - *安装最新的Linux主线内核：这是所有问题首先得到修复的地方，因为它是内核 - 开发人员主要关注的版本线。在某些情况下，使用最新的Linux稳定版内核进行测 - 试和报告也是一个可以接受的替代方案，例如在合并窗口期间；但在这段时间里， - 你可能想要暂停努力直到它结束。* + *除非您已经在运行最新的“主线”Linux内核，否则最好在报告流程前安装它。在 + 某些情况下，使用最新的“稳定版”Linux进行测试和报告也是可以接受的替代方案； + 在合并窗口期间，这实际上可能是最好的方法，但在开发阶段最好还是暂停几天。 + 无论你选择什么版本，最好使用“普通”构建。忽略这些建议会大大增加您的报告 + 被拒绝或忽略的风险。* + +正如第一步的详细解释中所提到的：与大多数程序员一样，与大多数程序员一样，Linux +内核开发人员不喜欢花时间处理他们维护的源代码中根本不会发生的问题的报告。这只 +会浪费每个人的时间，尤其是你的时间。这就是为什么在报告问题之前，您必须先确认 +问题仍然存在于最新的上游代码中，这符合每个人的利益。您可以忽略此建议，但如前 +所述：这样做会极大地增加问题报告被拒绝或被忽略的风险。 -向 Linux 内核开发者报告一个他们几周或几个月前就已经解决的问题是很烦人的，还 -浪费了他们和你的时间。这就是为什么在报告之前要先检查一下这个问题是否发生在 -最新的代码库中，这对大家都有好处。 +内核“最新上游”的范围通常指： -在 Linux 内核的范畴内，术语“latest最新”意味着：一个最近从开发主线中创建的内 -核版本，因为这个“主线”树是开发者首先应用修复的地方；只有在那之后，它们才被 -允许被移植回更老的仍然受支持的版本线，即“稳定版”和“长期支持”内核。这就是为 -什么你应该检查最近的主线内核，即使你处理的是一个你只想在旧版本线中看到修复 -的问题。另一个原因是：有些修复只应用于主线或最近的版本新，因为将它们回溯到 -旧版本太难或风险太大。如果是这样，再次报告问题不太可能改变什么。 + * 安装一个主线内核；最新的稳定版内核也可以是一个选择，但大多数时候都最好避免。 + 长期支持内核（有时称为“LTS内核”）不适合此流程。下一小节将更详细地解释所有 + 这些。 -因此，长期支持内核（有时也被称为“LTS 内核”）不适合进行测试，它们与当前的开 -发相距太远。即使是最新的 Linux“稳定版”内核也要落后很多，因此最好避免使用。 -至少在大多数时候是这样，因为有时稳定的内核是最好的选择；但在这种情况下，你 -可能想再等几天。 + * 下一小节描述获取和安装这样一个内核的方法。它还指出了使用预编译内核是可以的， + 但普通的内核更好，这意味着：它是直接使用从 `kernel.org <https://kernel.org/>`_ + 获得的Linux源代码构建并且没有任何方式修改或增强。 -选择主线、稳定版还是继续等待 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +选择适合测试的版本 +~~~~~~~~~~~~~~~~~~~~ 前往 `kernel.org <https://kernel.org/>`_ 来决定使用哪个版本。忽略那个写着 “Latest release最新版本”的巨大黄色按钮，往下看有一个表格。在表格的顶部，你会 @@ -650,37 +651,61 @@ RX 5700 XT Gaming OC”）往往帮助不大，因为它太具体了。相反， 不无法正常工作，那么使用它也是可以接受的。总的来说：用它来重现问题也比完全 不报告问题要好。 +最好避免在合并窗口外使用最新的稳定版内核，因为所有修复都必须首先应用于主线。 +这就是为什么检查最新的主线内核是如此重要：你希望看到在旧版本线修复的任何问题 +需要先在主线修复，然后才能得到回传，这可能需要几天或几周。另一个原因是：您 +希望的修复对于回传来说可能太难或太冒险；因此再次报告问题不太可能改变任何事情。 + +这些方面也部分表明了为什么长期支持内核（有时称为“LTS内核”）不适合报告流程： +它们与当前代码的距离太远。因此，先去测试主线，然后再按流程走：如果主线没有 +出现问题，流程将指导您如何在旧版本线中修复它。 + 如何获得新的 Linux 内核 ~~~~~~~~~~~~~~~~~~~~~~~~~ 你可以使用预编译或自编译的内核进行测试；如果你选择后者，可以使用 git 获取源 代码，或者下载其 tar 存档包。 -使用预编译的内核进行测试往往是最快速、最简单、最安全的方法——尤其是在你不熟 -悉 Linux 内核的情况下。但它需要是一个纯净内核，这可能很难直接得到。如果你使 -用的是流行的 Linux 发行版，那么你是幸运的：在网络上，你会发现不少发行版都有 -包含最新的主线或稳定版内核的软件包。使用这些包是完全没问题的，只要从仓库的 -文档中确认它们真的是纯净的。并且确保这些软件包是 `kernel.org -<https://kernel.org/>`_ 上提供的最新版本；如果软件包的时间超过了一周，那么 -可能就不合适了，因为新的主线和稳定版内核通常至少一周发布一次。需要注意的是， -在帮助测试修复的时候，你可能无论如何都得自己构建内核，这一点在本文后面会 -有介绍。 - -熟悉 git 的开发者和有经验的 Linux 用户通常最好直接从 `kernel.org 上的官方开 -发仓库 +**使用预编译的内核** ：这往往是最快速、最简单、最安全的方法——尤其是在你不熟 +悉 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 存档包。 +**常规方法** ：不熟悉 git 的人通常最好从 `kernel.org <https://kernel.org/>`_ +下载源码的tar 存档包。 如何实际构建一个内核并不在这里描述，因为许多网站已经解释了必要的步骤。如果 你是新手，可以考虑按照那些建议使用 ``make localmodconfig`` 来做，它将尝试获 取你当前内核的配置，然后根据你的系统进行一些调整。这样做并不能使编译出来的 内核更好，但可以更快地编译。 +注意：如果您正在处理来自内核的pannc、Oops、warning或BUG，请在配置内核时尝试 +启用 CONFIG_KALLSYMS 选项。此外，还可以启用 CONFIG_DEBUG_KERNEL 和 +CONFIG_DEBUG_INFO；后者是相关选项，但只有启用前者才能开启。请注意， +CONFIG_DEBUG_INFO 会需要更多储存空间来构建内核。但这是值得的，因为这些选项将 +允许您稍后精确定位触发问题的确切代码行。下面的“解码失败信息”一节对此进行了更 +详细的解释。 + +但请记住：始终记录遇到的问题，以防难以重现。发送未解码的报告总比不报告要好。 + 检查“污染”标志 ---------------- @@ -696,8 +721,8 @@ tar 存档包。 用新内核重现问题 ------------------ - *在您刚刚安装的内核中复现这个问题。如果它没有出现，请查看只发生在稳定版 - 和长期支持内核的问题的说明。* + *在您刚刚安装的内核中复现这个问题。如果它没有出现，请查看下方只发生在 + 稳定版和长期支持内核的问题的说明。* 检查这个问题是否发生在你刚刚安装的新 Linux 内核版本上。如果新内核已经修复了， 可以考虑使用此版本线，放弃报告问题。但是请记住，只要它没有在 `kernel.org @@ -723,27 +748,45 @@ tar 存档包。 解码失败信息 ------------- -.. note:: + *如果失败涉及“panic”、“Oops”、“warning”或“BUG”，请考虑解码内核日志以查找 + 触发错误的代码行。* - FIXME: 本节文字暂时是占位符，与目前 - “Documentation/admin-guide/reporting-bugs.rst”中的旧文字非常相似。它和它 - 所引用的文档已经过时，因此需要重新审视。因此，请将此说明视为一个求助：如 - 果你熟悉这个主题，请写几行适合这里的文字。或者只需向本文件的主要作者（见 - 导言）大致概述一下当前的情况，因为他们也许能写出一些东西来。 +当内核检测到内部问题时，它会记录一些有关已执行代码的信息。这使得在源代码中精 +确定位触发问题的行并显示如何调用它成为可能。但只有在配置内核时启用了 +CONFIG_DEBUG_INFO 和 CONFIG_KALLSYMS选项时，这种方法才起效。如果已启用此选项， +请考虑解码内核日志中的信息。这将使我们更容易理解是什么导致了“panic”、“Oops”、 +“warning”或“BUG”，从而增加了有人提供修复的几率。 - 最后这部分应该回答“什么时候真正需要这个”、“理想的情况下，早一点设置哪些 - .config 选项会让这一步变得简单或不必要？”这样的问题（可能是类似 - CONFIG_UNWINDER_ORC，要不是CONFIG_UNWINDER_FRAME_POINTER；还有其它什么是 - 需要的吗？）。 +解码可以通过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行的指令中。 - *如果失败包含堆栈转储（stack dump），例如Oops所做的，则请考虑对其进行解 - 码以找到出错的代码行。* +该脚本也会如此解码以“Call trace”开头的部分中提到的地址，该部分显示出现问题的 +函数的路径。此外，脚本还会显示内核正在执行的代码部分的汇编输出。 -当内核检测到错误时，它将打印一个堆栈转储以便于确定问题发生的确切代码行。但 -是这些信息有时需要解码后才能阅读，这在 -“Documentation/admin-guide/bug-hunting.rst”中有介绍。 +注意，如果你没法做到这一点，只需跳过这一步，并在报告中说明原因。如果你幸运的 +话，可能无需解码。如果需要的话，也许有人会帮你做这件事情。还要注意，这只是解 +码内核堆栈跟踪的几种方法之一。有时需要采取不同的步骤来检索相关的详细信息。 +别担心，如果您碰到的情况需要这样做，开发人员会告诉您该怎么做。 对回归的特别关照 @@ -759,10 +802,10 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这 重现它。 有一个叫做“二分”的过程可以来寻找变化，这在 -“Documentation/admin-guide/bug-bisect.rst”文档中进行了详细的描述，这个过程通 -常需要你构建十到二十个内核镜像，每次都尝试在构建下一个镜像之前重现问题。是 -的，这需要花费一些时间，但不用担心，它比大多数人想象的要快得多。多亏了 -“binary search二进制搜索”，这将引导你在源代码管理系统中找到导致回归的提交。 +“Documentation/translations/zh_CN/admin-guide/bug-bisect.rst”文档中进行了详细 +的描述，这个过程通常需要你构建十到二十个内核镜像，每次都尝试在构建下一个镜像 +之前重现问题。是的，这需要花费一些时间，但不用担心，它比大多数人想象的要快得多。 +多亏了“binary search二进制搜索”，这将引导你在源代码管理系统中找到导致回归的提交。 一旦你找到它，就在网上搜索其主题、提交ID和缩短的提交ID（提交ID的前12个字符）。 如果有的话，这将引导您找到关于它的现有报告。 @@ -937,7 +980,7 @@ Linux 首席开发者 Linus Torvalds 认为 Linux 内核永远不应恶化，这 报告，请将报告的文本转发到这些地址；但请在报告的顶部加上注释，表明您提交了 报告，并附上工单链接。 -更多信息请参见“Documentation/admin-guide/security-bugs.rst”。 +更多信息请参见“Documentation/translations/zh_CN/admin-guide/security-bugs.rst”。 发布报告后的责任 @@ -1079,28 +1122,11 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于 编程的人，也许能写出一个修复方案。 -报告仅在旧内核版本线中发生的问题的细节 ----------------------------------------- -本节提供了关于：如果你不能在主线内核上重现你的问题，但又想看到它在旧的版本 -线（也就是稳定版和长期支持内核）上得到修复时，需要采取的步骤之细节。 +“报告稳定版和长期支持内核线的回归”的参考 +------------------------------------------ -有些修复太复杂 -~~~~~~~~~~~~~~~ - - *请做好准备，接下来的几个步骤可能无法在旧版本中解决问题：修复可能太大或 - 太冒险，无法移植到那里。* - -即使是微小的、看似明显的代码变化，有时也会带来新的、完全意想不到的问题。稳 -定版和长期支持内核的维护者非常清楚这一点，因此他们只对这些内核进行符合 -“Documentation/translations/zh_CN/process/stable-kernel-rules.rst”中所列出的 -规则的修改。 - -复杂或有风险的修改不符合条件，因此只能应用于主线。其他的修复很容易被回溯到 -最新的稳定版和长期支持内核，但是风险太大，无法集成到旧版内核中。所以要注意 -你所希望的修复可能是那些不会被回溯到你所关心的版本线的修复之一。在这种情况 -下，你将别无选择，要么忍受这个问题，要么切换到一个较新的 Linux 版本，除非你 -想自己把修复补丁应用到你的内核中。 +本小节提供了在稳定版和长期支持内核线中面对回归时需要执行的步骤的详细信息。 确保特定版本线仍然受支持 ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1138,6 +1164,72 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于 版本中已经得到了修复。这个内核需要是纯净的，在问题发生之前不应该被污染，正 如上面已经在测试主线的过程中详细介绍过的一样。 +您是否是第一次注意到供应商内核的回归？供应商的更改可能会发生变化。你需要重新 +检查排除来这个问题。当您从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稳定邮件列表中搜索退出的报告。 + + * 检查最新版本。 + + 检查代码历史和搜索现有的讨论 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1178,31 +1270,6 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于 * 如果修复的问题未包含稳定版标签，并且没有讨论过回溯问题，请加入讨论：如 果合适的话，请提及你所面对的问题的版本，以及你希望看到它被修复。 -检查是否是稳定版内核或长期支持内核特有的回归。 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - *通过安装您所关心的版本线的首个发行版，检查您是否正在处理主线中从未出现 - 过的回归。如果这个问题没有出现，你基本上需要用此版本来报告这个问题，就 - 像你用主线报告一个问题一样（见上面）。理想情况下，在该主题和两个相关提 - 交ID的帮助下，通过对网上现有报告的搜索，将能二分问题。如果还是一无所获， - 那就写份报告；将报告抄送或转发给稳定版维护者、稳定版邮件列表和编写更 - 改的人。如果您发现了导致问题的更改，请包含缩短的提交ID。* - -有时你在上一步中不会发现任何东西：你所面临的问题可能从未在主线中发生过，因 -为它是由一些不完整或未正确应用的更改引起的。要检查这一点，安装你关注的版本 -线的首个版本，例如如果你关注 5.4.x 就安装 5.4。 - -如果问题没有在那显示出来，那就是特定版本线的回归。在这种情况下，你需要像在 -主线中发生的问题一样报告它，就像上面大纲中主线部分的最后几步。 - -在这种情况下，强烈建议你做二分处理。找到罪魁祸首后，再在网上搜索现有的报告： -不仅要搜索准确的主题和变更的提交ID（完整的与12个字符的缩短版），还要搜索 -提交信息中提到的“上游提交”的提交ID（完整的，缩短的）。 - -撰写报告；只要记住几个点就可以了：把报告抄送或转发给稳定版维护者、稳定版邮 -件列表，:ref:`MAINTAINERS <maintainers>` 文件在“STABLE BRANCH”一节中提到了 -这一点。如果你执行了一个成功的二分，请抄送提交的作者，并包含它的主题和缩短 -的提交ID。 请求建议 ~~~~~~~~~ @@ -1212,8 +1279,7 @@ FLOSS 问题报告的人看，询问他们的意见。同时征求他们关于 如果前面的三个步骤都没有让你更接近解决方案，那么只剩下一个选择：请求建议。 在你发给可能是问题根源的子系统的维护者的邮件中这样做；抄送子系统的邮件列表 -以及 :ref:`MAINTAINERS <maintainers>` 文件在“STABLE BRANCH”一节中提到的稳定 -邮件列表。 +以及稳定版邮件列表（stable@vger.kernel.org）。 为什么有些问题在报告后没有任何回应或仍未解决？ |