8.5. カーネル

RHEL 7 仮想マシンが ESXi 5.5 で起動に失敗することがある

VMware ESXi 5.5 ハイパーバイザーで RAM が 12GB 以上の Red Hat Enterprise Linux 7 ゲストを実行している場合、一部のコンポーネントは現在、間違ったメモリータイプ範囲レジスター (MTRR) 値で初期化されていたり、システムの起動時に MTRR 値が間違って再設定されています。これにより、ゲストカーネルがパニック状態になったり、ゲストがシステムの起動時に応答しなくなることがあります。

bnx2x で特定の NIC ファームウェアが応答しなくなることがある

ブート前のドライバーのアンロードシーケンスのバグにより、bnx2x ドライバーがデバイスを引き継ぐと、一部のインターネットアダプターのファームウェアが応答しなくなることがあります。bnx2x ドライバーは問題を検出し、カーネルログにメッセージ "storm stats were not updated for 3 times" を返します。この問題を回避するには、ハードウェアベンダーが提供する最新の NIC ファームウェアの更新を適用します。その結果、起動前のファームウェアのアンロードが期待どおりに機能し、bnx2x がデバイスを引き継ぐとファームウェアがハングしなくなりました。

i40iw モジュールがシステムの起動時に自動的に読み込まれない

一部の i40e NIC は iWarp に対応しておらず、i40iw モジュールは一時停止および再開操作を完全にサポートしません。そのため、i40iw モジュールはデフォルトで自動的に読み込まれず、一時停止および再開の操作が正しく機能するようになりました。この問題を回避するには、/lib/udev/rules.d/90-rdma-hw-modules.rules ファイルを編集して、i40iw の自動読み込みを有効にします。

インターリーブされていない永続メモリー設定はストレージを使用できません

以前は、永続メモリーを備えたシステムが 64 MB の境界に合致し、名前空間を作成できませんでした。その結果、非インターリーブな永続メモリー設定がストレージを使用できない場合がありました。この問題を回避するには、永続メモリーにインターリーブモードを使用します。その結果、ほとんどのストレージが使用できるようになり、障害分離が制限されました。

永続メモリーのファイルシステムが原因で、システムの起動が失敗する場合がある

永続メモリーのサイズが大きい場合は、システムの起動に時間がかかります。/etc/fstab ファイルが、永続メモリーのファイルシステムを設定すると、デバイスが利用可能になる前にシステムがタイムアウトになる場合があります。その後システムの起動プロセスに失敗して、緊急プロンプトが表示されます。

radeon がハードウェアを適切なハードウェアリセットに失敗します。

現在、radeon カーネルドライバーは、kexec コンテキストでハードウェアを正しくリセットしません。代わりに、radeon が突然終了するため、残りの kdump サービスが失敗します。

一部の eBPF ツールを使用すると、IBM Z でシステムが応答しなくなることがあります。

JIT コンパイラーのバグにより、IBM Z の bcc-tools パッケージに含まれる特定の eBPF ツールを実行すると、システムが応答しなくなる可能性があります。この問題を回避するには、修正がリリースされるまで、IBM Z の bcc-tools の dcsnoop ツール、runqlen ツール、および slabratetop ツールの使用は避けてください。

/dev/sg の同時 SG_IO 要求により、データが破損する可能性があります。

/dev/sg デバイスドライバーは、カーネルデータの同期がありません。ドライバーの同時要求は、同時に同じデータにアクセスします。

内部および外部 VLAN タグの順序が正しくない

mlx5 ドライバーを使用する場合、システムはレプリゼンターデバイス (IEEE802.1Q は IEEE802.1Q 標準では IEEE802.1Q) を使用する場合にスワップされた順序で内部および外部 VLAN タグを受け取ります。これは、rxvlan オフロードスイッチがこのパスでは有効ではなく、Open vSwitch (OVS) がこのエラーを転送するためです。既知の回避策はありません。

RHEL 7 の Azure インスタンスで kdump が vmcore の生成に失敗する

UEFI ブートローダーを介して起動した Azure インスタンスでのシリアルコンソール実装に関する根本的な問題により、kdump カーネルを起動できません。したがって、クラッシュしたカーネルの vmcore は、/var/crash/ ディレクトリーに取得できません。この問題を回避するには、以下を実行します。

KASLR が有効になっている場合、kdumpctl サービスがクラッシュカーネルのロードに失敗する

kptr_restrict カーネルチューナブルの不適切な設定により、/proc/kcore ファイルの内容がすべてゼロとして生成されます。これにより、Kernel Address Space Layout Randomization (KASLR) が有効になっている場合、kdumpctl サービスは /proc/kcore にアクセスし、クラッシュカーネルを読み込むことができません。この問題を回避するには、kptr_restrict を 1 に設定します。これにより、上記のシナリオで kdumpctl がクラッシュカーネルを読み込むことができます。

kdump が 2 番目のカーネルで失敗する

kdump initramfs アーカイブは、クラッシュダンプを取得するために重要なコンポーネントです。ただし、これは実行するマシン用に厳密に生成され、一般性はありません。ディスクの移行を行ったり、ディスクイメージを含む新しいマシンをインストールした場合に、2 番目のカーネルで kdump が失敗する可能性があります。