英語

報告問題

簡明指南（又稱 TL;DR）

您是否在同一個穩定版或長期支援版系列的原版核心中遇到了迴歸？該版本是否仍在支援中？那麼請在 LKML 和 Linux 穩定版郵件列表歸檔中搜索匹配的報告以參與討論。如果沒有找到，請安裝 該系列的最新版本。如果問題仍然存在，請將其報告給穩定版郵件列表 (stable@vger.kernel.org)，並抄送回歸郵件列表 (regressions@lists.linux.dev)；理想情況下，也請抄送相關子系統的維護者和郵件列表。

在所有其他情況下，請盡力猜測是哪個核心部分導致了問題。檢查 MAINTAINERS 檔案，瞭解其開發人員希望如何被告知問題，大多數情況下是透過電子郵件並抄送郵件列表。檢查目標歸檔中是否存在匹配的報告；也請搜尋 LKML 和網路。如果沒有找到可以參與的報告，請安裝 最新的主線核心。如果問題在那裡仍然存在，請傳送報告。

問題在那裡已修復，但您也希望在仍在支援的穩定版或長期支援版系列中解決它？那麼請安裝該系列的最新版本。如果問題仍然存在，請搜尋主線中修復它的更改，並檢查是否正在進行反向移植或已被放棄；如果兩者都不是，請向處理該更改的人員詢問。

一般說明：如上所述安裝和測試核心時，請確保它是原版（換句話說：未打補丁且未使用附加模組）。還要確保它在健康的執行環境中構建和執行，並且在問題發生之前沒有被汙染。

如果您同時面臨多個 Linux 核心問題，請分別報告。在撰寫報告時，請包含所有與問題相關的資訊，例如所使用的核心和發行版。如果是迴歸問題，請在報告中抄送回歸郵件列表 (regressions@lists.linux.dev)。另請嘗試使用二分法找出罪魁禍首；如果成功，請包含其提交 ID 並抄送簽發鏈中的所有人。

報告發出後，請回答提出的任何問題，並在力所能及的範圍內提供幫助。這包括透過偶爾使用新版本進行重新測試並在之後傳送狀態更新來保持事情的進展。

如何向核心維護者報告問題的逐步指南

上述 TL;DR 大致說明了如何向 Linux 核心開發人員報告問題。對於已經熟悉向自由/開源軟體 (FLOSS) 專案報告問題的人來說，這可能就是所需的一切。對於其他人，本節提供了更詳細的逐步方法。它仍然力求簡潔易讀，並省略了許多細節；這些細節在逐步指南下方的參考章節中進行了更詳細的解釋。

注意：本節比 TL;DR 涵蓋了更多方面，並且步驟順序略有不同。這符合您的利益，可以確保您及早發現一個看似 Linux 核心問題的問題實際上是否由其他原因引起。因此，這些步驟有助於確保您在此過程中投入的時間最終不會白費。

  • 您是否在使用硬體或軟體供應商提供的 Linux 核心時遇到問題？那麼在幾乎所有情況下，您最好停止閱讀本文件，而是向您的供應商報告問題，除非您願意自己安裝最新的 Linux 版本。請注意，後者通常是追蹤和修復問題所必需的。

  • 使用您喜歡的網際網路搜尋引擎粗略搜尋現有報告；此外，請檢視 Linux 核心郵件列表 (LKML) 的歸檔。如果您找到匹配的報告，請加入討論，而不是傳送新的報告。

  • 檢視您正在處理的問題是否符合迴歸、安全問題或非常嚴重的問題：這些是“高優先順序問題”，在接下來的某些步驟中需要特殊處理。

  • 確保導致您所遇到問題的不是核心的周邊環境。

  • 建立新的備份，並準備好系統修復和恢復工具。

  • 確保您的系統不會透過動態構建額外的核心模組來增強其核心，像 DKMS 這樣的解決方案可能會在您不知情的情況下在本地執行此操作。

  • 檢查問題發生時您的核心是否被“汙染”，因為導致核心設定此標記的事件可能正是您所遇到問題的原因。

  • 粗略記錄如何重現問題。如果您同時處理多個問題，請為每個問題建立單獨的筆記，並確保它們在全新啟動的系統上獨立執行。這是必要的，因為每個問題都需要單獨報告給核心開發人員，除非它們之間存在強烈的關聯。

  • 如果您在穩定版或長期支援版系列中遇到了迴歸（例如，從 5.10.4 更新到 5.10.5 時出現問題），請向下滾動到“處理穩定版和長期支援版核心系列中的迴歸”一節。

  • 找出似乎導致問題的驅動程式或核心子系統。查明其開發人員期望如何以及在哪裡接收報告。注意：大多數情況下這不會是 bugzilla.kernel.org，因為問題通常需要透過郵件傳送給維護者和公共郵件列表。

  • 徹底搜尋相關 bug 跟蹤器或郵件列表的歸檔，尋找可能與您問題匹配的報告。如果您找到任何內容，請加入討論，而不是傳送新的報告。

完成這些準備後，您現在將進入主要部分。

  • 除非您已經執行最新的“主線”Linux 核心，否則最好安裝它以便進行報告。在某些情況下，使用最新的“穩定版”Linux 進行測試和報告是可以接受的替代方案；在合併視窗期間，這實際上可能是最好的方法，但在那個開發階段，無論如何暫停幾天您的努力可能是一個更好的主意。無論您選擇哪個版本，理想情況下都應使用“原版”構建。忽視這些建議將大大增加您的報告被拒絕或忽略的風險。

  • 確保您剛剛安裝的核心在執行時不會“汙染”自己。

  • 使用您剛剛安裝的核心重現問題。如果問題沒有出現，請向下滾動到僅在穩定版和長期支援版核心中出現的問題的說明。

  • 最佳化您的筆記：嘗試找到並寫下重現問題的最直接方法。確保最終結果包含所有重要細節，同時對於初次聽說的人來說易於閱讀和理解。如果您在此過程中學到了什麼，請考慮再次搜尋有關該問題的現有報告。

  • 如果您的故障涉及“panic”、“Oops”、“warning”或“BUG”，請考慮解碼核心日誌以找到觸發錯誤的原始碼行。

  • 如果您的問題是迴歸，請儘量縮小問題引入的時間範圍。

  • 開始撰寫報告，詳細描述問題。務必提及幾點：您為重現問題而安裝的最新核心版本、所使用的 Linux 發行版以及您關於如何重現問題的筆記。理想情況下，請將核心的構建配置 (.config) 和 dmesg 的輸出釋出到網上並提供連結。包含或上傳所有其他可能相關的資訊，例如 Oops 的輸出/截圖或 lspci 的輸出。完成這部分主要內容後，在其上方插入一個長度適中的段落，快速概述問題和影響。在此之上，再新增一個簡短描述問題的句子，吸引人們繼續閱讀。現在，給報告一個描述性更短的標題或主題。然後您就可以按照 MAINTAINERS 檔案告訴您的方式傳送或提交報告了，除非您正在處理“高優先順序問題”之一：這些問題需要特殊處理，具體說明見下方的“高優先順序問題的特殊處理”一節。

  • 等待回應，並持續跟進，直到您能接受某種結果。因此，請公開並及時回應任何詢問。測試提議的修復。進行主動測試：至少對新主線版本的每一個第一個釋出候選版 (RC) 進行重新測試，並報告您的結果。如果事情停滯不前，請傳送友善的提醒。如果您沒有得到任何幫助或結果不盡如人意，請嘗試自助。

在穩定版和長期支援版核心系列中報告迴歸

如果您遵循了上述流程並在穩定版或長期支援版核心系列中的迴歸問題處被引導到這裡，那麼本小節是為您準備的。如果您從 5.10.4 更新到 5.10.5 時出現問題（從 5.9.15 切換到 5.10.5 不符合條件），則您遇到了此類問題。開發人員希望儘快修復此類迴歸，因此有一個簡化的報告流程。

  • 檢查核心開發人員是否仍在維護您所關心的 Linux 核心版本系列：訪問 kernel.org 的首頁，並確保它提到了該特定版本系列的最新版本，且沒有“[EOL]”標記。

  • 檢查 Linux 穩定版郵件列表 的歸檔，查詢現有報告。

  • 將該特定版本系列的最新版本作為原版核心安裝。確保此核心未被汙染且問題仍然存在，因為問題可能已在那裡修復。如果您最初是在供應商核心中注意到此問題，請檢查已知可正常工作的最後一個版本的原版構建是否也執行良好。

  • 向 Linux 穩定版郵件列表 (stable@vger.kernel.org) 傳送一份簡短的問題報告，並抄送 Linux 迴歸郵件列表 (regressions@lists.linux.dev)；如果您懷疑是某個特定子系統引起的問題，請抄送其維護者和其郵件列表。大致描述問題，並理想地解釋如何重現。提及出現問題的第一個版本和正常工作的最後一個版本。然後等待進一步的指示。

