path: root/Documentation/translations/zh_TW/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_TW.rst

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

:譯者:

 �想� Wu XiangCheng <bobwxc@email.cn>
 胡皓文 Hu Haowen <src.res.211@gmail.com>


報告�題
+++++++++


簡明指�（亦� 太長�看）
==========================

您�臨的是�爲�系列穩定版或長期支�內核的普通內核的回歸？是��然�支�？
請�索 `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_TW/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_TW/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_TW/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_TW/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_TW/admin-guide/bug-bisect.rst�。


「報告僅在舊內核版本線中發生的�題�的�考
------------------------------------------

本節詳細介紹了如果無法用主線內核���題，但希望在舊版本線（�稱穩定版內核和
長期支�內核）中修復�題時需�採�的步驟。

有些修復太複雜
~~~~~~~~~~~~~~~

    *請�好準備，接下來的幾個步驟�能無法在舊版本中解決�題：修復�能太大或
    太冒險，無法移�到那裡。*

�使是微�的�看似明顯的代碼變化，有時也會帶來新的�完全�想�到的�題。穩
定版和長期支�內核的維護者�常清楚這一點，因此他們��這些內核進行符�
「Documentation/translations/zh_TW/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 內核開發者報告�題是很難的：這個文檔的長度和複雜性以�字裡行間的內
涵都說明了這一點。但目�就是這樣了。這篇文字的主�作者希望通�記錄�狀來爲
以後改善這種狀�打下一些基礎。