11.7. カーネル
カーネルの kdump メカニズムにより、64K カーネルで OOM エラーが発生します。
64 ビット ARM アーキテクチャー上の 64K カーネルページサイズは、4KB カーネルよりも多くのメモリーを使用します。その結果、kdump はカーネルパニックを引き起こし、メモリー不足 (OOM) エラーでメモリー割り当てが失敗します。回避策として、crashkernel 値を手動で 640 MB に設定します。たとえば、crashkernel= パラメーターを crashkernel=2G- :640M として設定します。
結果として、説明されているシナリオでは、kdump メカニズムは 64K カーネルで失敗しません。
Bugzilla:2160676
カーネルページサイズに依存する顧客アプリケーションは、ページサイズカーネルを 4k から 64k に移行するときに更新が必要になる場合があります。
RHEL は、4k と 64k の両方のページサイズのカーネルと互換性があります。4K カーネルページサイズに依存する顧客アプリケーションは、4K から 64K ページサイズカーネルに移行するときに更新が必要になる場合があります。この既知の例には、jemalloc および依存アプリケーションが含まれます。
jemalloc メモリーアロケータライブラリーは、システムのランタイム環境で使用されるページサイズの影響を受けます。このライブラリーは、たとえば、--with-lg-page=16 または env JEMALLOC_SYS_WITH_LG_PAGE=16 (jemallocator Rust クレートの場合) で設定されている場合、4k および 64k ページサイズのカーネルと互換性があるように構築できます。その結果、ランタイム環境のページサイズと、jemalloc に依存するバイナリーのコンパイル時に存在したページサイズとの間に不一致が発生する可能性があります。その結果、jemalloc ベースのアプリケーションを使用すると、次のエラーが発生します。
<jemalloc>: Unsupported system page size
この問題を回避するには、次のいずれかの方法を使用します。
- 適切なビルド設定または環境オプションを使用して、4k および 64k ページサイズと互換性のあるバイナリーを作成します。
-
最終的な 64k カーネルおよびランタイム環境で起動した後、
jemallocを使用するユーザー空間パッケージをビルドします。
たとえば、同じく jemalloc を使用する fd-find ツールを、cargo Rust パッケージマネージャーを使用して構築できます。最後の 64k 環境では、cargo コマンドを入力して、すべての依存関係の新しいビルドをトリガーし、ページサイズの不一致を解決します。
# cargo install fd-find --force
Bugzilla:2167783
kdump サービスが IBM Z システムで initrd ファイルの構築に失敗する
64 ビットの IBM Z システムでは、s390- subchannels などの znet 関連の設定情報が非アクティブな NetworkManager 接続プロファイルに存在する場合、kdump サービスは初期 RAM ディスク (initrd) のロードに失敗します。その結果、kdump メカニズムは次のエラーで失敗します。
dracut: Failed to set up znet kdump: mkdumprd: failed to make kdump initrd
回避策として、次のいずれかの解決策を使用してください。
znet設定情報を持つ接続プロファイルを再利用して、ネットワークボンディングまたはブリッジを設定します。$ nmcli connection modify enc600 master bond0 slave-type bond
非アクティブな接続プロファイルからアクティブな接続プロファイルに
znet設定情報をコピーします。nmcliコマンドを実行して、NetworkManager接続プロファイルを照会します。# nmcli connection show NAME UUID TYPE Device bridge-br0 ed391a43-bdea-4170-b8a2 bridge br0 bridge-slave-enc600 caf7f770-1e55-4126-a2f4 ethernet enc600 enc600 bc293b8d-ef1e-45f6-bad1 ethernet --
非アクティブな接続からの設定情報でアクティブなプロファイルを更新します。
#!/bin/bash inactive_connection=enc600 active_connection=bridge-slave-enc600 for name in nettype subchannels options; do field=802-3-ethernet.s390-$name val=$(nmcli --get-values "$field"connection show "$inactive_connection") nmcli connection modify "$active_connection" "$field" $val" done
変更を有効にするために
kdumpサービスを再起動します。# kdumpctl restart
kTLS は、TLS 1.3 の NIC へのオフロードをサポートしない
Kernel Transport Layer Security (kTLS) は、TLS 1.3 の NIC へのオフロードをサポートしていません。そのため、NIC が TLS オフロードをサポートしていても、TLS 1.3 によるソフトウェア暗号化が使用されます。この問題を回避するには、オフロードが必要な場合は TLS 1.3 を無効にしてください。その結果、TLS 1.2 のみをオフロードすることができます。TLS 1.3 が使用されている場合、TLS 1.3 をオフロードすることができないため、パフォーマンスが低下します。
Bugzilla:2000616
デフォルトでは、Delay Accounting 機能は SWAPIN および IO% 統計列を表示しない
初期のバージョンとは異なり、Delayed Accounting 機能はデフォルトで無効になっています。その結果、iotop アプリケーションは SWAPIN および IO% 統計列を表示せず、次の警告を表示します。
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO%
taskstats インターフェイスを使用する Delay Accounting 機能は、スレッドグループに属するすべてのタスクまたはスレッドの遅延統計を提供します。タスク実行の遅延は、カーネルリソースが利用可能になるのを待つときに発生します。たとえば、空き CPU が実行されるのを待っているタスクです。統計は、タスクの CPU 優先度、I/O 優先度、および rss 制限値を適切に設定するのに役立ちます。
回避策として、実行時または起動時に、delayacct ブートオプションを有効にすることができます。
実行時に
delayacctを有効にするには、次のように入力します。echo 1 > /proc/sys/kernel/task_delayacct
このコマンドはシステム全体で機能を有効にしますが、このコマンドの実行後に開始したタスクに対してのみ有効であることに注意してください。
起動時に
delayacctを永続的に有効にするには、次のいずれかの手順を使用します。/etc/sysctl.confファイルを編集して、デフォルトのパラメーターをオーバーライドします。次のエントリーを
/etc/sysctl.confファイルに追加します。kernel.task_delayacct = 1
詳細は、Red Hat Enterprise Linux で sysctl 変数を設定する方法 を参照してください。
- システムを再起動して、変更を反映させます。
カーネルコマンドラインに
delayacctオプションを追加します。詳細は、カーネルコマンドラインパラメーターの設定 を参照してください。
その結果、iotop アプリケーションは SWAPIN および IO% 統計列を表示します。
Bugzilla:2132480
kdump メカニズムは、LUKS 暗号化ターゲットで vmcore ファイルをキャプチャーできない
Linux Unified Key Setup (LUKS) で暗号化されたパーティションを使用するシステムで kdump を実行する場合、システムには一定量の使用可能なメモリーが必要です。使用可能なメモリーが必要なメモリー量より少ない場合、systemd-cryptsetup サービスはパーティションのマウントに失敗します。その結果、2 番目のカーネルは LUKS 暗号化ターゲット上のクラッシュダンプファイル (vmcore) のキャプチャに失敗します。
kdumpctl estimate コマンドを使用すると、kdump に必要な推奨メモリーサイズである 推奨クラッシュカーネル値 を照会できます。
この問題を回避するには、次の手順を使用して、LUKS 暗号化ターゲットで kdump に必要なメモリーを設定します。
推定
crashkernel値を出力します。# kdumpctl estimate
crashkernelの値を増やして、必要なメモリー量を設定します。# grubby --args=crashkernel=652M --update-kernel=ALL
システムを再起動して、変更を反映させます。
# reboot
これにより、LUKS で暗号化したパーティションがあるシステムで kdump が正常に機能します。
Bugzilla:2017401
起動時にクラッシュカーネルメモリーの割り当てに失敗する
特定の Ampere Altra システムでは、利用可能なメモリーが 1 GB 未満の場合に、起動中に kdump の使用に対してクラッシュカーネルメモリーの割り当てに失敗します。その結果、kdumpctl コマンドは kdump サービスの起動に失敗します。
この問題を回避するには、以下のいずれかを実行します。
-
crashkernelパラメーターの値を 240 MB 以上減らしてサイズ要件に合わせます (例:crashkernel=240M)。 -
crashkernel=x,highオプションを使用して、kdump用に 4 GB を超えるクラッシュカーネルメモリーを予約します。
その結果、Ampere Altra システムで kdump のクラッシュカーネルメモリー割り当てが失敗しなくなりました。
VMD が有効になっている場合、RHEL が NVMe ディスクを認識できません。
ドライバーをリセットまたは再接続しても、ボリューム管理デバイス (VMD) ドメインは現在ソフトリセットされません。その結果、ハードウェアはデバイスを適切に検出して列挙できなくなります。その結果、VMD が有効になっているオペレーティングシステムは、特にサーバーをリセットするときや VM マシンを操作するときに、NVMe ディスクを認識しません。
Bugzilla:2128610
iwl7260-firmware により、Intel Wi-Fi 6 AX200、AX210、および Lenovo ThinkPad P1 Gen 4 で Wi-Fi が切断される
iwl7260-firmware または iwl7260-wifi ドライバーを 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
未確認の回避策は、システムの電源をオフにしてから再度オンにすることです。再起動しないでください。
Bugzilla:2129288
kmod の weak-modules がモジュールの相互依存関係で機能しない
kmod パッケージによって提供される weak-modules スクリプトは、どのモジュールがインストールされたカーネルと kABI 互換であるかを判別します。しかし、weak-modules は、モジュールのカーネル互換性をチェックする際に、モジュールシンボルの依存関係を、そのビルド対象のカーネルの新しいリリースから古いリリースの順に処理します。結果として、異なるカーネルリリースに対して構築された相互依存関係を持つモジュールは互換性がないと解釈される可能性があるため、weak-modules はこのシナリオでは機能しません。
この問題を回避するには、新しいカーネルをインストールする前に、最新のストックカーネルに対して追加のモジュールをビルドまたは配置します。
Bugzilla:2103605
Mellanox ConnectX-5 アダプターの使用中に mlx5 ドライバーが失敗する
イーサネットスイッチデバイスドライバーモデル (switchdev) モードでは、デバイス管理フローステアリング (DMFS) パラメーターと ConnectX-5 アダプターがサポートするハードウェアを使用して設定されていると、mlx5 ドライバーが失敗します。その結果、次のエラーメッセージが表示されることがあります。
BUG: Bad page cache in process umount pfn:142b4b
この問題を回避するには、DMFS の代わりにソフトウェア管理フローステアリング (SMFS) パラメーターを使用します。
Bugzilla:2180665
コア数が大きいシステムのリアルタイムカーネルのハードウェア認定では、ロックの競合を回避するために 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 を有効にすると、消費電力が大幅に増加するため、レイテンシーの影響を受けるリアルタイムワークロードを実行している場合にのみ有効にする必要があります。
Bugzilla:2214508
64 ビット ARM CPU で正しくコンパイルされたドライバーでのプログラム失敗に関して dkms が誤った警告を出す
Dynamic Kernel Module Support (dkms) ユーティリティーは、64 ビット ARM CPU のカーネルヘッダーが、ページサイズが 4 キロバイトのカーネルと 64 キロバイトのカーネルの両方で動作することを認識しません。その結果、dkms は、カーネルの更新時に kernel-64k-devel パッケージがインストールされていない場合、正しくコンパイルされたドライバーでプログラムが失敗した理由に関して誤った警告を出します。この問題を回避するには、kernel-headers パッケージをインストールします。このパッケージは、両タイプの ARM CPU アーキテクチャー用のヘッダーファイルを含むもので、dkms とその要件に特化したものではありません。
Jira:RHEL-25967