下面的參考章節更詳細地解釋了這些步驟。

報告僅在舊版核心系列中出現的問題

如果您嘗試瞭如上所述的最新主線核心，但未能重現您的問題；同時您希望在仍在支援的穩定版或長期支援版系列或基於這些版本定期重構的供應商核心中看到問題得到修復。如果是這樣，請遵循以下步驟。

  • 請做好準備，接下來的幾個步驟可能無法在舊版本中解決問題：修復可能太大或風險太高，無法反向移植到那裡。

  • 執行上面“處理穩定版和長期支援版核心系列中的迴歸”一節的前三個步驟。

  • 在 Linux 核心版本控制系統中搜索在主線中修復該問題的更改，因為其提交訊息可能會告訴您該修復是否已計劃進行反向移植。如果沒有找到，請在適當的郵件列表中搜索討論此類問題或同行評審可能修復的帖子；然後檢查討論，看看該修復是否被認為不適合反向移植。如果根本沒有考慮反向移植，請加入最新的討論，詢問是否有可能。

  • 前面的步驟之一應該能找到解決方案。如果行不通，請向似乎導致問題的子系統的維護者尋求建議；抄送該特定子系統的郵件列表以及穩定版郵件列表。

下面的參考章節更詳細地解釋了這些步驟。

參考章節：向核心維護者報告問題

上面詳細的指南簡要概述了所有主要步驟，這對於大多數人來說應該足夠了。但有時即使是經驗豐富的使用者也可能會想知道如何實際執行其中一個步驟。這就是本節的目的，它將提供有關上述每個步驟的更多詳細資訊。將此視為參考文件：可以從頭到尾閱讀。但它主要用於快速瀏覽，也是一個查詢如何實際執行這些步驟的詳細資訊的地方。

在深入細節之前的一些一般性建議

  • Linux 核心開發人員深知這個過程很複雜，並且比其他自由/開源軟體專案要求更多。我們很樂意使其更簡單。但這需要在多個地方進行工作以及一些基礎設施，這將需要持續維護；目前沒有人主動承擔這項工作，所以目前情況就是如此。

  • 與某些供應商的保修或支援合同，並不能讓您有權向上遊 Linux 核心社群的開發人員請求修復：此類合同完全超出 Linux 核心、其開發社群和本文件的範圍。因此，在這種情況下，您不能要求此類合同保證的任何內容，即使處理該問題的開發人員為相關供應商工作也是如此。如果您想主張自己的權利，請使用供應商的支援渠道。這樣做時，您可能希望提及您希望看到問題在上游 Linux 核心中得到修復；透過說明這是確保最終修復會被所有 Linux 發行版採納的唯一方式來激勵他們。

  • 如果您以前從未向自由/開源軟體專案報告過問題，您應該考慮閱讀 《如何有效報告 Bug》、 《提問的智慧》 和 《如何提出好問題》。

排除這些之後，下面是關於如何正確向 Linux 核心開發人員報告問題的詳細資訊。

確保您使用的是上游 Linux 核心

您是否在使用硬體或軟體供應商提供的 Linux 核心時遇到問題？那麼在幾乎所有情況下，您最好停止閱讀本文件，而是向您的供應商報告問題，除非您願意自己安裝最新的 Linux 版本。請注意，後者通常是追蹤和修復問題所必需的。

和大多數程式設計師一樣，Linux 核心開發人員不喜歡花時間處理那些甚至不會在他們當前程式碼中發生的問題報告。這只是浪費大家的時間，特別是您的時間。不幸的是，在核心方面這種情況很容易發生，並常常導致雙方沮喪。這是因為幾乎所有預裝在裝置（計算機、筆記型電腦、智慧手機、路由器等）上的基於 Linux 的核心以及大多數由 Linux 發行版釋出的核心都與 kernel.org 分發的官方 Linux 核心相去甚遠：這些供應商的核心通常在 Linux 開發的角度來看非常古老，或被大量修改，常常兩者兼有。

這些供應商核心大多不適合向 Linux 核心開發人員報告問題：您在使用其中一個核心時遇到的問題可能在數月甚至數年前就已被 Linux 核心開發人員修復；此外，供應商的修改和增強可能導致您所遇到的問題，即使它們看起來很小或完全不相關。這就是為什麼您應該向供應商報告這些核心的問題。其開發人員應該研究該報告，如果發現是上游問題，應直接在上游修復或將報告轉發到上游。實際上，這通常行不通，或者可能不是您想要的。因此，您可能需要考慮自行安裝最新的 Linux 核心核心來繞過供應商。如果這對您來說是一個選擇，請繼續此過程，因為本指南稍後會解釋如何在排除其他潛在問題原因後執行此操作。

請注意，上一段以“大多”開頭，因為有時開發人員實際上願意處理有關供應商核心中出現的問題報告。他們最終是否處理，很大程度上取決於開發人員和所涉問題。如果發行版僅對基於最新 Linux 版本的核心進行了少量修改，您的機會就相當大；例如，這通常適用於 Debian GNU/Linux Sid 或 Fedora Rawhide 釋出的上游主線核心。一些開發人員也會接受關於釋出最新穩定版核心的發行版中的問題報告，只要它們只是略微修改過；例如，Arch Linux、常規 Fedora 版本和 openSUSE Tumbleweed 通常就是這種情況。但請記住，您最好使用主線 Linux 並避免在此過程中使用穩定版核心，如“安裝新核心進行測試”一節中更詳細地概述的那樣。

顯然，您可以隨意忽略所有這些建議，並向上遊 Linux 開發人員報告舊的或經過大量修改的供應商核心的問題。但請注意，這些報告通常會被拒絕或忽略，因此請自行斟酌。但總比完全不報告問題要好：有時此類報告會直接或間接地幫助問題隨著時間的推移得到修復。

搜尋現有報告，首次執行

使用您喜歡的網際網路搜尋引擎粗略搜尋現有報告；此外，請檢視 Linux 核心郵件列表 (LKML) 的歸檔。如果您找到匹配的報告，請加入討論，而不是傳送新的報告。

報告一個別人已經提出的問題，通常會浪費所有相關人員的時間，尤其是作為報告者的您。因此，徹底檢查是否有人已經報告了該問題符合您自身的利益。在此過程的此步驟中，進行粗略搜尋是可以的：一旦您知道問題需要報告到何處，後續步驟會告訴您進行更詳細的搜尋。儘管如此，請不要急於執行報告流程的此步驟，它可以為您節省時間和麻煩。

首先，簡單地使用您喜歡的搜尋引擎在網際網路上搜索。之後，搜尋 Linux 核心郵件列表 (LKML) 歸檔。

如果結果氾濫，請考慮告訴您的搜尋引擎將搜尋時間範圍限制在過去一個月或一年。無論您在哪裡搜尋，請務必使用好的搜尋詞；也要嘗試多次更改它們。這樣做時，請嘗試從他人的角度看待問題：這將幫助您想出其他可以用作搜尋詞的詞語。此外，確保不要一次使用過多的搜尋詞。記住，搜尋時可以包含或不包含核心驅動程式名稱或受影響硬體元件名稱等資訊。但其確切的品牌名稱（例如“華碩 ROG 猛禽 Radeon RX 5700 XT Gaming OC”）通常幫助不大，因為它過於具體。相反，嘗試使用像型號系列（Radeon 5700 或 Radeon 5000）和主晶片代號（“Navi”或“Navi10”）這樣的搜尋詞，可以帶或不帶其製造商（“AMD”）。

如果您發現有關您問題的現有報告，請加入討論，因為您可能能夠提供有價值的額外資訊。即使修復已在準備中或已進入最後階段，這也很重要，因為開發人員可能會尋找能夠提供額外資訊或測試擬議修復的人。請跳轉到“報告發出後的職責”一節，瞭解如何正確參與的詳細資訊。

請注意，搜尋 bugzilla.kernel.org 也可能是個好主意，因為它可能會提供有價值的見解或發現匹配的報告。如果您找到後者，請記住：大多數子系統期望在不同地方接收報告，如下文“檢查您需要向何處報告問題”一節所述。因此，負責該問題的開發人員可能甚至不知道該 bugzilla 工單。因此，請檢查該工單是否已按本文件所述報告了問題，如果沒有，請考慮報告。

高優先順序問題？

檢視您正在處理的問題是否符合迴歸、安全問題或非常嚴重的問題：這些是“高優先順序問題”，在接下來的某些步驟中需要特殊處理。

Linus Torvalds 和主要的 Linux 核心開發人員希望儘快修復一些問題，因此存在“高優先順序問題”，它們在報告過程中會略有不同地處理。三種情況符合條件：迴歸、安全問題和非常嚴重的問題。

