11.8. カーネル
IBM Power Systems のセキュアブートは移行をサポートしていません
現在、IBM Power Systems では、物理ボリューム (PV) の移行が成功した後、論理パーティション (LPAR) が起動しません。その結果、パーティションでセキュアブートが有効になっているタイプの自動移行は失敗します。
(BZ#2126777)
page_poison=1 を使用すると、カーネルクラッシュが発生する可能性がある
EFI 実装に問題のあるファームウェアでカーネルパラメーターとして page_poison=1 を使用すると、オペレーティングシステムが原因でカーネルがクラッシュする可能性があります。デフォルトでは、このオプションは無効になっており、特に実稼働システムでは有効にすることは推奨しません。
(BZ#2050411)
kmod の weak-modules がモジュールの相互依存関係で機能しない
kmod パッケージによって提供される weak-modules スクリプトは、どのモジュールがインストールされたカーネルと kABI 互換であるかを判別します。ただし、モジュールのカーネル互換性をチェックしている間、weak-modules は モジュールシンボルの依存関係を、それらがビルドされたカーネルの上位リリースから下位リリースへと処理します。結果として、異なるカーネルリリースに対して構築された相互依存関係を持つモジュールは互換性がないと解釈される可能性があるため、weak-modules はこのシナリオでは機能しません。
この問題を回避するには、新しいカーネルをインストールする前に、最新のストックカーネルに対して追加のモジュールをビルドまたは配置します。
(BZ#2103605)
同一の crash 拡張機能を再読み込みすると、セグメンテーションフォルトが発生する場合がある
読み込み済みのクラッシュ拡張ファイルのコピーを読み込むと、セグメンテーションフォルトが発生する場合があります。現在、crash ユーティリティーは、元のファイルが読み込まれているかどうかを検出します。その結果、crash ユーティリティーに同一のファイルが 2 つ共存するため、名前空間コリジョンが発生し、クラッシュユーティリティーが起動してセグメンテーションフォルトが発生します。
この問題を回避するには、クラッシュ拡張ファイルを一度だけ読み込みます。その結果、セグメンテーションフォルトは上記のシナリオでは発生しなくなりました。
vmcore キャプチャーが、メモリーのホットプラグまたはアンプラグの操作を実行した後に失敗する
メモリーのホットプラグまたはホットアンプラグ操作の実行後に、メモリーのレイアウト情報を含むデバイスツリーを更新するとイベントが発生します。これにより、makedumpfile ユーティリティーは存在しない物理アドレスにアクセスしようとします。以下の条件を満たすと問題が発生します。
- IBM Power System (little endian) で RHEL 8 を実行する。
-
システムで
kdumpサービスまたはfadumpサービスが有効になっている。
このような場合に、メモリーホットプラグまたはホットアンプラグの操作後にカーネルクラッシュが発生すると、カーネルのキャプチャーで vmcore の保存に失敗します。
この問題を回避するには、ホットプラグまたはホットアンプラグ後に kdump サービスを再起動します。
# systemctl restart kdump.service
これにより、上記のシナリオで vmcore が正常に保存されます。
(BZ#1793389)
RHEL 8 で、デバッグカーネルがクラッシュキャプチャー環境で起動に失敗する
デバッグカーネルはメモリーを大量に消費するので、デバッグカーネルが使用中で、カーネルパニックが発生すると、問題が発生します。その結果、デバッグカーネルはキャプチャーカーネルとして起動できず、代わりにスタックトレースが生成されます。この問題を回避するには、必要に応じてクラッシュカーネルメモリーを増やします。これにより、デバッグカーネルが、クラッシュキャプチャー環境で正常に起動します。
(BZ#1659609)
起動時にクラッシュカーネルメモリーの割り当てに失敗する
一部の Ampere Altra システムでは、BIOS 設定で 32 ビットリージョンが無効になっていると、起動時にクラッシュカーネルメモリーを割り当てることに失敗します。したがって、kdump サービスが起動できません。これは、クラッシュカーネルメモリーを含むのに十分な大きさのフラグメントがない場合に、4 GB 未満のリージョンのメモリーの断片化によって生じます。
この問題を回避するには、以下のように BIOS で 32 ビットのメモリーリージョンを有効にします。
- システムで BIOS 設定を開きます。
- Chipset メニューを開きます。
-
Memory Configuration で、
Slave 32-bitオプションを有効にします。
これにより、32 ビットリージョン内のクラッシュカーネルメモリー割り当てに成功し、kdump サービスが期待どおりに機能します。
(BZ#1940674)
QAT マネージャーが LKCF のスペアデバイスを残さない
Intel® QuickAssist Technology(QAT) マネージャー (qatmgr) はユーザー空間プロセスであり、デフォルトではシステム内のすべての QAT デバイスを使用します。これにより、Linux Kernel Cryptographic Framework(LKCF) には QAT デバイスが残っていません。この動作は予想され、大多数のユーザーはユーザースペースからのアクセラレーションを使用するため、この状況を回避する必要はありません。
(BZ#1920086)
カーネル ACPI ドライバーは、PCIe ECAM メモリーリージョンにアクセスできないことを報告します。
ファームウェアが提供する Advanced Configuration and Power Interface (ACPI) テーブルは、PCI バスデバイスの現在のリソース設定 (_CRS) メソッドにおいて PCI バス上のメモリーリージョンを定義しません。したがって、システムの起動時に以下の警告メッセージが表示されます。
[ 2.817152] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x30000000-0x31ffffff] not reserved in ACPI namespace [ 2.827911] acpi PNP0A08:00: ECAM at [mem 0x30000000-0x31ffffff] for [bus 00-1f]
ただし、カーネルは依然として 0x30000000-0x31ffffff メモリーリージョンにアクセスできます。また、そのメモリーリージョンを PCI Enhanced Configuration Access Mechanism (ECAM) に適切に割り当てることができます。以下の出力で 256 バイトオフセットで PCIe 設定領域にアクセスして、PCI ECAM が正常に機能することを確認できます。
03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD (prog-if 02 [NVM Express])
...
Capabilities: [900 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=0ns
L1SubCtl2: T_PwrOn=10usこれにより、警告メッセージを無視します。
問題の詳細は、Firmware Bug: ECAM area mem 0x30000000-0x31ffffff not reserved in ACPI namespace" appears during system boot を参照してください。
(BZ#1868526)
tuned-adm profile powersave コマンドを使用すると、システムが応答しなくなる
tuned-adm profile powersave コマンドを実行すると、古い Thunderx (CN88xx) プロセッサーを持つ Penguin Valkyrie 2000 2 ソケットシステムが応答しなくなります。これにより、作業を再開するためシステムを再起動することになります。この問題を回避するには、システムが上記の仕様と一致する場合には powersave プロファイルの使用を避けてください。
(BZ#1609288)
HP NMI ウォッチドッグが常にクラッシュダンプを生成しない
特定に場合において、HP NMI ウォッチドッグの hpwdt ドライバーは、マスク不可割り込み (NMI) が perfmon ドライバーにより使用されたため、HPE ウォッチドッグタイマーが生成した NMI を要求できません。
欠落している NMI は、以下の 2 つの条件のいずれかによって開始されます。
- Integrated Lights-Out (iLO) サーバー管理ソフトウェアの NMI 生成 ボタン。このボタンはユーザーがトリガーします。
-
hpwdtウォッチドッグ。デフォルトでは、有効期限により NMI がサーバーに送信されます。
通常、両方のシーケンスは、システムが応答しない場合に発生します。通常、これらの状況の NMI ハンドラーは kernel panic() 関数を呼び出します。また、設定されていれば、kdump サービスが vmcore ファイルを生成します。
ただし、NMI が見つからないため、kernel panic() は呼び出されず、vmcore が収集されません。
最初のケース (1.) でシステムが応答しない場合は、その状態のままになります。このシナリオを回避するには、仮想 電源 ボタンを使用してサーバーをリセットするか、電源を切って入れ直します。
2 つ目のケース (2.) では、欠落している NMI が Automated System Recovery (ASR) からのリセットの後 9 秒後に続きます。
HPE Gen9 Server ラインでは、1 桁台の割合でこの問題が発生します。Gen10 の周波数がさらに小さくなる。
(BZ#1602962)
irqpoll を使用すると vmcore の生成に失敗します。
アマゾンウェブサービス Graviton 1 プロセッサー上で実行される 64 ビット ARM アーキテクチャー上の nvme ドライバーの既存の問題により、最初のカーネルに irqpoll カーネルコマンドラインパラメーターを指定すると、vmcore の生成が失敗します。したがって、カーネルクラッシュ時に vmcore が /var/crash/ ディレクトリーにダンプされません。この問題を回避するには、以下を実行します。
/etc/sysconfig/kdumpファイルのKDUMP_COMMANDLINE_REMOVE変数にirqpollを追加します。# KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
/etc/sysconfig/kdumpファイルのKDUMP_COMMANDLINE_APPEND変数からirqpollを削除します。# KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory udev.children-max=2 panic=10 swiotlb=noforce novmcoredd"
kdumpサービスを再起動します。# systemctl restart kdump
その結果、最初のカーネルが正常に起動し、カーネルクラッシュ時に vmcore がキャプチャーされることが予想されます。
Amazon Web Services Graviton 2 および Amazon Web Services Graviton 3 プロセッサーでは、/etc/sysconfig/kdump ファイルの irqpoll パラメーターを手動で削除する必要がないことに注意してください。
kdump サービスは、大量のクラッシュカーネルメモリーを使用して vmcore ファイルをダンプする可能性があります。キャプチャーカーネルには、kdump サービス用のメモリーが十分あることを確認します。
この既知の問題の関連情報は、irqpoll カーネルコマンドラインパラメーターにより、vmcore 生成エラーが発生する場合がある を参照してください。
(BZ#1654962)
仮想マシンへの仮想機能の割り当て時に接続に失敗する
ionic デバイスドライバーを使用する Pensando ネットワークカードは、VLAN タグ設定要求を許可し、ネットワーク仮想機能 (VF) を VM に割り当てる間にネットワーク接続の設定を試行します。この機能はカードのファームウェアではサポートされていないため、このようなネットワーク接続は失敗します。
(BZ#1930576)
OPEN MPI ライブラリーは、デフォルトの PML でランタイムが失敗する可能性があります。
OPEN Message Passing Interface (OPEN MPI) 実装 4.0.x シリーズでは、UCX (Unified Communication X) がデフォルトの PPL (ポイントツーポイント) です。OPEN MPI 4.0.x シリーズの新しいバージョンでは、openib Byte Transfer Layer (BTL) が非推奨になりました。
ただし、OPEN MPI は 同種 クラスター (同じハードウェアおよびソフトウェア設定) で実行される場合も、UCX は MPI openlib の一方向操作に BTL を使用します。これにより、実行エラーが発生する可能性があります。この問題を回避するには、以下を実行します。
-
以下のパラメーターを使用して
mpirunコマンドを実行します。
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0
詳細は以下のようになります。
-
-mca btl openibパラメーターはopenibBTL を無効にします。 -
-mca pml ucxパラメーターは、ucxPML を使用するように OPEN MPI を設定します。 -
x UCX_NET_DEVICES=パラメーターは、指定したデバイスを使用するように UCX を制限します。
OPEN MPI は、異種 クラスター (ハードウェアおよびソフトウェア設定に異なる) を実行する場合は、デフォルトの PML として UCX を使用します。これにより、OPEN MPI ジョブが不安定なパフォーマンス、応答しない動作で実行されたり、またはクラッシュによる不具合とともに実行される可能性があります。この問題を回避するには、UCX の優先度を以下のように設定します。
-
以下のパラメーターを使用して
mpirunコマンドを実行します。
-mca pml_ucx_priority 5
これにより、OPEN MPI ライブラリーは、UCX を介して利用可能な別のトランスポート層を選択することができます。
(BZ#1866402)
Solarflare が、最大数の VF(Virtual Function) の作成に失敗する
Solarflare NIC は、リソースが十分にないため、最大数の VF の作成に失敗します。PCIe デバイスが作成できる VF の最大数は、/sys/bus/pci/devices/PCI_ID/sriov_totalvfs ファイルで確認できます。この問題を回避するには、起動時に Solarflare Boot Manager から、または Solarflare sfboot ユーティリティーの使用により、VF の数または VF MSI 割り込みの値を低い値に調整できます。デフォルトの VF MSI 割り込みの値は 8 です。
-
sfbootを使用して VF MSI 割り込み値を調整するには、以下を実行します。
# sfboot vf-msix-limit=2
VF MSI 割り込みの値を調整すると、VF のパフォーマンスに影響します。
調整されるパラメーターの詳細は、Solarflare Server Adapter user guide を参照してください。
(BZ#1971506)
iwl7260-firmware により、Intel Wi-Fi 6 AX200、AX210、および Lenovo ThinkPad P1 Gen 4 で Wi-Fi が切断される
iwl7260-firmware または iwl7260-wifi ドライバーを RHEL 8.7 および/または RHEL 9.1 (およびそれ以降) によって提供されるバージョンに更新した後、ハードウェアが正しくない内部状態になります。状態を誤って報告します。その結果、Intel Wifi 6 カードが機能せず、次のエラーメッセージが表示される場合があります。
kernel: iwlwifi 0000:09:00.0: Failed to start RT ucode: -110 kernel: iwlwifi 0000:09:00.0: WRT: Collecting data: ini trigger 13 fired (delay=0ms) kernel: iwlwifi 0000:09:00.0: Failed to run INIT ucode: -110
未確認の回避策は、システムの電源をオフにしてから再度オンにすることです。再起動しないでください。
(BZ#2106341)
64 ビット ARM アーキテクチャーで kdump のメモリー割り当てが失敗する
特定の 64 ビット ARM ベースのシステムでは、ファームウェアは、分散したさまざまな場所にメモリーをランダムに予約する不連続メモリー割り当て方法を使用します。その結果、連続したメモリーブロックが利用できないため、クラッシュカーネルは kdump メカニズム用のメモリー領域を予約できません。
この問題を回避するには、RHEL 8.8 以降で提供されるカーネルバージョンをインストールしてください。RHEL の最新バージョンは、説明されているシナリオで適切なメモリー領域を見つけるのに役立つ fallback ダンプキャプチャーメカニズムをサポートしています。
コア数が大きいシステムのリアルタイムカーネルのハードウェア認定では、ロックの競合を回避するために skew-tick=1 ブートパラメーターを渡す必要がある場合があります。
多数のソケットとコアカウントが大きい大規模なシステムまたは中規模のシステムでは、タイムキーピングシステムで使用される xtime_lock のロック競合により、レイテンシーの急増が発生する可能性があります。その結果、レイテンシーの急増およびハードウェア認証のレイテンシーは、マルチプロセッシングシステムで発生する可能性があります。回避策として、skew_tick=1 ブートパラメーターを追加することで、CPU ごとにタイマーティックをオフセットし、別のタイミングで開始できます。
ロックの競合を回避するには、skew_tick=1 を有効にします。
grubbyでskew_tick=1パラメーターを有効にします。# grubby --update-kernel=ALL --args="skew_tick=1"
- 変更を有効にするために再起動します。
-
cat /proc/cmdlineコマンドを実行して、新しい設定を確認します。
skew_tick=1 を有効にすると、消費電力が大幅に増加するため、レイテンシーの影響を受けるリアルタイムワークロードを実行している場合にのみ有効にする必要があります。
(BZ#2214508)
