8.5. カーネル
RHEL 7 仮想マシンが ESXi 5.5 で起動に失敗することがある
VMware ESXi 5.5 ハイパーバイザーで RAM が 12GB 以上の Red Hat Enterprise Linux 7 ゲストを実行している場合、一部のコンポーネントは現在、間違ったメモリータイプ範囲レジスター (MTRR) 値で初期化されていたり、システムの起動時に MTRR 値が間違って再設定されています。これにより、ゲストカーネルがパニック状態になったり、ゲストがシステムの起動時に応答しなくなることがあります。
この問題を回避するには、ゲストのカーネルコマンドラインに disable_mtrr_trim オプションを追加します。これにより、MTRR が正しく設定されていない場合でも、ゲストは起動を続行できます。このオプションを使用すると、ゲストは起動中に WARNING: BIOS bug メッセージを出力することに注意してください。これは無視しても問題ありません。
(BZ#1429792)
bnx2x で特定の NIC ファームウェアが応答しなくなることがある
ブート前のドライバーのアンロードシーケンスのバグにより、bnx2x ドライバーがデバイスを引き継ぐと、一部のインターネットアダプターのファームウェアが応答しなくなることがあります。bnx2x ドライバーは問題を検出し、カーネルログにメッセージ "storm stats were not updated for 3 times" を返します。この問題を回避するには、ハードウェアベンダーが提供する最新の NIC ファームウェアの更新を適用します。その結果、起動前のファームウェアのアンロードが期待どおりに機能し、bnx2x がデバイスを引き継ぐとファームウェアがハングしなくなりました。
(BZ#1315400)
i40iw モジュールがシステムの起動時に自動的に読み込まれない
一部の i40e NIC は iWarp に対応しておらず、i40iw モジュールは一時停止および再開操作を完全にサポートしません。そのため、i40iw モジュールはデフォルトで自動的に読み込まれず、一時停止および再開の操作が正しく機能するようになりました。この問題を回避するには、/lib/udev/rules.d/90-rdma-hw-modules.rules ファイルを編集して、i40iw の自動読み込みを有効にします。
また、同じマシンにある i40e デバイスに、別の RDMA デバイスがインストールされている場合に、i40e 以外の RDMA デバイスで、i40iw モジュールを含む、有効なすべての RDMA スタックモジュールを読み込む rdma サービスが起動します。
(BZ#1622413)
インターリーブされていない永続メモリー設定はストレージを使用できません
以前は、永続メモリーを備えたシステムが 64 MB の境界に合致し、名前空間を作成できませんでした。その結果、非インターリーブな永続メモリー設定がストレージを使用できない場合がありました。この問題を回避するには、永続メモリーにインターリーブモードを使用します。その結果、ほとんどのストレージが使用できるようになり、障害分離が制限されました。
(BZ#1691868)
永続メモリーのファイルシステムが原因で、システムの起動が失敗する場合がある
永続メモリーのサイズが大きい場合は、システムの起動に時間がかかります。/etc/fstab ファイルが、永続メモリーのファイルシステムを設定すると、デバイスが利用可能になる前にシステムがタイムアウトになる場合があります。その後システムの起動プロセスに失敗して、緊急プロンプトが表示されます。
この問題を回避するには、/etc/systemd/system.conf ファイルの DefaultTimeoutStartSec の値を大きくします。十分に大きな値 (1200s など) を使用します。これにより、システムの起動がタイムアウトしなくなります。
(BZ#1666535)
radeon がハードウェアを適切なハードウェアリセットに失敗します。
現在、radeon カーネルドライバーは、kexec コンテキストでハードウェアを正しくリセットしません。代わりに、radeon が突然終了するため、残りの kdump サービスが失敗します。
このバグを回避するには、/etc/kdump.conf ファイルに以下の行を追加して、kdump に radeon をブラックリストとして追加します。
dracut_args --omit-drivers "radeon"
その後、マシンおよび kdump を再起動します。
このシナリオでは、kdump 時にグラフィックは利用できませんが、kdump は問題なく完了します。
(BZ#1509444)
一部の eBPF ツールを使用すると、IBM Z でシステムが応答しなくなることがあります。
JIT コンパイラーのバグにより、IBM Z の bcc-tools パッケージに含まれる特定の eBPF ツールを実行すると、システムが応答しなくなる可能性があります。この問題を回避するには、修正がリリースされるまで、IBM Z の bcc-tools の dcsnoop ツール、runqlen ツール、および slabratetop ツールの使用は避けてください。
(BZ#1724027)
/dev/sg の同時 SG_IO 要求により、データが破損する可能性があります。
/dev/sg デバイスドライバーは、カーネルデータの同期がありません。ドライバーの同時要求は、同時に同じデータにアクセスします。
そのため、ioctl システムコールが、正しいコマンドと同時に送信された別のコマンドの SG_IO 要求のペイロードを誤って使用する可能性があります。これにより、特定のケースでディスクが破損する可能性があります。Red Hat は、Red Hat Virtualization (RHV) でこのバグを確認しています。
この問題を回避するには、以下のいずれかのソリューションを使用します。
-
/dev/sgドライバーに同時リクエストを送信しないでください。その結果、/dev/sgに送信される各SG_IOリクエストは、正しいデータが使用されることが保証されます。 -
または、
/dev/sgドライバーの代わりに、/dev/sdドライバーまたは/dev/bsgドライバーを使用します。これらのドライバーにはバグがありません。
(BZ#1710533)
内部および外部 VLAN タグの順序が正しくない
mlx5 ドライバーを使用する場合、システムはレプリゼンターデバイス (IEEE802.1Q は IEEE802.1Q 標準では IEEE802.1Q) を使用する場合にスワップされた順序で内部および外部 VLAN タグを受け取ります。これは、rxvlan オフロードスイッチがこのパスでは有効ではなく、Open vSwitch (OVS) がこのエラーを転送するためです。既知の回避策はありません。
(BZ#1701502)
RHEL 7 の Azure インスタンスで kdump が vmcore の生成に失敗する
UEFI ブートローダーを介して起動した Azure インスタンスでのシリアルコンソール実装に関する根本的な問題により、kdump カーネルを起動できません。したがって、クラッシュしたカーネルの vmcore は、/var/crash/ ディレクトリーに取得できません。この問題を回避するには、以下を実行します。
-
/etc/sysconfig/kdumpディレクトリーのKDUMP_COMMANDLINE_REMOVEコマンドラインにconsole=ttyS0パラメーターおよびearlyprintk=ttyS0パラメーターを追加します。 -
kdumpサービスを再起動します。
その結果、kdump カーネルが正常に起動し、クラッシュ時に vmcore がキャプチャーされることが予想されます。
システムメモリーのサイズまで、vmcore を保存するのに十分な領域が /var/crash/ にあることを確認します。
(BZ#1724993)
KASLR が有効になっている場合、kdumpctl サービスがクラッシュカーネルのロードに失敗する
kptr_restrict カーネルチューナブルの不適切な設定により、/proc/kcore ファイルの内容がすべてゼロとして生成されます。これにより、Kernel Address Space Layout Randomization (KASLR) が有効になっている場合、kdumpctl サービスは /proc/kcore にアクセスし、クラッシュカーネルを読み込むことができません。この問題を回避するには、kptr_restrict を 1 に設定します。これにより、上記のシナリオで kdumpctl がクラッシュカーネルを読み込むことができます。
詳細は、/usr/share/doc/kexec-tools/kexec-kdump-howto.txt ファイルを参照してください。
(BZ#1600148)
kdump が 2 番目のカーネルで失敗する
kdump initramfs アーカイブは、クラッシュダンプを取得するために重要なコンポーネントです。ただし、これは実行するマシン用に厳密に生成され、一般性はありません。ディスクの移行を行ったり、ディスクイメージを含む新しいマシンをインストールした場合に、2 番目のカーネルで kdump が失敗する可能性があります。
この問題を回避するには、ディスクの移行を行っている場合は、次のコマンドを実行して initramfs を手動で再構築します。
# touch /etc/kdump.conf # kdumpctl restart
新しいマシンをインストールするためのディスクイメージを作成する場合は、ディスクイメージに kdump initramfs を含めないことを強く推奨します。領域を節約し、欠落している場合は kdump が自動的に initramfs を構築します。
(BZ#1723492)