如果某個應用程式或實際用例在某個 Linux 核心上執行良好，但在使用類似配置編譯的較新版本上執行變差或完全無法執行，則您遇到了迴歸。文件 《報告迴歸》 更詳細地解釋了這一點。它還提供了許多其他有關回歸的資訊，您可能需要了解；例如，它解釋瞭如何將您的問題新增到已跟蹤迴歸列表中，以確保它不會被遺漏。

什麼構成安全問題由您自行判斷。在繼續之前，請考慮閱讀 《安全 Bug》，因為它提供瞭如何最好地處理安全問題的額外詳細資訊。

當發生完全不可接受的糟糕情況時，問題就是“非常嚴重的問題”。例如，當 Linux 核心損壞其處理的資料或損害其執行的硬體時，就是這種情況。當核心突然停止工作並顯示錯誤訊息（“核心 panic”）或完全沒有任何告別資訊時，您也在處理一個嚴重問題。注意：不要混淆“panic”（核心自行停止的致命錯誤）和“Oops”（可恢復錯誤），因為後者發生後核心仍會繼續執行。

確保健康的執行環境

確保導致您所遇到問題的不是核心的周邊環境。

看起來很像核心問題的問題有時是由構建或執行時環境引起的。很難完全排除這個問題，但您應該將其最小化。

  • 在構建核心時使用經過驗證的工具，因為編譯器或 binutils 中的錯誤可能導致生成的核心行為異常。

  • 確保您的計算機元件在其設計規範內執行；這對於主處理器、主記憶體和主機板尤為重要。因此，在面對潛在的核心問題時，請停止降壓或超頻。

  • 儘量確保不是有故障的硬體導致了您的問題。例如，損壞的主記憶體可能導致許多問題，表現為看起來像核心問題。

  • 如果您正在處理檔案系統問題，您可能需要使用 fsck 檢查相關檔案系統，因為它可能以導致意外核心行為的方式損壞。

  • 處理迴歸問題時，請確保不是其他與核心更新同時發生的變化導致了問題。例如，問題可能由同時更新的其他軟體引起。也可能發生硬體元件在您首次重啟進入新核心時恰好損壞的情況。更新系統 BIOS 或更改 BIOS 設定中的某些內容也可能導致看起來很像核心迴歸的問題。

為緊急情況做準備

建立新的備份，並準備好系統修復和恢復工具。

提醒：您正在處理計算機，它們有時會做一些意想不到的事情，特別是當您操作其作業系統的核心等關鍵部分時。這正是您在此過程中將要做的事情。因此，請務必建立新的備份；同時確保您手頭有所有修復或重新安裝作業系統所需的工具，以及恢復備份所需的一切。

確保您的核心未被增強

確保您的系統不會透過動態構建額外的核心模組來增強其核心，像 DKMS 這樣的解決方案可能會在您不知情的情況下在本地執行此操作。

如果您的核心以任何方式被增強，您的報告被忽略或拒絕的風險會大大增加。這就是為什麼您應該刪除或停用 akmods 和 DKMS 等機制：這些機制會自動構建附加核心模組，例如當您安裝新的 Linux 核心或首次啟動它時。同時刪除它們可能已安裝的任何模組。然後重啟再繼續。

請注意，您可能沒有意識到您的系統正在使用這些解決方案之一：當您安裝 Nvidia 的專有圖形驅動程式、VirtualBox 或其他需要 Linux 核心之外模組支援的軟體時，它們通常會被靜默設定。這就是為什麼您可能需要解除安裝包含此類軟體的軟體包，以清除任何第三方核心模組。

檢查“汙染”標記

檢查問題發生時您的核心是否被“汙染”，因為導致核心設定此標記的事件可能正是您所遇到問題的原因。

當發生一些可能導致完全不相關的後續錯誤的情況時，核心會用一個“汙染”（taint）標誌來標記自身。如果您的核心被汙染，您面臨的問題可能就是此類錯誤。這就是為什麼在投入更多時間到此流程之前，您應該儘早排除這種情況。這是此步驟在此的唯一原因，因為此流程稍後會告訴您安裝最新的主線核心；屆時您將需要再次檢查汙染標誌，因為那時它才重要，因為報告將關注的是該核心。

在一個正在執行的系統上，檢查核心是否被汙染很容易：如果 cat /proc/sys/kernel/tainted 返回“0”，則核心未被汙染，一切正常。在某些情況下，檢查該檔案是不可能的；這就是為什麼核心在報告內部問題（“核心錯誤”）、可恢復錯誤（“核心 Oops”）或在停止操作前不可恢復錯誤（“核心 panic”）時，也會提及汙染狀態。在其中之一發生時列印的錯誤訊息頂部附近查詢，並搜尋以“CPU:”開頭的行。如果核心在發現問題時未被汙染，它應該以“Not tainted”結尾；如果您看到“Tainted:”後跟著一些空格和一些字母，則它已被汙染。

如果您的核心被汙染，請查閱受汙染的核心以找出原因。嘗試消除原因。通常它由以下三件事之一引起：

  1. 發生了一個可恢復錯誤（一個“核心 Oops”），並且核心汙染了自身，因為核心知道此後可能會出現奇怪的行為。在這種情況下，請檢查您的核心或系統日誌，並查詢以以下內容開頭的片段：

    Oops: 0000 [#1] SMP

    這是自啟動以來的第一次 Oops，正如括號中的“#1”所示。此後發生的每個 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 核心是一個龐大的專案，其大多數開發人員只熟悉其中的一小部分。例如，相當多的程式設計師只關心一個驅動程式，例如一個 Wi-Fi 晶片的驅動程式；其開發者可能對遠端或不相關的“子系統”的內部結構知之甚少或一無所知，例如 TCP 棧、PCIe/PCI 子系統、記憶體管理或檔案系統。

問題是：Linux 核心缺乏一箇中央錯誤跟蹤器，您只需提交您的問題即可將其傳送給需要了解的開發者。這就是為什麼您必須自己找到報告問題的正確位置和方式。您可以在指令碼的幫助下做到這一點（見下文），但它主要針對核心開發者和專家。對於其他人來說，MAINTAINERS 檔案是更好的選擇。

如何閱讀 MAINTAINERS 檔案

為了說明如何使用MAINTAINERS檔案，讓我們假設您的筆記型電腦中的 Wi-Fi 在更新核心後突然出現異常。在這種情況下，很可能是 Wi-Fi 驅動程式的問題。顯然，它也可能是其所基於的一些程式碼，但除非您懷疑類似的情況，否則請堅持認為是驅動程式的問題。如果確實是其他問題，驅動程式的開發者會聯絡到正確的人。

遺憾的是，目前沒有一種通用且簡單的方法來檢查哪個程式碼驅動著特定的硬體元件。

例如，在 Wi-Fi 驅動程式出現問題時，您可能需要檢視 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
[...]

但如果您的 Wi-Fi 晶片透過 USB 或其他內部匯流排連線，則此方法將不起作用。在這些情況下，您可能需要檢查您的 Wi-Fi 管理器或 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 原始碼樹根目錄下的純 MAINTAINERS 檔案，行描述將是縮寫。“Mail:”例如將是“M:”，“Mailing list:”將是“L”，“Status:”將是“S:”。檔案頂部附近的一個部分解釋了這些和其他縮寫。

首先檢視“Status”行。理想情況下，它應該是“Supported”或“Maintained”。如果它顯示“Obsolete”，那麼您正在使用一些已被新解決方案取代的過時方法，您需要切換到新方法。有時程式碼只有在有動力時才會有人提供“Odd Fixes”。而“Orphan”則表示您完全不走運，因為程式碼已經沒有人維護了。這隻剩下這些選擇：想辦法接受這個問題，自己修復它，或者找到一位程式設計師願意修復它。

檢查狀態後，查詢以“bugs:”開頭的行：它會告訴您在哪裡找到特定子系統的錯誤跟蹤器來提交您的問題。上面的示例沒有這樣的行。大多數部分都是這種情況，因為 Linux 核心開發完全透過郵件驅動。很少有子系統使用錯誤跟蹤器，並且其中只有少數依賴 bugzilla.kernel.org。

在這種和許多其他情況下，您因此必須改為尋找以“Mail:”開頭的行。這些行提到了特定程式碼維護者的姓名和電子郵件地址。此外，還要查詢以“Mailing list:”開頭的行，它告訴您該程式碼開發的公共郵件列表。您的報告稍後需要透過郵件傳送到這些地址。此外，對於所有透過電子郵件傳送的問題報告，請確保將 Linux 核心郵件列表 (LKML) <linux-kernel@vger.kernel.org> 新增到抄送。稍後透過郵件傳送問題報告時，不要遺漏任何一個郵件列表！維護者都很忙，可能會將一些工作留給子系統特定列表上的其他開發人員；而 LKML 很重要，它提供了一個可以找到所有問題報告的地方。

藉助指令碼查詢維護者

對於手頭有 Linux 原始碼的人來說，還有第二種方法可以找到合適的報告地點：指令碼“scripts/get_maintainer.pl”，它試圖找到所有要聯絡的人。它查詢 MAINTAINERS 檔案，並且需要使用相關原始碼的路徑進行呼叫。對於作為模組編譯的驅動程式，通常可以使用如下命令找到它：

$ modinfo ath10k_pci | grep filename | sed 's!/lib/modules/.*/kernel/!!; s!filename:!!; s!\.ko\(\|\.xz\)!!'
drivers/net/wireless/ath/ath10k/ath10k_pci.ko

將其中一部分傳遞給指令碼：

$ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k*
Some Human <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)

