什麼可能導致系統日誌中出現單個“rcu_sched 檢測到 CPU 上的停頓”警告？
環境：Linux
$$ hostname $$3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux 硬體：AMD Opteron(tm) 處理器 6344、6x2MiB L2、2x8MiB L3、6 核 ht（12 個邏輯核） 今天我在 syslog 中收到警告：
Feb 28 09:58:53 amalthea kernel: [4367033.060016] INFO: rcu_bh detected stall on CPU 10 (t=0 jiffies) Feb 28 09:58:53 amalthea kernel: [4367033.060018] sending NMI to all CPUs:隨後是 CPU 狀態轉儲。日誌中似乎沒有什麼“壞”導致這種情況。
伺服器仍在執行，沒有（明顯）停滯的程序等，並且警告在一個小時內沒有重複，自從它發生以來一直如此。
我瀏覽了有關 RCU 失速檢測器的一些資訊（這對我來說太技術性了，無法真正理解），我可以看到：
- 我的 CPU 因
t=0 jiffies- 沒有“被”CPU“檢測到”
該文件中有一條註釋向我表明這可能是誤報：
$$ “Stall ended before state dump start” $$很少見，但在現實生活中確實時有發生。在這種情況下，也可能會標記零抖動停頓，具體取決於停頓警告和寬限期初始化如何相互作用。請注意，如果不求助於 stop_machine() 之類的東西，就不可能完全消除這種誤報，這對於這類問題來說太過分了。
（強調我的）
我沒有收到“在狀態轉儲開始之前停止”消息，但除了上面顯示的兩條日誌行之後出現的大量 CPU 轉儲之外，我似乎也沒有得到太多其他的診斷資訊。
如果有幫助，我可以從 CPU 轉儲中發布更多資訊。儘管我不是專家，但我沒有什麼大驚小怪的。
是什麼導致了這種情況？
t=0 jiffies僅基於數據點，加上沒有其他診斷資訊列印到日誌，是否可能是誤報？（請注意，這個問題與rcu_sched 在 CPU 上檢測到的停頓不同，後者似乎表明存在“真正的問題”。）
這很可能是由以下三件事之一引起的：
- 一個很難觸發的核心錯誤。不過我認為這不太可能，因為 RCU 的東西對於核心來說是如此的核心，以至於幾乎每個人都可能遇到任何錯誤。
- 壞記憶體。由壞記憶體模組引起的記憶體損壞很容易導致像這樣奇怪的事情發生。
- 由記憶體本身以外的東西引起的暫時性記憶體錯誤。與上述類似，但不太可能再次出現。這是 ECC 記憶體試圖保護的類型（但不能完全防止，因為 ECC 邏輯中完全有可能出現問題）。
除非它再次發生，否則您可能會認為是第 3 種情況並繼續前進。如果它再次發生，請在周圍的核心消息中尋找相似之處和/或檢查您的 RAM。