AArch64デスクトップ実験の終わり

この記事は、「AArch64システムをデスクトップとして使ってみよう」シリーズの第7弾です： AArch64デスクトップ：1日目 AArch64デスクトップ：2日目 AArch64デスクトップ：最終日 Armデスクトップ：2025年の試み、パート1 Armデスクトップ：エミュレーション Armデスクトップ：非常に多くのコア、十分な速度ではない AArch64デスクトップ実験の終わり 約11ヶ月間AArch64デスクトップを使用した後、この実験を終了することを決定しました。 使用したハードウェア 約1年前、私はAmpere Altraシステムを購入しました。いくつかのハードウェアを移動させ、いくつかの追加注文を行った後、最終的なセットアップは以下のようになりました。 CPU Ampere Altra Q80-30プロセッサ（80コア、3.0GHz） RAM 128 GB (8x 16GB HMA82GR7CJR8N-XN) GPU AMD Radeon RX6700XT NVME Lexar LM970 2TB ADATA SX8200 Pro 1TB マザーボード ASRock Rack ALTRAD8UD-1L2T PSU MSI MPG A850G (850W) ケース Endorfy 700 Air USB3 no-name USB 3.2/10Gbpsコントローラ (PCIe x4) 公平を期すために言っておくと、これはサーバーマザーボードであり、デスクトップ用ではありません。また、Altraシステムはデスクトップとして意図されていませんでした（一部の企業がそう売っていましたが）。当然ながら、テスト/承認済みデバイスのリスト（TLAファン向けのQVL）は非常に短く、Ampere Altraシステムの場合、AMD Radeon GPUカードは含まれていません。それらを動作させることは可能ですが、多くの場合、追加の労力が必要です。追加のUSB 3.2コントローラにより、マザーボード単体でサポートされるよりも多くのUSBデバイスを使用でき、外部NVMeドライブを接続するための10Gbpsポートも得られました。システム全体はFedora 42〜44で問題なく動作していました*。 最初の問題 前の段落の最後に小さな「*」があることにお気づきでしょうか？私が使用していたシステムは、完全にFedoraではありませんでした。私自身の、自分で構築したカーネルを使用する必要がありました。ご存知の通り、Ampere AltraのPCI Expressコントローラにはいくつかの問題があります。Ampere Altraのerratum 82288パッチの説明を引用しましょう。 Altraファミリーのerratumにより、PCIE_65はPCIe mmio書き込みで無効なアドレスを生成する可能性があり、特定のデバイスタイプ、特にAMD GPUに影響を与えるため、Altraファミリーは一般的にこれらのデバイスタイプと互換性がありません。 そして、パッチ自体のより長い説明です。 PCIeデバイスドライバは、MMIO空間をNormal, non-cacheable memory属性としてマップする場合があります（例：Linuxカーネルドライバがioremap_wcを使用してMMIOをマップする場合）。これは、ライトコンバイニングや非アラインアクセスを可能にすることを目的とする場合があります。これにより、ライトコンバイニング操作の問題により、PCIeインターフェースのアウトバウンドMMIO書き込みでデータ破損が発生する可能性があります。この回避策は、PCIe MMIO空間をNormal, non-cacheable memoryとしてマップするソフトウェア（例：ioremap_wc）を、代わりにDevice, non-gathering memory（例：ioremap）に変更します。そして、PCIe MMIO空間上のすべてのメモリ操作は厳密にアラインされている必要があります。 したがって、動作するLinuxシステムを持つためには、パッケージの更新ごとにカーネルを再構築する必要がありました。これは通常、「毎週」を意味しました。毎週月曜日か火曜日に、私はFedoraカーネルパッケージリポジトリのローカルコピーを更新し、私自身のバージョン管理スキーム（例：「7.0.2-200.fc44.pcie65.6」）を使用してビルドしました。「pcie65」の部分は適用したパッチを思い出させ、「6」はパッチのリベースのカウンタでした。GitHubからリポジトリをクローンし、その後パッチをリベースし、必要に応じて適応させました。副作用として、私は公式のFedoraリリースよりも新しいカーネルを頻繁に使用していました。Fedoraカーネルパッケージリポジトリには、間もなくプッシュされるバージョンが存在する「安定化」ブランチがあります。そのため、Fedoraが6.19.yカーネルを使用している間、私は7.0.zカーネルを使用していました。 非常に多くのコア、十分な速度ではない 以前の投稿で書いたように、80個のCPUコアがあるからといって、システムが優れた高速なデスクトップマシンであるとは限りません。 AMD GPUが故障し始めた 上記で述べたように、AMD Radeon RX6700XTを適切に動作させるためには、カーネルをアウトオブツリーパッチで変更する必要がありました。それは動作し、いくつかのゲームをプレイしたり、ハードウェア支援ビデオデコードアクセラレーションでビデオを視聴したりできました。しかし、ある日、Linux 7.0リリース頃から、それが故障し始めました。ゲームを実行すると、以下のようなエラーが発生しました。 kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 何度も何度も繰り返されました。YouTube動画の視聴は、750フレーム中720フレームがドロップされるため、不可能になりました。通常であれば、カーネルをバイセクトして問題の原因を特定するでしょう。しかし、PCIE65パッチのために汚染されたカーネルを実行していたため、実際の問題がどこにあるのか誰にもわかりませんでした… Nvidiaを導入する Nvidia RTX 2060グラフィックカードを購入し、AMD Radeonの代わりに装着しました。nouveauカーネルドライバーで使用したい場合でも、PCIE65パッチを適用する必要があることが判明しました…そこで、デフォルトのFedoraカーネルとNvidiaバイナリドライバーを試しました。そして、それは問題なく動作しました。ビデオデコードは高速化され、Wine下の一部のゲームも動作しました。しかし、FreeCADを起動し、OrcaSlicerを起動すると、どちらの場合もクラッシュして終了しました…AArch64用のorg.freedesktop.Platform.GL.nvidiaがFlatpakリポジトリにないことが判明しました。そして、私はこれらのツールを両方とも頻繁に使用していました。 古いx86-64を起動する… その時点で、私は諦めました。そして、ずっと電源がオフになっていたx86-64システムを起動しました。多くのケーブルを移動し、いくつかの新しいケーブルを整理し、今では「wooster」（Ampere Altra）と「puchatek」（Ryzen 5 3600）の両方のシステムが私の机の下で動作しています。80コアから6コア（12スレッド）に移行するのは奇妙な経験でした。はるかに少ない数ですが、物事はうまく機能します。すべてのスレッドをロードしても音楽は再生され続けます。Steamライブラリのすべてのゲームはプレイ可能です。動作するFreeCADにより、自宅プロジェクトのケース設計を完了でき、OrcaSlicerから直接プロトタイプを3Dプリントできます。「wooster」システムは電源が入ったままで、RISC-Vパッケージのビルドを処理しています。シングルスレッドでは弱いかもしれませんが、マルチコア負荷に関しては高速です。 結論 Ampere Altraについては、この実験を繰り返すつもりはありません。別のAArch64デスクトップの試みには、全く新しいハードウェアプラットフォームが必要になるでしょう。そして、Nvidia DGX Sparkシステムを購入するために2万PLN以上を費やす予定はありません。 aarch64 computers desktop fedora コメント？ コメントしたい場合は、Mastodonの私の投稿にアクセスしてください。 関連投稿 Armデスクトップ：非常に多くのコア、十分な速度ではない Armデスクトップ：エミュレーション Armデスクトップ：2025年の試み、パート1 HoneyComb AArch64デスクトップハードウェアを手に入れた？ Armデスクトップ：非常に多くのコア、十分な速度ではない »