不要將您的報告發送給他們所有人。將其傳送給維護者，指令碼稱之為“支持者：”；此外，還要抄送程式碼最具體的郵件列表以及 Linux 核心郵件列表 (LKML)。在這種情況下，您需要將報告發送給“Some Human <shuman@example.com>”，並抄送 ‘ath10k@lists.infradead.org’ 和 ‘linux-kernel@vger.kernel.org’。

注意：如果您使用 git 克隆了 Linux 原始碼，您可能需要再次使用 --git 呼叫 get_maintainer.pl。指令碼 then will look at the commit history to find which people recently worked on the code in question, as they might be able to help. But use these results with care, as it can easily send you in a wrong direction. That for example happens quickly in areas rarely changed (like old or unmaintained drivers): sometimes such code is modified during tree-wide cleanups by developers that do not care about the particular driver at all。

搜尋現有報告，第二次執行

徹底搜尋相關 bug 跟蹤器或郵件列表的歸檔，尋找可能與您問題匹配的報告。如果您找到任何內容，請加入討論，而不是傳送新的報告。

正如前面提到的：報告他人已經提出的問題通常會浪費所有相關人員的時間，尤其是您作為報告者。這就是為什麼您應該再次搜尋現有報告，現在您知道它們需要報告到哪裡了。如果是郵件列表，您通常會在 lore.kernel.org 上找到其存檔。

但有些列表託管在不同的地方。例如，上一步中用作示例的 ath10k WiFi 驅動程式就是這種情況。但您通常可以在網上輕鬆找到這些列表的存檔。例如，搜尋“archive ath10k@lists.infradead.org”將引導您進入ath10k 郵件列表的資訊頁面，該頁面頂部連結到其列表存檔。遺憾的是，這個和不少其他列表缺少搜尋存檔的方式。在這種情況下，請使用常規的網際網路搜尋引擎，並在您的搜尋詞中新增類似“site:lists.infradead.org/pipermail/ath10k/”的內容，這將把結果限制在該 URL 的存檔中。

此時再次檢查網際網路、LKML 以及可能存在的 bugzilla.kernel.org 也是明智之舉。如果您的報告需要提交到錯誤跟蹤器，您可能還需要檢查子系統的郵件列表存檔，因為有人可能只在那裡報告了它。

有關如何搜尋以及如果找到匹配報告如何處理的詳細資訊，請參閱上面的“搜尋現有報告，第一次執行”。

在報告過程的這一步不要著急：花費 30 到 60 分鐘甚至更多時間可以為您和他人節省大量時間和麻煩。

安裝新的核心進行測試

除非您已經在執行最新的“主線”Linux 核心，否則最好安裝它以進行報告。在某些情況下，使用最新的“穩定版”Linux 進行測試和報告是可接受的替代方案；在合併視窗期間，這實際上可能是最佳方法，但在該開發階段，無論如何，暫停您的努力幾天可能是一個更好的主意。無論您選擇哪個版本，理想情況下都使用“原版”構建。忽略這些建議將大大增加您的報告被拒絕或忽略的風險。

正如第一步的詳細解釋中已經提到的：像大多數程式設計師一樣，Linux 核心開發人員不喜歡花時間處理甚至在當前程式碼中都沒有發生的問題報告。這只是浪費每個人的時間，尤其是您的時間。這就是為什麼確認問題在報告之前仍然存在於最新的上游程式碼中符合每個人的利益。您可以自由地忽略此建議，但如前所述：這樣做會大大增加您的問​​題報告被拒絕或簡單地忽略的風險。

在核心範圍內，“最新上游”通常意味著：

  • 安裝主線核心；最新穩定版核心可能是一個選項，但大多數情況下最好避免。長期支援核心（有時稱為“LTS 核心”）在此過程的此時不適用。下一小節將更詳細地解釋所有這些。

  • 接下來的小節描述了獲取和安裝此類核心的方法。它還概述了使用預編譯核心是可以的，但最好是原版，這意味著：它是使用直接從 kernel.org 獲取的 Linux 原始碼構建的，並且沒有任何修改或增強。

選擇正確的版本進行測試

前往 kernel.org 找出您想用於測試的版本。忽略那個寫著“最新版本”的大黃色按鈕，向下一點看錶格。在它的頂部，您會看到一行以 mainline 開頭，它大多數時候會指向一個版本號類似“5.8-rc2”的預釋出版。如果是這種情況，您將需要使用這個主線核心進行測試，因為所有修復都必須首先應用到那裡。不要讓那個“rc”嚇到您，這些“開發核心”相當可靠——而且您已經按照上面的指示做好了備份，不是嗎？

大約每九到十週就有兩次，主線版本可能會指向一個正式釋出版，版本號類似“5.7”。如果發生這種情況，請考慮暫停報告過程，直到下一個版本（5.8-rc1）的第一個預釋出版出現在 kernel.org 上。這是因為 Linux 開發週期正處於其為期兩週的“合併視窗”期。大部分更改和所有侵入性更改都在此期間合併到下一個版本。在此期間使用主線版本風險稍大。核心開發人員那時通常也相當忙碌，可能沒有空閒時間處理問題報告。在合併視窗期間應用的眾多更改之一也很有可能修復您面臨的問題；這就是為什麼您遲早需要使用更新的核心版本重新測試，正如本文件後面“報告發出後的職責”一節中概述的那樣。

這就是為什麼等待合併視窗結束可能是有意義的。但如果您處理的是不應該等待的事情，請不要這樣做。在這種情況下，請考慮透過 git 獲取最新的主線核心（見下文）或使用 kernel.org 上提供的最新穩定版本。如果主線版本由於某種原因目前對您不起作用，使用它也是可以接受的。總的來說：用它來重現問題也比完全不報告問題要好。

在合併視窗之外，最好避免使用最新的穩定版核心，因為所有修復都必須首先應用到主線版本。這就是檢查最新的主線核心如此重要的原因：任何您希望在舊版本線中修復的問題都需要首先在主線版本中修復，然後才能反向移植，這可能需要幾天或幾周的時間。另一個原因：您所希望的修復可能對反向移植來說太困難或風險太大；因此，再次報告問題不太可能改變任何事情。

這些方面也是長期支援核心（有時稱為“LTS 核心”）不適用於報告過程此部分的原因：它們與當前程式碼相距太遠。因此，請先測試主線版本並繼續執行後續過程：如果問題在主線版本中未發生，它將指導您如何在舊版本線中修復它（如果該修復程式在考慮範圍內）。

如何獲取新的 Linux 核心

使用預編譯核心：這通常是測試最快、最簡單、最安全的方式——特別是如果您不熟悉 Linux 核心。問題是：大多數由發行版或附加倉庫提供的核心都是從修改過的 Linux 原始碼構建的。因此它們不是原版的，因此通常不適合測試和問題報告：這些更改可能會導致您面臨的問題或以某種方式影響它。

但如果您使用的是流行的 Linux 發行版，那您很幸運：對於其中不少發行版，您會在網上找到包含最新主線或穩定 Linux 的原版核心軟體包的倉庫。使用這些軟體包是完全可以的，只需確保倉庫描述中說明它們是原版的或者至少接近原版。此外，還要確保軟體包包含 kernel.org 上提供的最新版本。如果軟體包的版本比一週還舊，它們可能就不合適了，因為新的主線和穩定核心通常至少每週釋出一次。

請注意，您可能需要在以後手動構建自己的核心：這有時是除錯或測試修復所必需的，如本文件後面所述。另請注意，預編譯核心可能缺少除錯符號，這些符號在核心列印 panic、Oops、警告或 BUG 訊息時需要解碼；如果您計劃解碼這些，您最好自己編譯一個核心（有關詳細資訊，請參閱本小節末尾和題為“解碼故障訊息”的部分）。

使用 git：開發人員和熟悉 git 的經驗豐富的 Linux 使用者通常最好直接從 kernel.org 上的官方開發倉庫獲取最新的 Linux 核心原始碼。這些原始碼可能比最新的主線預釋出版稍早一些。不用擔心：它們和正式的預釋出版一樣可靠，除非核心的開發週期目前正處於合併視窗中間。但即使如此，它們也相當可靠。

