最近、Linuxディストリビューションでまったく新しいハードウェア関連の問題が発生しました。 Linux Mint 20.2では、バッテリー電源で起動している間、つまり壁のコンセントジュースがない場合、起動プロセスはある時点で停止し、応答しない黒い画面が表示されます。唯一の解決策は、再起動するか、充電器を接続した状態でホストの電源を入れることです。
興味深いのは、これがAMDVega8グラフィックスを搭載した比較的新しいIdeaPad3ラップトップで発生したことです。そして、ハードウェアには常に問題があるように思われるので、それは私を非常に苛立たせました。このマシンのワイヤレス、このマシンのグラフィックス、ここのI / O制御、そこのカメラなど。常に問題、常に言い訳。さて、ここで何ができるか、そしてこれを修正する方法を見てみましょう。
問題の詳細
LinuxMintで問題が発生しました。しかし、私はこの問題がはるかに広い基盤に影響を及ぼしているのではないかと思います。実際、「AMD boot black screen」を検索すると、Ubuntu、Mint、Arch、Manjaro、Gentooなどのフォーラムスレッドの結果が大量に表示されます。2019年にさかのぼり、多数の推奨事項があり、実際の解決策はほとんどありません。 。なんで？ドライバーの問題を修正するには専門知識が必要であり、カーネルやドライバーが適切な種類の機能を提供していない場合、できることはあまりありません。これはまた、オープンソースとクローズドソースのドライバーの問題に焦点を当てます。専門知識は専門知識であるため、そうではありません。
ミニラントはさておき、IdeaPad 3マシンには、MX-21KDEとWindowsを含むトリプルブート構成があります。これらの他の2つのシステムは問題なく動作するため、ハードウェアの問題を除外し、Mintの起動シーケンスで特に間違っている（そして異なる）ことに焦点を当てることができます。
そのために、MintとMX-21からdmesg、kern.log、X.org.log、およびシステムログファイルを取得し、それらを並べて比較し、実際の差分を作成しました。唯一の本当の違いはカーネルログにあり、Mintは起動を停止し、他のディストリビューションは陽気に続行します。エラーは次のようになります。
...
kernel：[] [drm：amdgpu_job_timedout [amdgpu]] *エラー*プロセス情報：プロセスXorg pid 790スレッドXorg：cs0 pid 824
kernel：[] amdgpu 0000：03：00.0： GPUリセットが始まります！
kernel：[] amdgpu 0000：03：00.0：GPUリセットが成功し、再開しようとしました
kernel：[] [drm]1024MのPCIEGARTが有効になっています（0x000000F400900000のテーブル）。
kernel：[][drm]PSPが再開しています...
kernel：[] [drm] PSPTMR用に0xf47f800000から0x400000を予約します
kernel：[][drm]pspコマンドが失敗しました応答ステータスは（0x7）
kernel：[] amdgpu 0000：03：00.0：ringgfxはハブ0でVMinveng0を使用します
...
最終的に、GPUリセットは成功しますが、役に立ちません。画面は黒のままです。それでは、問題を解決または回避する方法を紹介します。自由に使えるオプションがいくつかあります。
ソリューション
OK、これがあなたにできることです：
新しいカーネルをインストールします（利用可能な場合）
システムカーネルやファームウェアをアップグレードします。通常はカーネルを固定するLinuxMintでは、システムアップデートユーティリティを使用して新しいカーネルを手動でダウンロードできます。警告が表示されたら、目的のバージョンを選択して構成できます。 Mint 20.2 Umaの場合、カーネル5.4からカーネル5.13に上げることができます。
新しいカーネルをインストールして構成出力を確認すると、initramfsファイルの生成中に一連の警告メッセージも表示されました。
...
W：モジュールamdgpuのファームウェア/lib/firmware/amdgpu/vangogh_vcn.binが欠落している可能性があります
W：モジュールamdgpuのファームウェア/lib/firmware/amdgpu/navy_flounder_vcn.binが欠落している可能性があります
W：モジュールamdgpuのファームウェア/lib/firmware/amdgpu/navi12_vcn.binが欠落している可能性があります
W：モジュールamdgpuのファームウェア/lib/firmware/amdgpu/aldebaran_vcn.binが欠落している可能性があります
...
AMD GPUアーキテクチャがこのリストに表示されていない場合は、これらを無視できます。私の場合、Vega 8は正しくサポートされていました（つまり、このリストには含まれていません）。どうやって知るの？コマンドlspci-vを実行すると、さまざまなハードウェアコンポーネントがすべて一覧表示されます。使用中の適切なカーネルドライバ（この場合はamdpu）に一致するエントリが必要です。
03：00.0 VGA互換コントローラー：Advanced Micro Devices、Inc. [AMD / ATI] Picasso（rev c2）（prog-if 00 [VGAコントローラー]）
サブシステム：Lenovo Picasso
...
このようにして、私のVega8グラフィックが実際にはPicassoと呼ばれるアーキテクチャモデルに対応していることを発見しました。それが一般的に使われている名前を説明していると思います。この出力は、特定のGPUモデルをサポートしていない新しいカーネルについて通知する乱雑なノイズです。繰り返しになりますが、これはLinuxの下位互換性などのより広い問題を開きますが、ここではそれについては説明しません。再起動すると、うまくいけば、これでうまくいくはずです。
電源を接続した状態でホストを起動します
これは煩わしいことですが、システムの変更に慣れていない場合や、Linuxディストリビューションで問題が修正されるまで特別なことをしたくない場合の簡単な回避策です。ただし、この問題は、Mintのカーネルポリシーの1つの（小さな）欠点と、Linuxでのハードウェアサポートの一般的で幅広い現象を浮き彫りにします。なぜなら、ディストリビューションに利用可能な更新されたカーネルがない場合、多くのことを行うことができないからです。
この「トリック」が機能する理由は、（バッテリー電源ではなく）フルパワーのシステムが異なる電源プロファイルを使用するためです。本当に精通している場合は、BIOSの電力パフォーマンスオプションが利用可能な場合はそれを試してみるか、GPUの電力設定を微調整することができますが、これは一時的な一時的な対策としてのみ意図されています。
ブートパラメータを変更する
先ほど述べたことを続けると、AMD GPU（amdgpu）カーネルモジュールにさまざまなパラメーターを渡すことでシステムを起動できます。 modinfoコマンドを実行すると、モジュールがサポートするパラメーターとオプションの種類を確認できます。
modinfo amdgpu
ファイル名：/lib/modules/5.13.0-22-generic/kernel/drivers/gpu/drm/amd/amdgpu
/amdgpu.ko
ライセンス： GPLと追加の権限
説明：AMD GPU
作成者：AMDlinuxドライバーチーム
...
parm：audio：Audio enable（-1 =auto、0 =disable、1 =enable）（int）
parm：disp_priority：Display Priority（0 =auto、1 =normal、2 =high）（int）
parm：hw_i2c：hw i2c engine enable（0 =disable）（ int）
parm：pcie_gen2：PCIE Gen2モード（-1 =自動、0 =無効、1 =有効）（int）
parm：msi：MSIサポート（1 =有効、0 =無効、- 1 =自動）（int）
...
たとえば、試してみることができる利用可能なオプションのいくつかですが、何をしているのかを理解していない限り、試してはいけません！
amdgpu.noretry =0
amdgpu.dc =1
これらは、ブートメニューのカーネルブート行に追加する必要があります。 GRUB2ブートローダーを使用する最新のLinuxディストリビューションでは、コマンドのシーケンスは次のとおりです。
- テキストエディタでrootまたはsudoとして/etc/ default / grubを開きます（事前にバックアップを作成します）
- 1つ以上のamdgpuオプションをGRUB_CMDLINE_LINUX_DEFAULT行に追加します。
- ファイルを保存し、GRUB構成を次のように更新します：
sudo update-grub
または、上記のラッパースクリプトを使用しないシステムの場合：
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
システムを再起動して、問題が解決したかどうかを確認します。カーネルコマンドラインを調べることで、システムがどのように起動したかを確認できます。つまり、バッテリーで正常に起動する場合は、ハハ！
cat / proc / cmdline
さて、大きな問題は、どのamdgpuオプションを追加する必要があるかということです。
これに対する簡単な答えはありません、私は恐れています。ほとんどの場合、実際のカーネル/ファームウェアの修正を除いて、カーネルログに表示されるエラーメッセージに基づいて推測し、特定のオプションでうまくいくことを期待します。これは、エラーメッセージが一般的であることが多く、グラフィックスタックと特定のドライバに関する専門知識がなければ、少数のカーネルモジュールオプションで実際にエラーメッセージを特定できないためです。
これらの編集を行うと、追加の問題や複雑化につながる可能性があります。そのため、盲目的にそれらを適用したり、フォーラムから提案をコピーしたりしないでください。私のテストでは、実際に大きな違いをもたらすオプションはないことが示されています。上記の2つは参考用です。それでも、カーネルの更新が機能せず、バッテリー電源でラップトップを使用できる必要がある場合は、失うものは何もないと思います。実験して、何が得られるかを確認することをお勧めします。
結論
そこに行きます。うまくいけば、Linuxを実行しているAMD-graphicsラップトップが正しく動作し、バッテリー電源（またはその他のシナリオ）を使用しているときに起動時に黒い画面の問題が発生しなくなります。私のチュートリアルでは、カーネルのアップグレード、電力使用量の回避策、カーネルモジュールパラメータを使用したハッカリーの3つの主要なアプローチの概要を説明します。これらはリスクが高く、最良の結果が得られない可能性がありますが、ちょっと。
私はこの種の問題が好きではありません。彼らはいつもLinuxがいかに壊れやすいかを私に思い出させます。はい、それは大量のハードウェア上で実行され、それは称賛に値しますが、それは常に95％または91％であり、100％を完全に通過することはありません。そして、それは迷惑です。まあ、とにかく、それだけです。さて、次のタクシーのハードルに行きます。またね。