Proxmox VEを9.2以降へアップデートし、Linux Kernel 7.0（検証時: 7.0.6-2-pve）で運用を始めた後、AMD Ryzen搭載ホストが予告なく再起動するようになりました。私の環境では、SSDやCephそのものの故障ではなく、ログと切り分け結果から、AMD CPUが深い省電力状態へ移る際の電圧・信号状態の変化に関連した Data Fabric Sync Flood が再起動の直接要因と判断しました。
最終的には、BIOSの Global C-state Control を Disabled に変更することで安定しました。この記事では、発生した症状から実施した対策と注意点まで紹介します。
この記事は私のAMD Ryzen搭載ミニPCとProxmox環境での検証記録です。すべてのAMD製CPU、マザーボード、BIOS、Proxmox VE環境で同じ原因・結果になるとは限りません。BIOSを変更すると消費電力や発熱が変わるため、設定前に現在の値を記録してください。
私の環境では、Proxmox VEを更新してLinux Kernel 7.0系（検証時: 7.0.6-2-pve）で再起動した後から、ホストが予告なく再起動するようになりました。更新前は同じ構成で安定していたため、まずはKernel更新と発生時期が重なっている点を手掛かりに切り分けを始めました。
ここで確認したかったのは、Proxmox VEの表示上のバージョンではなく、その時点で実際に起動しているKernelです。KernelはCPUの省電力制御やNVMe・PCIeなどのデバイス制御を担うため、同じProxmox VE環境でもKernelが変わると挙動が変化することがあります。
# 現在起動しているLinux Kernelを確認
uname -r
# Proxmox VEのバージョンとインストール済みパッケージを確認
pveversion -v私の検証時には、uname -r が 7.0.6-2-pve を返す状態で症状を確認しました。
私の環境では、以下の症状が出ました。
HEALTH_WARN になる最も厄介だったのは、OSがログを書き込む前にリセットされることでした。ログの末尾が唐突に途切れるため、電源ユニット、メモリ、温度、NVMe SSD、マザーボードまで広く疑う必要がありました。
再起動後に dmesg を確認すると、次の記録がありました。
# 再起動理由を確認
dmesg | grep -i "reset reason"x86/amd: Previous system reset reason [0x08000800]:
an uncorrected error caused a data fabric sync flood event0x08000800 は「訂正不能なエラーがData Fabric Sync Floodを引き起こした」という内部CPUイベントを示す値です。
Data Fabric（Infinity Fabric）は、AMD CPU内でCPUコア、メモリコントローラー、PCIeなどを接続する内部の通信経路です。ここで訂正できないエラーが検出されると、破損した状態のまま処理を続けないようにCPUの保護機構が即時リセットを実行します。そのため、OS側のログが残らない再起動として見えます。
クラッシュ前後には、Ceph OSDから以下のようなログも出ていました。
ceph-osd: bdev(.../block) aio_submit retries 10aio_submit は、Cephが非同期I/Oをストレージへ投入する処理です。retries 10 は、要求を出してもすぐに受け付けられず、再試行が発生したことを意味します。
このログだけを見ると、NVMe SSDの故障に見えます。しかし私の環境では、SMARTのメディアエラーとNVMeエラーログがともに0件で、自己診断も正常でした。SMARTはSSDが内部で記録している健康状態・温度・エラーなどの診断情報です。
# NVMeの健康状態、温度、メディアエラーなどを確認
smartctl -a /dev/nvme0この結果から、aio_submit retries はSSDのNAND故障そのものではなく、CPU内部またはPCIe経路の一時的な不安定化によってNVMeコントローラーへアクセスできなくなった二次症状と判断しました。SSDを交換する前に、SMART、温度、リセット理由をセットで確認することが重要です。
AMD Zenアーキテクチャでは、CPUコアの使用率が低いときに消費電力を下げるため、C-state（CPU Idle State）と呼ばれる省電力状態へ段階的に移行します。
C0（処理中）→ C1（浅い休止）→ C2（より深い休止）→ CC6（非常に深い省電力状態）CC6は、使っていないCPUコアの電力を大幅に抑えるための仕組みです。ノートPCなどではバッテリー駆動時間の改善に役立ちます。一方、24時間稼働する仮想化ホストでは、環境によってはCC6への遷移や復帰に伴う電圧・信号状態の切り替えが不安定さを誘発する可能性があります。
今回、再起動が増えた時期はKernel 7.0への更新と重なっています。ただし、Kernel 7.0自体がCC6への移行を積極化した、あるいはData Fabric Sync Floodを直接引き起こしたと断定できる公式な根拠は確認できていません。
AMD CPUの電源管理は、Linux Kernelだけで完結しません。BIOS/UEFIと、CPU内蔵のSMU（System Management Unit）が関与します。SMUはCPU内の管理用コントローラーで、温度、消費電力、クロック、電圧、電源状態などをリアルタイムに管理します。
Linux側では、CPUの性能・周波数要求をP-state、アイドル時の省電力状態をC-stateとして扱います。amd-pstate は前者、つまりP-stateを主に扱うドライバーです。CC6を直接オン・オフする機能ではないため、「amd-pstate が有効になったからCC6が増えた」と単純に結論づけることはできません。
その一方で、Kernelの更新によりCPUの性能制御、アイドル処理、PCIe ASPM、NVMeの省電力制御など複数の条件やタイミングが変わる可能性はあります。ASPMはPCIeリンクがアイドル時に消費電力を下げる仕組みで、NVMeの省電力制御も同様に低負荷時の消費電力を抑える機能です。
私の環境では、こうしたLinux側の変化と、BIOS/UEFI・SMUを含むプラットフォーム側の電源管理の組み合わせにより、以前から潜在していた電圧・信号品質の余裕の少なさが表面化し、Data Fabric Sync Floodにつながった可能性が高いと判断しました。これはログ、発生時期、BIOS変更後に安定した結果に基づく技術的な推定であり、Kernel 7.0がSMUを変更した、またはCC6を直接増やしたことを確認したものではありません。
また、0x08000800 のような前回リセット理由をKernelログへ出す機能が追加されたことで、以前なら原因不明だった異常リセットを把握しやすくなった可能性もあります。
つまり今回確認できた事実は、「Kernel 7.0への更新後に再起動が多発し、ログにData Fabric Sync Floodが記録されたこと」です。Kernel 7.0を唯一の原因と断定するのではなく、更新をきっかけにCPU・BIOS・SMU・電源回路・PCIe/NVMeを含む環境固有の不安定さが顕在化した、と捉えるのが適切です。
最初は、起動時にKernelへ渡す設定値である「カーネルパラメータ」を使い、省電力機能を抑える方法を試しました。Proxmoxでは、通常 /etc/default/grub の GRUB_CMDLINE_LINUX_DEFAULT に追加し、update-grub 実行後に再起動します。
processor.max_cstate=2
pcie_aspm=off
nvme_core.default_ps_max_latency_us=0
idle=nomwait各パラメータの意味は以下の通りです。
| パラメータ | 役割 | 期待した効果 |
|---|---|---|
processor.max_cstate=2 |
OSが利用するCPUのアイドル状態をC2までに制限する | 深いC-stateへの移行を抑える |
pcie_aspm=off |
PCIe ASPM（Active State Power Management）を無効化する | PCIeリンクの省電力遷移を止め、NVMe接続を安定させる |
nvme_core.default_ps_max_latency_us=0 |
NVMe SSDの省電力状態への遷移を実質無効化する | NVMeの省電力復帰に起因する遅延を避ける |
idle=nomwait |
CPUのアイドル処理方法を変更する | 一部環境でのアイドル遷移問題を回避する目的 |
これらの設定で再起動までの時間が延びる場面はありましたが、私の環境では完全には止まりませんでした。カーネルパラメータはLinux側の動作を制限する設定であり、BIOS/UEFIやSMUを含むCPU内部のすべての電源状態を強制的に支配するものではないためです。
カーネルパラメータを恒久設定にする前に、必ず現在のGRUB設定をバックアップしてください。誤った指定で起動できなくなった場合は、Proxmoxのコンソールまたは物理アクセスでの復旧が必要になります。
OSのカーネルパラメータはLinux側の制御ですが、実際のハードウェア電圧や深い省電力状態の制御には、SMUとBIOS/UEFIファームウェアが深く関わります。そこで最終的に、BIOSの Global C-state Control を無効化しました。
Global C-state Control は、CPU全体でC-stateを利用するかを設定する項目です。これを Disabled にすると、BIOS/UEFIからCPUの深い省電力状態を許可しない方針となり、CPUが深いアイドル状態へ入る機会と電圧状態の大きな切り替えを抑えられます。私の環境では、この変更後にカーネルパラメータを外しても安定稼働しました。
一般的な設定場所は以下です。機種やBIOSによって名称・階層は異なります。
起動時にDelまたはF2
→ Advanced
→ AMD CBS
→ CPU Common Options
→ Global C-state Control = Disabled
→ F10で保存して再起動
BIOSによっては Global C-state Control ではなく C-State と表記されている場合もあります。Power Supply Idle Control がある機種では、Typical Current Idle も低負荷時の電源供給を保守的にする設定として選択肢になります。ただし、同時に複数の設定を変えると原因の切り分けが難しくなるため、私はまず Global C-state Control = Disabled だけを適用して確認しました。
BIOS変更後は、一度に全サービスを戻さず、段階的に負荷を戻して確認しました。
dmesg で異常なリセット理由が新たに出ていないか確認するceph status が HEALTH_OK になることを確認するUnsafe Shutdowns、温度、NVMeエラーログを継続監視する# 再起動理由を確認
dmesg | grep -i "reset reason"
# CephのI/Oリトライを確認
dmesg | grep -i "aio_submit"
# Cephクラスタの健全性を確認
ceph status
# NVMeのSMART情報を確認（デバイス名は環境に合わせて変更）
smartctl -a /dev/nvme0Proxmox VE 9.2以降へ更新後、Kernel 7.0系でAMDホストが突然再起動する場合、次の順に切り分けます。
uname -r で実行中のKernelを確認するdmesg に data fabric sync flood または 0x08000800 がないか確認するGlobal C-state Control = Disabled を適用し、十分な期間を監視する設定変更時は必ず変更前の設定値をメモしてから作業し、正常に動作しなかった場合に元に戻せるようにしておくと安心です。リモート環境では、BIOS変更後に復旧できるよう、IPMI、KVM over IP、現地コンソールなどの手段も確保してください。
私の環境では、Proxmox VE 9.2以降への更新後にKernel 7.0系を利用したことをきっかけとして、AMD CPUの深い省電力状態であるCC6付近の電圧制御・Data Fabricの不安定さが表面化しました。CephのI/OリトライはSSD故障ではなく、ホストの内部通信が不安定になった際の二次症状でした。
ただし、Kernel 7.0がCC6移行を積極化した、またはSMUを変更したことは確認できていません。Kernel更新、BIOS/UEFI、SMU、電源回路、PCIe/NVMeの省電力制御が組み合わさって環境固有の不安定さが顕在化した、というのが私の判断です。
カーネルパラメータは原因切り分けや一時的な緩和には役立ちましたが、私の環境で最終的に安定したのは、BIOSの Global C-state Control を Disabled にした後です。消費電力が増える可能性はあるものの、24時間稼働する仮想化ホストでは、突然の再起動を避けることを優先する価値があると考えています。