常規方式：不熟悉 git 的人通常最好從 kernel.org 下載 tarball 格式的原始碼。

這裡不描述如何實際構建核心，因為許多網站已經解釋了必要的步驟。如果您是新手，可以考慮遵循那些建議使用 make localmodconfig 的操作指南，因為它會嘗試獲取您當前核心的配置，然後嘗試為您的系統進行一些調整。這並不會讓生成的核心變得更好，但可以更快地編譯。

注意：如果您遇到核心的 panic、Oops、warning 或 BUG，請在配置核心時嘗試啟用 CONFIG_KALLSYMS。此外，還要啟用 CONFIG_DEBUG_KERNEL 和 CONFIG_DEBUG_INFO；後者是兩者中相關的那個，但只有啟用前者才能達到。請注意，CONFIG_DEBUG_INFO 會相當大地增加構建核心所需的儲存空間。但這值得，因為這些選項稍後將允許您精確定位觸發您問題的確切程式碼行。下面的“解碼故障訊息”部分將更詳細地解釋這一點。

但請記住：如果問題難以重現，請務必記錄下遇到的問題。傳送一份未解碼的報告總比完全不報告問題要好。

檢查“汙染”標誌

確保您剛剛安裝的核心在執行時不會“汙染”自己。

正如上面已經詳細概述的：當發生可能導致完全不相關的後續錯誤的情況時，核心會設定一個“汙染”標誌。這就是為什麼您需要檢查您剛剛安裝的核心是否沒有設定此標誌。如果設定了，在幾乎所有情況下，您都需要消除其原因，然後才能報告由此引發的問題。有關如何執行此操作的詳細資訊，請參閱上面的部分。

用新核心重現問題

使用您剛剛安裝的核心重現問題。如果問題沒有出現，請向下滾動到僅在穩定版和長期支援版核心中出現的問題的說明。

檢查您剛剛安裝的最新 Linux 核心版本是否出現該問題。如果問題已經修復，請考慮繼續使用此版本線並放棄報告問題的計劃。但請記住，只要 kernel.org 的穩定版和長期支援版（以及由此衍生的廠商核心）尚未修復此問題，其他使用者可能仍會受到其困擾。如果您更喜歡使用其中一個版本或只是想幫助其使用者，請參閱下面的“關於僅在舊核心版本線中發生的問題報告的詳細資訊”一節。

最佳化重現問題的描述

最佳化您的筆記：嘗試找到並寫下重現問題的最直接方法。確保最終結果包含所有重要細節，同時對於初次聽說的人來說易於閱讀和理解。如果您在此過程中學到了什麼，請考慮再次搜尋有關該問題的現有報告。

不必要的複雜報告會使他人難以理解您的報告。因此，請嘗試找到一個易於描述且易於書面理解的重現方法。包含所有重要細節，但同時儘量保持簡短。

在此以及之前的步驟中，您可能已經學到了一些關於您面臨的問題。利用這些知識，再次搜尋現有報告，看看是否有您可以加入的。

解碼故障訊息

如果您的故障涉及“panic”、“Oops”、“warning”或“BUG”，請考慮解碼核心日誌以找到觸發錯誤的原始碼行。

當核心檢測到內部問題時，它會記錄一些關於已執行程式碼的資訊。這使得精確定位原始碼中觸發問題的確切行以及其如何被呼叫成為可能。但這隻有在您配置核心時啟用了 CONFIG_DEBUG_INFO 和 CONFIG_KALLSYMS 才能實現。如果您這樣做了，請考慮解碼來自核心日誌的資訊。這將使理解導致“panic”、“Oops”、“warning”或“BUG”的原因變得容易得多，從而增加了有人提供修復的機會。

解碼可以使用 Linux 原始碼樹中的指令碼完成。如果您正在執行您自己早些時候編譯的核心，請像這樣呼叫它：

[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux

如果您正在執行一個打包的原版核心，您可能需要安裝帶有除錯符號的相應軟體包。然後像這樣呼叫指令碼（如果您的發行版沒有打包它，您可能需要從 Linux 原始碼中獲取它）：

[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \
 /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/

該指令碼將處理如下所示的日誌行，這些日誌行顯示了錯誤發生時核心正在執行的程式碼地址：

[   68.387301] RIP: 0010:test_module_init+0x5/0xffa [test_module]

解碼後，這些行將如下所示：

[   68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:16) test_module

在這種情況下，執行的程式碼是從檔案“~/linux-5.10.5/test-module/test-module.c”構建的，錯誤發生在“16”行中的指令處。

指令碼將類似地解碼以“Call trace”開頭的段落中提及的地址，這些地址顯示了問題發生函式的路徑。此外，指令碼還將顯示核心正在執行的程式碼段的彙編輸出。

注意，如果您無法完成此操作，只需跳過此步驟並在報告中說明原因。如果您幸運的話，可能不需要它。如果需要，可能會有人幫助您解決問題。另請注意，這只是解碼核心堆疊跟蹤的幾種方法之一。有時可能需要不同的步驟才能檢索相關細節。不用擔心，如果您的案例需要，開發人員會告訴您該怎麼做。

迴歸的特殊處理

如果您的問題是迴歸，請儘量縮小問題引入的時間範圍。

Linux 首席開發者 Linus Torvalds 堅持認為 Linux 核心絕不能惡化，因此他認為迴歸是不可接受的，並希望它們能迅速得到修復。這就是為什麼引入迴歸的更改如果其引起的問題無法透過其他方式迅速解決，通常會被立即回滾。因此，報告迴歸有點像打出一張王牌，以期迅速得到修復。但要實現這一點，導致迴歸的更改需要已知。通常，跟蹤罪魁禍首是報告者的責任，因為維護者通常沒有時間或設定來自己重現它。

為了找到這種變化，有一個稱為“二分法”的過程，文件二分法尋找回歸對此進行了詳細描述。這個過程通常要求您構建大約十到二十個核心映象，每次構建下一個映象之前都要嘗試重現問題。是的，這需要一些時間，但不用擔心，它的工作速度比大多數人想象的要快得多。藉助“二分查詢”，這將引導您找到原始碼管理系統中導致迴歸的那一次提交。一旦找到它，請在網上搜索該更改的主題、其提交 ID 和縮短的提交 ID（提交 ID 的前 12 個字元）。如果存在任何關於它的現有報告，這將引導您找到它們。

請注意，二分法需要一些專業知識，並非每個人都具備，並且需要相當大的努力，並非每個人都願意投入。儘管如此，強烈建議您自己執行二分法。如果您確實不能或不想走這條路，至少找出哪個主線核心引入了迴歸。例如，如果從 5.5.15 切換到 5.8.4 時出現問題，那麼至少嘗試在該區域的所有主線版本（5.6、5.7 和 5.8）來檢查它何時首次出現。除非您嘗試在穩定版或長期支援版核心中查找回歸，否則請避免測試版本號有三部分的版本（5.6.12、5.7.8），因為這會使結果難以解釋，這可能使您的測試變得無用。一旦您找到引入迴歸的主要版本，請隨意繼續報告過程。但請記住：開發人員是否能夠在不知道罪魁禍首的情況下提供幫助取決於具體問題。有時他們可能會從報告中識別出問題所在並修復它；其他時候，除非您執行二分法，否則他們將無法提供幫助。

在處理迴歸問題時，請確保您面臨的問題確實是由核心引起的，而不是由其他原因引起的，如上文所述。

在整個過程中請記住：只有當舊核心和新核心使用相似的配置構建時，問題才符合迴歸的條件。這可以透過使用 make olddefconfig 來實現，正如 報告迴歸 中更詳細的解釋；該文件還提供了許多您可能需要了解的關於迴歸的其他資訊。

編寫併發送報告

透過詳細描述問題來開始撰寫報告。始終提及幾件事：您為重現而安裝的最新核心版本、所使用的 Linux 發行版以及您關於如何重現問題的注意事項。理想情況下，將核心的構建配置 (.config) 和 dmesg 的輸出釋出到網上某個地方並提供連結。包含或上傳所有其他可能相關的資訊，例如 Oops 的輸出/螢幕截圖或 lspci 的輸出。寫完主要部分後，在頂部插入一個正常長度的段落，快速概述問題和影響。在此之上再新增一句話，簡要描述問題並吸引人們繼續閱讀。現在給它一個描述性的標題或主題，再次要更短。然後，您就可以按照 MAINTAINERS 檔案告訴您的方式傳送或提交報告了，除非您正在處理“高優先順序問題”之一：它們需要特殊處理，這在下面“高優先順序問題的特殊處理”中解釋。

現在您已經準備好一切，是時候撰寫報告了。如何撰寫部分地由上面序言中連結的三個文件解釋。因此，本文只提及一些要點以及 Linux 核心特有的事項。

有一點符合這兩類：報告最關鍵的部分是標題/主題、第一句話和第一段。開發人員通常會收到大量的郵件。因此，他們通常只會花幾秒鐘快速瀏覽一封郵件，然後決定是繼續還是仔細檢視。因此：您的報告頂部部分越好，有人檢視並幫助您的機會就越高。這就是為什麼您現在應該忽略它們，先撰寫詳細報告。 ;-)

每個報告都應提及的事項

詳細描述您的問題是如何在使用您安裝的全新原版核心時發生的。嘗試包含您之前編寫和最佳化的逐步說明，這些說明概述了您以及理想情況下其他人如何重現問題；在極少數不可能的情況下，請嘗試描述您為觸發問題所做的操作。

還應包含其他人理解問題及其環境可能需要的所有相關資訊。實際需要什麼很大程度上取決於問題，但有些事情您應該始終包含：

  • 來自 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 上建立的工單等），並在您的報告中包含它們的連結。理想情況下，使用可以使檔案保留多年的方式，因為它們可能在許多年後對某人有用；例如，如果五年或十年後，開發人員正在處理某個僅為修復您的問題而更改的程式碼，就可能發生這種情況。

  • 將檔案放在一邊，並說明您將在稍後的回覆中單獨傳送它們。只記得在報告發出後實際這樣做。;-)

