10.8. カーネル

同一の crash 拡張機能を再読み込みすると、セグメンテーションフォルトが発生する場合がある

読み込み済みのクラッシュ拡張ファイルのコピーを読み込むと、セグメンテーションフォルトが発生する場合があります。現在、crash ユーティリティーは、元のファイルが読み込まれているかどうかを検出します。その結果、crash ユーティリティーに同一のファイルが 2 つ共存するため、名前空間コリジョンが発生し、クラッシュユーティリティーが起動してセグメンテーションフォルトが発生します。

この問題を回避するには、クラッシュ拡張ファイルを一度だけ読み込みます。その結果、セグメンテーションフォルトは上記のシナリオでは発生しなくなりました。

(BZ#1906482)

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 ビットのメモリーリージョンを有効にします。

  1. システムで BIOS 設定を開きます。
  2. Chipset メニューを開きます。
  3. Memory Configuration で、Slave 32-bit オプションを有効にします。

これにより、32 ビットリージョン内のクラッシュカーネルメモリー割り当てに成功し、kdump サービスが期待どおりに機能します。

(BZ#1940674)

デフォルトのクラッシュカーネルメモリーを使用する KVM 仮想マシンで kdump が失敗する

一部の KVM 仮想マシンでは、kdump にデフォルトメモリー量を使用してカーネルクラッシュダンプをキャプチャーすると kdump に失敗します。その結果、クラッシュカーネルにより、以下のエラーが表示されます。

/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory

この問題を回避するには、kdump のサイズ要件に合うように、crashkernel= オプションを 32M 以上増やします。たとえば、final の値は、現在の値と 32M の合計になります。

crashkernel=auto パラメーターの場合、以下のようになります。

  1. 現在のメモリーサイズを確認し、次のようにして 32M 増加します。

    echo $(($(cat /sys/kernel/kexec_crash_size)/1048576+32))M
  2. kernel crashkernel パラメーターを crashkernel=x に設定します。x は増加したサイズになります。

(BZ#2004000)

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)

irqpoll を使用すると vmcore の生成に失敗します。

Amazon Web Services (AWS) クラウドプラットフォームで実行している 64 ビット ARM アーキテクチャー上には nvme ドライバーの既存の問題があります。この問題により、最初のカーネルに irqpoll カーネルコマンドラインパラメーターを指定すると vmcore の生成に失敗します。したがって、カーネルクラッシュ時に vmcore/var/crash/ ディレクトリーにダンプされません。この問題を回避するには、以下を実行します。

  1. /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_REMOVEirqpoll を追加します。

    KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
  2. /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"
  3. kdump サービスを再起動します。

    systemctl restart kdump

その結果、最初のカーネルが正常に起動し、カーネルクラッシュ時に vmcore がキャプチャーされることが予想されます。

kdump サービスは、大量のクラッシュカーネルメモリーを使用して vmcore ファイルをダンプできることに注意してください。キャプチャーカーネルには、kdump サービス用のメモリーが十分あることを確認します。

この既知の問題の関連情報は、irqpoll カーネルコマンドラインパラメーターにより、vmcore 生成エラーが発生する場合がある を参照してください。

(BZ#1654962)

HP NMI ウォッチドッグが常にクラッシュダンプを生成しない

特定に場合において、HP NMI ウォッチドッグの hpwdt ドライバーは、マスク不可割り込み (NMI) が perfmon ドライバーにより使用されたため、HPE ウォッチドッグタイマーが生成した NMI を要求できません。

欠落している NMI は、以下の 2 つの条件のいずれかによって開始されます。

  1. Integrated Lights-Out (iLO) サーバー管理ソフトウェアの NMI 生成 ボタン。このボタンはユーザーがトリガーします。
  2. 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)

仮想マシンへの仮想機能の割り当て時に接続に失敗する

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 パラメーターは openib BTL を無効にします。
  • -mca pml ucx パラメーターは、ucx PML を使用するように 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)