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 was 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 の境界に調整されたシステムでは、namespace を作成できませんでした。そのため、介入のない永続メモリー設定は、ストレージを使用できませんでした。この問題を回避するには、永続メモリーに interleaved モードを使用します。その結果、ほとんどのストレージが利用できるようになり、障害の分離が制限されています。

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

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

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

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

特定の eBPF ツールにより、IBM Z でシステムが応答しなくなることがあります。

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

/dev/sg の同時 SG_IO 要求が原因でデータが破損する可能性がある

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

内部および外部 VLAN タグの順序が間違っている

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

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

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

KASLR が有効な場合 kdumpctl サービスがクラッシュカーネルをロードできません。

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

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

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