可能需要提供的明智資訊

根據問題，您可能需要新增更多背景資料。以下是一些通常建議提供的內容：

  • 如果您正在處理核心的“warning”、“OOPS”或“panic”，請將其包含在內。如果您無法複製貼上，請嘗試捕獲 netconsole 跟蹤或至少擷取螢幕截圖。

  • 如果問題可能與您的計算機硬體有關，請提及您使用的系統型別。例如，如果您遇到顯示卡問題，請提及製造商、顯示卡型號以及使用的晶片。如果是筆記型電腦，請提及其名稱，但要確保其有意義。例如，“Dell XPS 13”就沒有意義，因為它可能是 2012 年的型號；雖然它與現在銷售的型號看起來差別不大，但除此之外，兩者沒有任何共同之處。因此，在這種情況下，請新增確切的型號，例如 2019 年推出的 XPS 13 型號為“9380”或“7390”。像“Lenovo 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，由音訊/聲音子系統開發人員提供。

這些示例應該能給您一些關於哪些資料可能值得附加的想法，但您需要自己思考哪些對其他人會有幫助。不用太擔心遺漏什麼，因為開發人員會要求您提供他們需要的額外細節。但從一開始就提供所有重要資訊會增加有人會仔細檢視的機會。

重要部分：報告的開頭

現在您已經準備好報告的詳細部分，讓我們來看看最重要的部分：前幾句話。因此，請回到頂部，在您剛剛寫的部分之前新增類似“The detailed description:”的內容，並在頂部插入兩個新行。現在寫一個正常長度的段落，大致描述問題。省略所有無聊的細節，專注於讀者需要了解的關鍵部分，以便理解整個情況；如果您認為此錯誤會影響大量使用者，請提及這一點以引起人們的興趣。

完成此操作後，在頂部再插入兩行，並寫一個一句話的摘要，快速解釋報告的內容。之後，您必須更加抽象，為報告寫一個更短的主題/標題。

現在您已經寫好了這部分，花些時間最佳化它，因為它是您報告中最重要的部分：很多人只會閱讀這部分，然後決定是否值得花時間閱讀其餘部分。

現在，按照 MAINTAINERS 檔案告訴您的那樣傳送或提交報告，除非它是前面概述的那些“高優先順序問題”之一：在這種情況下，請先閱讀下一小節，然後再發送報告。

高優先順序問題的特殊處理

高優先順序問題的報告需要特殊處理。

嚴重問題：確保主題或工單標題以及第一段清楚地表明其嚴重性。

迴歸：使報告的主題以“[REGRESSION]”開頭。

如果您成功地進行了二分法，請使用引入迴歸的更改的標題作為主題的第二部分。報告中還要提及罪魁禍首的提交 ID。如果二分法不成功，請在報告中提及最新測試的正常工作版本（例如 5.7）和問題出現的最早版本（例如 5.8-rc1）。

透過郵件傳送報告時，抄送 Linux regressions 郵件列表 (regressions@lists.linux.dev)。如果報告需要提交到某個網路跟蹤器，請繼續進行。提交後，透過郵件將報告轉發給 regressions 列表；抄送維護者和相關子系統的郵件列表。確保將轉發的報告嵌入郵件正文，因此不要作為附件。還在郵件頂部新增簡短說明，提及工單的 URL。

郵寄或轉發報告時，如果二分法成功，請將罪魁禍首的作者新增到收件人列表中；還要抄送 signed-off-by 鏈中的每個人，您可以在其提交訊息的末尾找到這些資訊。

安全問題：對於這些問題，您需要評估公開披露細節是否會給其他使用者帶來短期風險。如果不是，只需按所述方式報告問題即可。對於具有此類風險的問題，您將需要稍微調整報告流程：

  • 如果 MAINTAINERS 檔案指示您透過郵件報告問題，請不要抄送任何公共郵件列表。

  • 如果您應該在錯誤跟蹤器中提交問題，請務必將工單標記為“私有”或“安全問題”。如果錯誤跟蹤器不提供將報告保密的方式，請放棄並改為將您的報告作為私人郵件傳送給維護者。

在這兩種情況下，請務必將您的報告也傳送到 MAINTAINERS 檔案中“security contact”部分列出的地址。理想情況下，在傳送報告時直接抄送他們。如果您在錯誤跟蹤器中提交了報告，請將報告文字轉發到這些地址；但在其頂部附上一個小說明，提及您已提交併附上工單鏈接。

有關更多資訊，請參閱安全漏洞。

報告發出後的職責

等待回應，並持續跟進，直到您能接受某種結果。因此，請公開並及時回應任何詢問。測試提議的修復。進行主動測試：至少對新主線版本的每一個第一個釋出候選版 (RC) 進行重新測試，並報告您的結果。如果事情停滯不前，請傳送友善的提醒。如果您沒有得到任何幫助或結果不盡如人意，請嘗試自助。

如果您的報告寫得好，並且您非常幸運，那麼其中一位開發人員可能會立即發現問題所在；他們可能會編寫一個補丁來修復它，測試它，並直接傳送到主線進行整合，同時標記它以便稍後反向移植到需要的穩定版和長期支援版核心。那麼您所需要做的就是回覆“非常感謝”，並在修復版本釋出後切換到該版本。

但這種理想情況很少發生。這就是為什麼一旦報告發出，工作才剛剛開始。您將不得不做些什麼取決於具體情況，但通常會是下面列出的事情。但在深入細節之前，請牢記在此過程的這部分需要注意的幾點重要事項。

進一步互動的通用建議

始終公開回復：當您在錯誤跟蹤器中提交問題時，請始終在那裡回覆，不要私下聯絡任何開發人員。對於郵件報告，回覆任何收到的郵件時，請始終使用“回覆全部”功能。這包括包含您可能想要新增到報告中的任何額外資料的郵件：轉到您的郵件應用程式的“已傳送”資料夾，並使用“回覆全部”回覆您包含報告的郵件。這種方法將確保公共郵件列表以及隨著時間推移參與其中的所有人都能保持同步；它還會保持郵件主題的完整性，這對於郵件列表將所有相關郵件分組尤其重要。

只有兩種情況下，錯誤跟蹤器中的評論或“回覆全部”是不合適的：

  • 有人告訴您私下發送某些內容。

  • 您被告知要傳送某些內容，但發現其中包含需要保密的敏感資訊。在這種情況下，可以私下發送給請求該資訊的開發者。但請在工單或郵件中註明您已傳送，以便其他人知道您已履行請求。

在尋求澄清或幫助之前進行研究：在此過程的這部分中，有人可能會告訴您做一些需要您尚未掌握技能的事情。例如，您可能會被要求使用一些您從未聽說過的測試工具；或者您可能會被要求將補丁應用到 Linux 核心原始碼以測試它是否有幫助。在某些情況下，傳送回覆詢問如何操作是可以的。但在走這條路之前，嘗試透過搜尋網際網路自己找到答案；或者考慮在其他地方尋求建議。例如，向朋友尋求幫助，或者將其釋出到您通常會去的聊天室或論壇。

要有耐心：如果您真的幸運，您可能會在幾小時內收到報告的回覆。但大多數時候會需要更長的時間，因為維護者分佈在全球各地，因此可能處於不同的時區——一個他們已經享受夜晚、遠離鍵盤的時區。

一般來說，核心開發人員將在一到五個工作日內回覆報告。有時會需要更長的時間，因為他們可能忙於合併視窗、其他工作、參加開發者大會，或者僅僅是享受漫長的暑假。

“高優先順序問題”（參見上文解釋）是例外：維護者應儘快處理它們；因此，您最多應等待一週（或如果緊急，只需兩天）再發送友善的提醒。

