11.6. カーネル

誤ってパッチが削除されると、huge_page_setup_helper.py でエラーが表示されます。

huge_page_setup_helper.py スクリプトを更新するパッチが誤って削除されました。これにより、huge_page_setup_helper.py の実行後に、以下のエラーメッセージが表示されます。 

SyntaxError: Missing parentheses in call to 'print'

この問題を回避するには、RHEL 8.1 から huge_page_setup_helper.py スクリプトをコピーし、これを /usr/bin/ ディレクトリーにインストールします。

  1. RHEL-8.1.0 のインストールメディアまたは Red Hat カスタマーポータル から、libhugetlbfs-utils-2.21-3.el8.x86_64.rpm パッケージをダウンロードします。

  2. rpm2cpio コマンドを実行します。 

    # rpm2cpio libhugetlbfs-utils-2.21-3.el8.x86_64.rpm | cpio -D / -iduv '*/huge_page_setup_helper.py'

    このコマンドは、RHEL 8.1 RPM から huge_page_setup_helper.py スクリプトを展開して、 /usr/bin/ ディレクトリーに保存します。

これにより、huge_page_setup_helper.py スクリプトが正しく動作するようになります。

(BZ#1823398)

永続メモリーのサイズが大きくなると、システムの起動プロセス時に遅延が発生します。

メモリーの初期化がシリアル化されるため、永続メモリーのサイズが大きいシステムは起動に時間がかかります。したがって、/etc/fstab ファイルに永続メモリーのファイルシステムがあると、デバイスが利用できるようになるまで待つ際に、システムがタイムアウトする場合があります。この問題を回避するには、/etc/systemd/system.conf ファイルの DefaultTimeoutStartSec オプションを十分に大きな値に設定します。

(BZ#1666538)

KSM が、NUMA メモリーポリシーを無視することがあります。

merge_across_nodes=1 パラメーターで、カーネル共有メモリー (KSM) 機能を有効にすると、KSM は、mbind() 関数が設定したメモリーポリシーを無視し、一部のメモリーから、ポリシーに一致しない NUMA (Non-Uniform Memory Access) ノードにページをマージできない場合があります。

この問題を回避するには、KSM を無効にするか、QEMU で NUMA メモリーバインディングを使用する場合は merge_across_nodes パラメーターを 0 に設定します。これにより、KVM 仮想マシンに設定した NUMA メモリーポリシーが期待どおりに機能します。

(BZ#1153521)

RHEL 8 で、デバッグカーネルがクラッシュキャプチャー環境で起動に失敗します。

デバッグカーネルのメモリー要求の性質により、デバッグカーネルが使用中で、カーネルパニックが発生すると、問題が発生します。その結果、デバッグカーネルはキャプチャーカーネルとして起動できず、代わりにスタックトレースが生成されます。この問題を回避するには、クラッシュカーネルメモリーを適宜増やします。これにより、デバッグカーネルが、クラッシュキャプチャー環境で正常に起動します。

(BZ#1659609)

zlib は、一部の圧縮機能で vmcore キャプチャーの速度を低下させる可能性があります。

kdump 設定ファイルはデフォルトで、lzo 圧縮形式 (makedumpfile -l) を使用します。zlib 圧縮形式 (makedumpfile -c) を使用して設定ファイルを変更すると、vmcore のキャプチャープロセスの速度を低下させる代わりに、圧縮の因子が改善される可能性が高くなっています。これにより、lzoと比較して、kdump が zlibで vmcore をキャプチャーするのに最大 4 倍の時間がかかります。

このように、Red Hat は、速度が主要な要因である場合に、デフォルトの lzo を使用することを推奨します。ただし、ターゲットマシンで利用可能な領域が少ない場合は、zlib の方が適しています。

(BZ#1790635)

vmcore キャプチャーはメモリーのホットプラグまたはアンプラグの操作を実行した後に失敗します。

メモリーのホットプラグまたはホットアンプラグ操作の実行後に、メモリーのレイアウト情報を含むデバイスツリーを更新するとイベントが発生します。これにより、makedumpfile ユーティリティーは存在しない物理アドレスにアクセスしようとします。以下の条件を満たすと問題が発生します。

  • IBM Power System (little endian) で RHEL 8 を実行する。
  • システムで kdump サービスまたは fadump サービスが有効になっている。

このような場合に、メモリーホットプラグまたはホットアンプラグの操作後にカーネルクラッシュが発生すると、カーネルのキャプチャーで vmcore の保存に失敗します。

この問題を回避するには、ホットプラグまたはホットアンプラグ後に kdump サービスを再起動します。 

# systemctl restart kdump.service

これにより、上記のシナリオで vmcore が正常に保存されます。

(BZ#1793389)

fadump ダンピングメカニズムが、ネットワークインターフェースの名前を kdump-<interface-name> に変更します。

ファームウェア支援ダンプ (fadump) を使用して vmcore を取得し、SSH または NFS プロトコルを使用してこれをリモートマシンに保存すると、ネットワークインターフェースの名前が kdump-<interface-name> に変更されます。名前変更は、<interface-name> が、*eth# や net# などのように一般的な場合に起こります。この問題は、初期 RAM ディスク (initrd) の vmcore 取得スクリプトが、ネットワークインターフェース名に接頭辞 kdump- を追加して、永続的な名前付けを保護するために発生します。同じ initrd が通常の起動にも使用されるため、実稼働環境のカーネルのインターフェース名も変更されます。

(BZ#1745507)

fadump が有効な場合、システムが起動時に緊急モードに切り替わります。

fadump (kdump) または dracut squash モジュールが initramfs スキームで有効化されると、システムが緊急モードに切り替わります。これは、systemd マネージャーがマウント情報の取得とマウントする LV パーティションの設定に失敗するためです。この問題を回避するには、以下のカーネルコマンドラインパラメーター rd.lvm.lv=<vg>/<LV> を追加し、失敗した LV パーティションを適切に検出してマウントします。これにより、上述のシナリオでシステムが正常に起動するようになります。

(BZ#1750278)

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

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

  1. / /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_REMOVE キーに irqpoll を追加します。
  2. systemctl restart kdump コマンドを実行して、kdump サービスを再起動します。

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

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

(BZ#1654962)

ダンプターゲットとして vPMEM メモリーを使用すると、カーネルクラッシュキャプチャープロセスが遅延します。

仮想永続メモリー (vPEM) 名前空間を kdump または fadump ターゲットとして使用する場合には、 papr_scm モジュールは強制的に、vPMEM がサポートするメモリーのマッピングを解除して再マッピングし、メモリーをリニアマップに再追加します。したがって、この動作により、ハイパーバイザーコール (HCall) が POWER Hypervisor にトリガーされ、カーネルブートのキャプチャーにかかる合計時間が大幅に長くなります。そのため、kdump または fadump のダンプターゲットとして vPMEM 名前空間を使用しないことが推奨されます。

vPMEM を使用する場合に、この問題を回避するには、以下のコマンドを実行します。

  1. /etc/dracut.conf.d/99-pmem-workaround.conf ファイルを作成し、以下を追加します。 

    add_drivers+="nd_pmem nd_btt libnvdimm papr_scm"

  2. 初期 RAM ディスク (initrd) のファイルシステムを再構築します。 

    # touch /etc/kdump.conf
# systemctl restart kdump.service

(BZ#1792125)

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)

tuned-adm profile powersave コマンドを使用すると、システムが応答しなくなります。

tuned-adm profile powersave コマンドを実行すると、古い Thunderx (CN88xx) プロセッサーを持つ Penguin Valkyrie 2000 2 ソケットシステムが応答しなくなります。これにより、作業を再開するためシステムを再起動することになります。この問題を回避するには、システムが上記の仕様と一致する場合には powersave プロファイルの使用を避けてください。

(BZ#1609288)

cxgb4 ドライバーにより kdump カーネルでクラッシュします。

vmcore ファイルに情報を保存しようとすると、kdump カーネルがクラッシュします。そのため、cxgb4 ドライバーにより、kdump カーネルが、後で分析するためにコアを保存できなくなります。この問題を回避するには、kdump カーネルコマンドラインに novmcoredd パラメーターを追加して、コアファイルを保存できるようにします。

(BZ#1708456)

ICE ドライバー NIC ポートをモード 5 (balance-tlb) ボンディングマスターインターフェースに追加しようとすると失敗する場合があります。

ICE ドライバー NIC ポートをモード 5 (balance-tlb) ボンディングマスターインターフェースに追加しようとすると、Master 'bond0', Slave 'ens1f0': Error: Enslave failed のエラーで失敗する可能性があります。そのため、NIC ポートをボンディングマスターインターフェースに NICE ポートを追加するときに断続的に問題が発生します。この問題を回避するには、インターフェースの追加をもう一度試してください。

(BZ#1791664)

type='hostdev' の仮想マシンへの Virtual Function のアタッチに失敗する場合があります。

Assignment with <interface type='hostdev'> メソッドに従って、.XML ファイルを使用して仮想マシンに Virtual Function (VF) をアタッチすると、失敗する場合があります。Assignment with <interface type='hostdev'> メソッドを使用すると、仮想マシンに渡す VF NIC に仮想マシンをアタッチできなくなります。この問題を回避するには、Assignment with <hostdev> メソッドを使用する、.XML ファイルで、仮想マシンに VF をアタッチしてください。こうすることで、virsh attach-device コマンドがエラーなしで成功します。Assignment with <hostdev> と Assignment with <interface type='hostdev'> (SRIOV デバイスのみ) の相違点については、「PCI Passthrough of host network devices」を参照してください。

(BZ#1792691)

このページには機械翻訳が使用されている場合があります (詳細はこちら)。