該問題與內核未退出省電模式有關
最近 發布了關於錯誤 b 的信息在服務器處理器系列中非常特別 AMD EPYC 7002 （“羅馬”）基於自 2 年以來分發的“Zen 2018”微架構。
這就是有問題的裁決 導致處理器在運行 1044 天后掛起 連續的（一種相當特殊的情況，這種情況並不常見。
一個簡短的帖子來自 AMD 表示第二代服務器處理器遇到問題 這 防止內核退出 Core C6 State 省電模式 （或 CC6）經過長時間的運行週期。 同時，製造商聲稱1044天不是一個絕對值，因為故障可能發生得更早或更晚，因為 這完全取決於 REFCLK 的頻率， 它允許處理器跟踪時間參數和其他一些因素。 但是製造商並沒有提供任何信息來說明故障發生的確切原因，因此直到現在都沒有人確切地了解故障的根源是什麼。
失敗 因此它將處理器置於“殭屍”模式，其中它不接受任何命令或外部中斷請求並保持此狀態，除非它重新啟動。
這些 C 狀態模式從 C0 開始，這是 CPU 的正常運行模式。 C 數越高，CPU 進入休眠模式的深度越深，關閉的信號也越多。 睡眠狀態越深，CPU 完全喚醒所需的時間就越長。
有了這個錯誤，一旦 CPU 進入 C6 超過 1044 天標記，它就會卡住並需要重新啟動。 解決方案是在三年前重新啟動服務器或禁用導致錯誤的睡眠狀態。
AMD沒有提供更詳細的解釋 失敗的原因。 根據假設判斷 發佈在 Reddit 上：
當 TSC 寄存器（Time Stamp Counter）中的計數器（計數復位後的工作週期數）在 2800 MHz 的頻率下達到值 0x380000000000000（2800 MHz * 10* *6 * 1042,5, 1042,即 12 天 XNUMX 小時後）。
除此之外， AMD 已經提到不會發布錯誤修復，因為這個問題很長一段時間都沒有引起注意，因為對於需要定期重新啟動以安裝內核更新或遷移到新操作系統版本以保持最新狀態的服務器來說，多年的正常運行時間並不典型。
然而，Linux 發行版的免重啟內核升級方式和較長的維護週期（Ubuntu、RHEL 和 SUSE 支持 10 年）會導致服務器等待時間過長而無需重啟。
公司代表表示，目前 有兩種方案可以解決這個問題： l這些處理器的服務器所有者必須 重新啟動系統 將計時器重置為 1044 天所以完全禁用Core C6 State省電模式。 可能這兩個選項都非常不適合服務器處理器的所有者 - 省電模式，因為它可以節省大量的電力消耗，所以顯然沒有人會關閉它並等待錯誤發生並凍結，然後重新啟動系統也不是一個非常方便的解決方案。 特別是當涉及到一些非常重要的基礎設施組件時。
值得一提的是 這種類型的錯誤在處理器領域並不少見 （無論它們是用於服務器還是台式機），因為很多時候商業模型也包含許多錯誤，但隨後他們嘗試使用新版本或基於軟件和固件的修復來修補它們。
終於 如果您有興趣了解更多信息， 我請你諮詢 信息 由 AMD 發布。