有時維護者可能沒有及時回覆；有時可能會出現分歧，例如一個問題是否符合迴歸的條件。在這種情況下，請在郵件列表上提出您的擔憂，並請求其他人公開或私下回復如何繼續。如果這失敗了，可能適合讓更高許可權的人員介入。如果是 Wi-Fi 驅動程式問題，那將是無線維護者；如果沒有更高級別的維護者或所有其他方法都失敗了，這可能是少數可以聯絡 Linus Torvalds 的情況之一。

主動測試：每當新的主線核心版本（“rc1”）的第一個預釋出版本釋出時，請檢查問題是否已修復或是否有任何重要變化。在工單中或在您回覆報告的郵件中提及結果（確保所有參與討論的人都在抄送列表中）。這將表明您的承諾和您願意提供幫助。它還會告訴開發人員問題是否仍然存在，並確保他們不會忘記它。偶爾進行其他一些重新測試（例如，使用 rc3、rc5 和最終版本）也是一個好主意，但只有當有相關變化或您無論如何都在撰寫內容時才報告您的結果。

拋開所有這些一般性問題，讓我們深入探討如何幫助解決已報告的問題。

詢問和測試請求

以下是您收到報告回覆時應盡的職責：

檢查您在與誰打交道：大多數時候，回覆您報告的將是特定程式碼區域的維護者或開發人員。但由於問題通常是公開報告的，回覆的人可能是任何人——包括那些想提供幫助，但最終可能會用他們的問題或請求完全誤導您的人。這種情況很少發生，但這是許多原因之一，為什麼快速進行網際網路搜尋以檢視您正在與誰互動是明智之舉。透過這樣做，您還可以瞭解您的報告是否被正確的人聽到，因為如果討論在沒有導致令人滿意的解決方案的情況下逐漸平息，稍後可能需要提醒維護者（見下文）。

資料查詢：您經常會被要求測試某些東西或提供額外的細節。請儘快提供所需的資訊，因為您正在獲得可能提供幫助的人的關注，等待時間越長，失去這種關注的風險就越大；如果您在幾個工作日內未能提供資訊，這種結果甚至很有可能發生。

測試請求：當您被要求測試診斷補丁或可能的修復時，也請嘗試及時測試。但要正確地做，並確保不要急於求成：混淆很容易發生，並可能給所有相關人員帶來很多困惑。一個常見的錯誤例如是認為一個提出的修復補丁已經應用，但實際上並沒有。即使是經驗豐富的測試人員偶爾也會發生這樣的事情，但他們大多數時候會注意到，如果帶有修復的核心表現得和沒有修復的核心一樣。

當沒有實質性進展時該怎麼辦

一些報告將得不到負責任的 Linux 核心開發人員的任何回應；或者圍繞該問題的討論已經展開，但最終沒有取得任何實質性成果。

在這些情況下，等待兩週（最好是三週）再發送友善的提醒：也許維護者在您報告到達時暫時離開了鍵盤，或者有更重要的事情要處理。在撰寫提醒時，請禮貌地詢問是否還需要您做些什麼來推動事情的進展。如果報告是透過郵件發出的，請在回覆您最初郵件的第一行中這樣做（見上文），並在下方包含原始報告的完整引用：這是少數幾個“TOFU”（Text Over, Fullquote Under）是正確方法的例子之一，因為這樣所有收件人都可以立即以正確的順序掌握詳細資訊。

提醒後，再等三週等待回覆。如果您仍然沒有得到適當的回覆，您應該首先重新考慮您的方法。您是否可能嘗試聯絡了錯誤的人？報告是否冒犯性或混亂到人們決定完全遠離它？排除這些因素的最佳方法是：將報告展示給一兩個熟悉自由/開源軟體（FLOSS）問題報告的人，並徵求他們的意見。同時詢問他們如何繼續的建議。這可能意味著：準備一份更好的報告，並在傳送之前請這些人審閱。這種方法完全可以；只需提及這是關於該問題的第二份改進報告，幷包含指向第一份報告的連結。

如果報告得當，您可以傳送第二次提醒；其中詢問報告為何沒有收到任何回覆的原因。傳送第二次提醒郵件的最佳時機是在新的 Linux 核心版本（“rc1”）的第一個預釋出版本釋出後不久，因為那時您無論如何都應該重新測試並提供狀態更新（見上文）。

如果第二次提醒在一週內仍然沒有收到任何回覆，請嘗試聯絡更高級別的維護者尋求建議：即使是忙碌的維護者，到那時也至少應該傳送某種確認資訊。

請記住為失望做好準備：維護者理想情況下應該對每個問題報告做出某種回應，但他們只負責修復前面概述的那些“高優先順序問題”。所以，如果您收到類似“感謝您的報告，我目前有更重要的問題要處理，在可預見的將來沒有時間研究這個問題”的回覆，請不要過於沮喪。

也有可能在錯誤跟蹤器或列表上經過一些討論後，問題不再有任何進展，且提醒也無法促使任何人著手修復。這種情況可能令人沮喪，但在 Linux 核心開發中是可能發生的。本文件末尾的“為什麼有些問題得不到任何回應或報告後仍未修復”解釋了這種情況以及其他幾個得不到幫助的原因。

如果您沒有找到任何幫助，或者問題最終沒有得到解決，請不要沮喪：Linux 核心是自由/開源軟體（FLOSS），因此您仍然可以自助。例如，您可以嘗試找到受影響的其他人，並與他們合作解決問題。這樣的團隊可以一起準備一份新的報告，其中提及您有多少人以及為什麼您認為這應該得到修復。也許透過合作，您還可以縮小根本原因或引入迴歸的變更，這通常會使開發修復更容易。並且如果幸運的話，團隊中可能有人對程式設計有所瞭解，並可能能夠編寫一個修復程式。

“報告穩定版和長期支援版核心線中的迴歸”參考

本小節詳細說明了如果您在穩定版和長期支援版核心系列中遇到迴歸時需要執行的步驟。

確保特定版本線仍然獲得支援

檢查核心開發者是否仍在維護您所關心的 Linux 核心版本線：前往 kernel.org 的首頁，確保它提到了該特定版本線的最新發布版本，並且沒有“[EOL]”標籤。

大多數核心版本線只支援大約三個月，因為維護它們更長時間工作量很大。因此，每年只會選擇一個版本線，並至少支援兩年（通常是六年）。這就是為什麼您需要檢查核心開發者是否仍在支援您關心的版本線。

請注意，如果 kernel.org 首頁列出了兩個穩定版本線，您應該考慮切換到較新的一個並忘記較舊的一個：對其的支援可能很快就會被放棄。然後它將獲得“生命週期結束”（EOL）標記。達到該點的版本線仍會在 kernel.org 首頁上提及一兩週，但不再適合測試和報告。

搜尋穩定版郵件列表

檢查 Linux 穩定版郵件列表的存檔，查詢現有報告。

您面臨的問題可能已經已知並已修復或即將修復。因此，請搜尋 Linux 穩定版郵件列表的存檔，查詢與您問題類似的報告。如果找到任何匹配項，請考慮加入討論，除非修復已經完成並計劃很快應用。

用最新版本重現問題

將該特定版本系列的最新版本作為原版核心安裝。確保此核心未被汙染且問題仍然存在，因為問題可能已在那裡修復。如果您最初是在供應商核心中注意到此問題，請檢查已知可正常工作的最後一個版本的原版構建是否也執行良好。

在投入更多時間到這個流程之前，您需要檢查您感興趣的版本線的最新發布版是否已經修復了該問題。這個核心必須是原版的，並且在問題發生前不應該被汙染，正如前面“安裝一個新的核心進行測試”一節中詳細概述的那樣。

您是否最初是在廠商核心中注意到迴歸的？那麼廠商應用的更改可能會干擾。您需要透過重新檢查來排除這種情況。假設您從 5.10.4-vendor.42 更新到 5.10.5-vendor.43 時出現了問題。那麼在按照上一段概述的方式測試最新的 5.10 版本後，檢查 Linux 5.10.4 的原版構建是否也正常工作。如果那裡也出現問題，那麼該問題就不符合上游迴歸的條件，您需要返回到主要的分步指南來報告問題。

報告迴歸

傳送一份簡短的問題報告到 Linux stable 郵件列表 (stable@vger.kernel.org)，並抄送 Linux regressions 郵件列表 (regressions@lists.linux.dev)；如果你懷疑問題出在某個特定的子系統，請抄送其維護者及其郵件列表。大致描述問題，並最好解釋如何重現。提及出現問題的第一個版本和工作正常的最後一個版本。然後等待進一步的指示。

