Atom C3558のQATをFreeBSDで有効化する
Notes on QAT Setup and Caveats for FreeBSD / Atom
以前の記事の続きです。
はじめに
前回、Quanmax MITX-DNVEの詳細・テスト起動までを紹介しました。
FreeBSDをインストールして運用するのにあたって、このAtom C3558に搭載されているIntel QAT(Quick Assist Technology)を有効化する方法をまとめておきます。
QATは暗号処理や圧縮をハードウェアでオフロードできる機能で、C3558にはデフォルトで搭載されています。設定自体は難しくないのですが、FreeBSD 15では記述の順序を間違えるとカーネルパニックになる既知のバグがあるため、その点も含めて記録しておきます。
対象環境
CPU Intel Atom C3558(c3xxx ファミリー)
OS FreeBSD 15.0
有効化手順
/boor/loader.confへ以下を追記するだけです。
ファームウェアを先、ドライバを後に書く順序が重要です。
qat_c3xxx_fw_load="YES"
qat_load="YES"逆順にするとカーネルパニックが発生する可能性があります。その点については後述していきます。
手動ロードの場合は以下のようにターミナルで入力するだけです。
kldload qat_c3xxx_fw
kldload qat動作確認
以下のコマンドで有効かどうか確認していきます。
# モジュール確認
kldstat | grep qat
# デバイス認識確認
dmesg | grep qat正常な出力例は以下のようになっています。qat_ocf0が上がっていれば OCF (OpenCrypto Framework) 経由でカーネルの暗号処理にQATが使われている状態ということです。
$ kldstat | grep qat
19 1 0xffffffff82e65000 122c20 qat_c3xxx_fw.ko
20 1 0xffffffff82f88000 4390 qat.ko
21 6 0xffffffff82f8d000 15dd0 qat_hw.ko
22 9 0xffffffff82fa3000 30010 qat_common.ko
23 8 0xffffffff82fd4000 68cd8 qat_api.ko
$ dmesg | grep qat
qat0: <Intel c3xxx QuickAssist> mem 0xdfb40000-0xdfb7ffff,0xdfb00000-0xdfb3ffff irq 18 at device 0.0 on pci1
qat0: qat_dev0 started 6 acceleration engines
qat0: FW version: 4.18.0
qat0: Excessive clock measure delay
qat_ocf0: <QAT engine>
FreeBSDのバグ
loader.conf経由でドライバをファームウェアより先に記述するとカーネルパニックが発生します。
参考:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283285
qat_c3xxx_fw: could not load firmware image, error 6
Fatal trap 12: page fault while in kernel modeこのバグはファームウェアをドライバより先に記述することで回避可能です。
# OK
qat_c3xxx_fw_load="YES"
qat_load="YES"
# NG
qat_load="YES"
qat_c3xxx_fw_load="YES"※kldloadによる手動ロードはどちらの順序でも問題なく動作します。
dmesgに以下のような警告がでることがありますが、動作には影響しないのでそこまで気にしなくていいです。
※QATドライバは初期化時に内部タイマーを使ってシステムクロックの周波数を自己計測しています。その計測処理が想定より時間がかかったときにこのメッセージが出るみたいです。
qat0: Excessive clock measure delayまとめ
qatを有効化する方法について紹介しました。このバグについては、FreeBSDのコミッターによって根本原因がすでに特定されており、VFSの初期化前にファームウェアのパス探索が走ることが問題だと判明しています。2025年6月時点でパッチ作業に着手するとコメントがありましたが、2026年3月現在もBugzilla上でクローズされた記録がないため、正式な修正が15.0-RELEASEには間に合わなかった可能性があります。
なお、2025年6月のコミットでc3xxxのPCIeレジスタ番号が変更され別のパニックが発生するリグレッションも報告されましたが、こちらは15.0-RELEASEで修正済みと思われます(kldloadが正常動作していれば問題ありません)。
今どきのドライバは依存関係を自動解決してくれるものが多いので、「ファームウェアを先に書く」という手動の順序管理が必要なのは組み込み・産業用機器っぽい雰囲気がありますね。マザーボード自体が産業用設計なので、そういう意味では機器の性格と合っているかなあと思ったりしています。
おわり
参考URL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283285
https://www.mail-archive.com/[email protected]/msg40837.html