5.4.6. カーネル


huge_page_setup_helper.py スクリプトが正しく動作する

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

SyntaxError: Missing parentheses in call to 'print'

今回の更新で、libhugetlbfs.spec ファイルを更新してこの問題が修正されています。その結果、huge_page_setup_helper.py に上記のシナリオでエラーが表示されなくなりました。

(BZ#1823398)

大量の永続メモリーを備えたシステムは、タイムアウトなしでより迅速に起動します

元のソースコードではノードごとに 1 つの初期化スレッドしか許可されていなかったため、大量の永続メモリーを備えたシステムは起動に長い時間がかかりました。たとえば、4 ノードシステムの場合は、4 つのメモリー初期化スレッドがありました。したがって、/etc/fstab ファイルに永続メモリーのファイルシステムがあると、デバイスが利用できるようになるまで待つ際に、システムがタイムアウトする場合があります。今回の更新では、ソースコードが単一ノード内で複数のメモリー初期化スレッドを許可するようになったため、問題が修正されました。その結果、システムはより迅速に起動し、説明されているシナリオではタイムアウトは発生しません。

(BZ#1666538)

bcc スクリプトが正常に BPF モジュールをコンパイル

スクリプトコードをコンパイルして Berkeley Packet Filter (BPF) モジュールを作成すると、bcc ツールキットはデータタイプ定義にカーネルヘッダーを使用していました。一部のカーネルヘッダーには、KBUILD_MODNAME マクロを定義する必要がありました。そのため、KBUILD_MODNAME を追加しない bcc スクリプトでは、さまざまな CPU アーキテクチャー全体で BPF モジュールをコンパイルする可能性がありました。以下の bcc スクリプトは影響を受けます。

  • bindsnoop
  • sofdsnoop
  • solisten
  • tcpaccept
  • tcpconnect
  • tcpconnlat
  • tcpdrop
  • tcpretrans
  • tcpsubnet
  • tcptop
  • tcptracer

今回の更新で、bcc のデフォルトの cflags パラメーターに KBUILD_MODNAME を追加することで、この問題が修正されています。その結果、この問題は上記のシナリオで表示されなくなります。また、カスタマースクリプトは、KBUILD_MODNAME 自体を定義する必要はありません。

(BZ#1837906)

IBM Z で bcc-tools および bpftrace が適切に動作するようになりました。

以前のバージョンでは、機能のバックポートにより、ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE カーネルオプションが導入されました。ただし、IBM Z アーキテクチャー用の bcc-tools パッケージおよび bpftrace トレース言語パッケージでは、このオプションが適切にサポートされませんでした。そのため、bpf() システムコールが Invalid argument exception で失敗し、bpftrace が BPF プログラムを読み込む際に Error loading program を示すエラーを出して失敗しました。今回の更新により、ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE オプションが削除されました。その結果、上記のシナリオで問題が表示されなくなりました。

(BZ#1847837、BZ#1853964)

エントロピーがないためブートプロセスが失敗しなくなる

以前のバージョンでは、エントロピーがないためにブートプロセスが失敗しました。カーネルがブートプロセスの早い段階でエントロピーを収集できるように、より良いメカニズムが使用されるようになりました。これは、ハードウェア固有の割り込みに依存しません。今回の更新では、起動の初期で無作為な生成のセキュリティーを保護するのに十分なエントロピーの可用性を確保することでこの問題が修正されています。その結果、この修正によりキックスタートのタイムアウトや起動速度が遅くなり、起動プロセスが期待どおりに機能します。

(BZ#1778762)

kexec を使用した再起動が期待どおりに動作する

以前のバージョンでは、Amazon EC2 Nitro プラットフォームでカーネルを再起動すると、カーネル実行パスの shutdown() の呼び出し中に remove モジュール (rmmod) が呼び出されませんでした。したがって、kexec システムコールを使用してカーネルを再起動すると、失敗していました。今回の更新で、安全なカーネル実行を可能にする PCI shutdown() ハンドラーを追加してこの問題が修正されています。その結果、Amazon EC2 Nitro プラットフォームで kexec を使用した再起動が繰り返し行われなくなりました。

(BZ#1758323)

ダンプターゲットとして vPMEM メモリーを使用した繰り返し再起動が期待どおりに機能するようになりました。

以前は、kdump または fadump のダンプターゲットとして仮想永続メモリー (vPMEM) 名前空間を使用すると、papr_scm モジュールが vPMEM がサポートするメモリーのマッピングを解除し、メモリーをリニアマップに再追加していました。

その結果、この動作により、ハイパーバイザーコール (HCall) がトリガーされ、POWER Hypervisor がトリガーされます。その結果、キャプチャーカーネルブートが大幅に遅くなり、ダンプファイルを保存するのに時間がかかります。今回の更新で問題が修正され、上記のシナリオで起動プロセスが期待どおりに動作するようになりました。

(BZ#1792125)

ICE ドライバーの NIC ポートをモード 5 ボンディングマスターインターフェイスに追加しようとしても失敗しなくなりました。

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

(BZ#1791664)

cxgb4 ドライバーにより、kdump カーネルでクラッシュが発生しなくなる

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

RHSA-2020:1769 アドバイザリーのリリースにより、kdump カーネルがこの状況を適切に処理し、クラッシュしなくなりました。

(BZ#1708456)

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る