當報告發生在穩定版或長期支援版核心系列（例如從 5.10.4 更新到 5.10.5）中的迴歸問題時，一份簡短的報告足以快速地報告問題。因此，一份粗略的描述發給 stable 和 regressions 郵件列表就足夠了；但如果你懷疑問題出在某個特定的子系統，也請抄送其維護者及其郵件列表，因為這會加快處理速度。

請注意，如果你能明確指出引入問題的確切版本，將對開發者有很大幫助。因此，如果在合理的時間範圍內有可能，請嘗試使用原版（vanilla）核心來找到該版本。假設你的發行版從 Linux 核心 5.10.5 更新到 5.10.8 時出現了問題。那麼，按照上述指示，檢查該版本系列中的最新核心，比如 5.10.9。如果它顯示問題，嘗試一個原版 5.10.5 以確保發行版應用的補丁沒有干擾。如果問題在那裡沒有出現，嘗試 5.10.7，然後（根據結果）嘗試 5.10.8 或 5.10.6，以找到問題首次出現的版本。在報告中提及它，並說明 5.10.9 仍然存在問題。

前一段所概述的基本上是一種粗略的手動“二分查詢”。一旦你的報告發出，你可能會被要求進行一次正規的二分查詢，因為它能夠精確定位導致問題的具體變更（這樣就可以很容易地回滾以快速修復問題）。因此，如果時間允許，請考慮立即進行一次正規的二分查詢。有關如何執行二分查詢的詳細資訊，請參閱“迴歸問題的特別處理”部分和文件二分查找回歸問題。如果二分查詢成功，請將被認定為罪魁禍首的作者新增到收件人列表中；同時抄送其提交訊息末尾“signed-off-by”鏈中的所有人。

“僅在舊核心版本系列中出現的問題報告”的參考資料

本節詳細介紹瞭如果你無法使用主線核心重現問題，但希望在舊版本系列（即穩定版和長期支援版核心）中修復它時需要採取的步驟。

有些修復過於複雜

請做好準備，接下來的幾個步驟可能無法在舊版本中解決問題：修復可能太大或風險太高，無法反向移植到那裡。

即使是微小且看似明顯的程式碼更改，有時也會引入新的、完全意想不到的問題。穩定版和長期支援版核心的維護者非常清楚這一點，因此只對這些核心應用符合關於 Linux -stable 釋出版你所想知道的一切中概述的規則的更改。

例如，複雜或有風險的更改不符合條件，因此只應用到主線版本。其他修復很容易回溯到最新的穩定版和長期支援版核心，但整合到舊版本中風險太大。因此請注意，你所期望的修復可能屬於那些不會回溯到你所關心的版本系列的型別。在這種情況下，你別無選擇，只能接受這個問題或切換到較新的 Linux 版本，除非你想自己將修復程式打入你的核心。

通用準備工作

執行上面“僅在舊核心版本系列中出現的問題報告”部分中的前三個步驟。

你需要執行本指南另一部分中已描述的幾個步驟。這些步驟將讓你能夠：

  • 檢查核心開發者是否仍在維護你所關心的 Linux 核心版本系列。

  • 在 Linux stable 郵件列表中搜索已有的報告。

  • 檢查最新發布版。

檢查程式碼歷史並搜尋現有討論

在 Linux 核心版本控制系統中搜索在主線中修復該問題的更改，因為其提交訊息可能會告訴您該修復是否已計劃進行反向移植。如果沒有找到，請在適當的郵件列表中搜索討論此類問題或同行評審可能修復的帖子；然後檢查討論，看看該修復是否被認為不適合反向移植。如果根本沒有考慮反向移植，請加入最新的討論，詢問是否有可能。

在很多情況下，你處理的問題可能已在主線版本中出現，但已在那裡得到修復。修復該問題的提交也需要回溯，才能解決問題。這就是為什麼要搜尋它或任何關於它的討論。

  • 首先嚐試在儲存 Linux 核心原始碼的 Git 倉庫中查詢該修復。你可以透過 kernel.org 上的網頁介面或其映象 GitHub 進行操作；如果你有本地克隆，也可以在命令列上使用 git log --grep=<pattern> 進行搜尋。

    如果你找到了修復，請檢視提交訊息的末尾是否包含一個類似這樣的“stable tag”：

    如果是這種情況，開發者已將該修復標記為可安全回溯到版本系列 5.4 及更高版本。大多數時候它會在兩週內應用到那裡，但有時會花費更長時間。

  • 如果該提交沒有告訴你任何資訊，或者你找不到修復，請再次查詢關於該問題的討論。使用你喜歡的網際網路搜尋引擎以及 Linux 核心開發者郵件列表的存檔來搜尋網路。另外，閱讀上面“定位導致問題的核心區域”部分，並按照指示找到相關子系統：其錯誤跟蹤器或郵件列表存檔可能包含你正在尋找的答案。

  • 如果你看到一個提議的修復，請按照上述方式在版本控制系統中搜索它，因為提交可能會告訴你是否可以預期回溯。

    • 檢查討論中是否有任何跡象表明該修復可能風險太大而無法回溯到你所關心的版本系列。如果是這種情況，你必須接受這個問題，或者切換到應用了該修復的核心版本系列。

    • 如果該修復不包含 stable 標籤並且沒有討論回溯，請加入討論：提及你遇到問題的版本，並說明如果合適，你希望它得到修復。

尋求建議

前面的步驟之一應該能找到解決方案。如果行不通，請向似乎導致問題的子系統的維護者尋求建議；抄送該特定子系統的郵件列表以及穩定版郵件列表。

如果前三個步驟沒有讓你更接近解決方案，那麼只剩下一種選擇：尋求建議。透過郵件將郵件傳送給問題似乎起源的子系統維護者；同時抄送該子系統的郵件列表以及穩定版郵件列表 (stable@vger.kernel.org)。

為什麼有些問題報告後沒有得到任何回應或仍未修復

向 Linux 開發者報告問題時，請注意只有“高優先順序問題”（迴歸、安全問題、嚴重問題）才肯定會得到解決。維護者，或者如果所有其他方法都失敗了，Linus Torvalds 本人會確保這一點。他們和其他核心開發者也會修復許多其他問題。但請注意，有時他們不能或不願提供幫助；有時甚至沒有人可以傳送報告。

這最好用業餘時間為 Linux 核心做出貢獻的核心開發者來解釋。核心中的許多驅動程式都是由這些程式設計師編寫的，通常只是因為他們想讓他們的硬體在他們喜歡的作業系統上可用。

這些程式設計師大多時候都會樂意修復其他人報告的問題。但沒有人能強迫他們這樣做，因為他們是自願貢獻的。

還有些情況是，這些開發者確實想修復一個問題，但不能：有時他們缺乏硬體程式設計文件來做到這一點。這通常發生在公開可用的文件過於膚淺，或者驅動程式是在逆向工程的幫助下編寫的情況下。

遲早，業餘開發者也會停止關心該驅動程式。也許他們的測試硬體壞了，被更 fancy 的東西取代了，或者已經老舊到除了計算機博物館之外很難找到了。有時開發者會完全停止關心他們的程式碼和 Linux，因為他們生活中其他事情變得更重要了。在某些情況下，沒有人願意接管維護者這項工作——而且沒有人能被強迫這樣做，因為對 Linux 核心的貢獻是自願的。然而，被遺棄的驅動程式仍然留在核心中：它們對人們仍然有用，移除將是一種迴歸。

對於那些為 Linux 核心工作而獲得報酬的開發者來說，情況並沒有太大不同。現在大多數更改都是由他們貢獻的。但他們的僱主遲早也會停止關心他們的程式碼，或者讓程式設計師專注於其他事情。例如，硬體供應商主要透過銷售新硬體賺錢；因此他們中很少有人投入大量時間和精力來維護一個他們幾年前停止銷售的產品的 Linux 核心驅動程式。企業 Linux 發行商通常會關心更長的時間，但在新版本中常常放棄對舊的和稀有硬體的支援，以限制範圍。通常，一旦公司放棄了某些程式碼，業餘貢獻者會接手，但正如前面提到的：遲早他們也會放棄這些程式碼。

優先順序是導致某些問題未被修復的另一個原因，因為維護者通常被迫設定優先順序，因為用於 Linux 工作的時間有限。無論是業餘時間，還是僱主授予開發者用於上游核心維護工作的時間，都是如此。有時維護者也會被報告淹沒，即使驅動程式幾乎完美執行。為了不完全陷入困境，程式設計師可能別無選擇，只能對問題報告進行優先順序排序，並拒絕其中的一些。

但不必對此過於擔心，許多驅動程式都有活躍的維護者，他們非常樂意修復儘可能多的問題。

結語

與其他自由/開源軟體相比，向 Linux 核心開發者報告問題是困難的：本文件的篇幅和複雜性以及字裡行間的含義都說明了這一點。但目前情況就是如此。本文的主要作者希望透過記錄現狀，能為隨著時間推移改善這種情況奠定一些基礎。