Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.7.6. カーネル

tboot-1.9.12-2 ユーティリティーを使用すると、RHEL 8 でシステムが起動できない

バージョン 1.9.12-2 の tboot ユーティリティーにより、TPM(Trusted Platform Module)2.0 の一部のシステムがレガシーモードでの起動に失敗します。これにより、tboot Grand Unified Bootloader(GRUB) エントリーから起動を試みると、システムは停止します。この問題を回避するには、バージョン 1.9.10 の tboot にダウングレードします。

(BZ#1947839)

カーネルが IBM Z システムで誤検出の警告を返す

RHEL 8 では、IBM Z システムで ZONE_DMA メモリーゾーンのホワイトリストエントリーが含まれており、ユーザーアクセスが許可されます。したがって、カーネルは以下のような誤検出の警告を返します。 

...
Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dma-kmalloc-192' (offset 0, size 144)!
WARNING: CPU: 0 PID: 8519 at mm/usercopy.c:83 usercopy_warn+0xac/0xd8
...

sysfs インターフェイスから特定のシステム情報にアクセスする際に警告が表示されます。たとえば、debuginfo.sh スクリプトを実行するなどです。

この問題を回避するには、hardened_usercopy=off パラメーターをカーネルコマンドラインに追加します。

これにより、上記のシナリオで警告メッセージが表示されなくなります。

(BZ#1660290)

rngd サービスのビジー待機により、FIPS モードで CPU が完全に消費される

バージョン 4.18.0-193.10 で始まるカーネル用に、FIPS モードの新しいカーネルエントロピーソースが追加されました。その結果、FIPS モードでは、rngd サービスのビジー状態が /dev/random デバイスの poll() システムコールを待つため、CPU 時間が 100% 消費していました。この問題を回避するには、以下を実行して rngd を停止して無効にします。 

# systemctl stop rngd
# systemctl disable rngd

その結果、rngd は上記のシナリオで poll() でビジー待機しなくなりました。

(BZ#1884857)

softirq の変更により、負荷が大きい場合に localhost インターフェイスが UDP パケットをドロップできるようになります

Linux カーネルのソフトウェア割り込み (softirq) 処理の変更を行い、サービス拒否 (DOS) の影響を軽減します。その結果、これにより、localhost インターフェイスが負荷が大きいときに localhost インターフェイスが UDP (User Datagram Protocol) パケットをドロップする状況が生じます。

この問題を回避するには、ネットワークデバイスのバックログバッファーのサイズを 6000: の値に増やします。 

echo 6000 > /proc/sys/net/core/netdev_max_backlog

Red Hat テストでは、パケットロスを防ぐために十分な値でした。より負荷の高いシステムには、より大きなバックログ値が必要になる場合があります。バックログが増えると、ローカルホストインターフェイスのレイテンシーが増加する可能性があります。

その結果、バッファーを増やし、より多くのパケットを処理まで待機できるため、ローカルホストパケットをドロップする可能性を減らすことができます。

(BZ#1779337)

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

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

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

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

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

# systemctl restart kdump.service

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

(BZ#1793389)

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)

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)

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)

デフォルトの 7 4 1 7 printk 値により、一時的なシステムが応答しなくなることがあります。

デフォルトの 7 4 1 7 printk 値を使用することで、カーネルアクティビティーのデバッグを改善できます。ただし、シリアルコンソールと組み合わせると、この printk 設定により、RHEL システムが一時的に応答しなくなるような激しい I/O がバーストする可能性があります。この問題を回避するには、新しい optimize-serial-console TuneD プロファイルを追加し、デフォルトの printk 値を 4 4 1 7 に減らします。ユーザーは、以下のようにシステムをインストルメント化できます。 

# tuned-adm profile throughput-performance optimize-serial-console

再起動後も printk 値を短くすると、システムがハングする可能性が低くなります。

この設定変更は、余分なデバッグ情報が失われる代償を伴うことに注意してください。

新たに追加された機能の詳細は、printk の値を減らして I/O をシリアルコンソールに減らす新しい optimize-serial-console TuneD プロファイル を参照してください。

(JIRA:RHELPLAN-28940)

カーネル 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)

OPEN MPI ライブラリーは、デフォルトの PML でランタイムが失敗する可能性があります。

OPEN Message Passing Interface (OPEN MPI) 実装 4.0.x シリーズでは、UCX (Unified Communication X) がデフォルトの PML (ポイントツーポイント) です。OPEN MPI 4.0.x シリーズの新しいバージョンでは、openib Byte Transfer Layer (BTL) が非推奨になりました。

ただし、OPEN MPI は 同種 クラスター (同じハードウェアおよびソフトウェア設定) で実行される場合も、UCX は MPI openib の一方向操作に 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)

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る