第57章 カーネル

SCTP パフォーマンスと転送速度が向上

SCTP (Stream Control Transmission Protocol) 実装は、CPU リソースを大量に消費することで知られています。そのため、CPU のリソースが不足していると、転送速度を上げるのが困難になります (たとえば、単一のアソシエーションで 10 Gbps など)。今回の更新では、特定の SCTP 処理で CPU の使用量が削減される改良が加えられ、SCTP のパフォーマンスが改善されました。その結果、状況によって転送速度が向上されます。
この更新は、SCTP による 10Gbps の転送速度を保証するものではありません (BZ#1058148)。

トランスポートまたはアソシエーションを検索するとカーネルパニックが発生することがある

Use-after-free バグが原因で、カーネルの SCTP (Stream Control Transmission Protocol) 実装は使用中にトランスポートパスへのポインターを保持しません。そのため、別の CPU がポインターを開放し、利用できないはずのメモリーへアクセスできるため、カーネルパニックが発生します。この問題解決への取り組みは https://bugzilla.redhat.com/show_bug.cgi?id=1368884 で確認できます (BZ#1368884)。

dracut が存在しない /etc/hba.conf に関する悪影響のないエラーメッセージを表示

dracut で FCoE (Fibre Channel over Ethernet) サポートを持つ初期 RAM ファイルシステム (initramfs) を作成する場合、/etc/hba.confファイルが存在しないと dracut がエラーメッセージを表示します。このメッセージは無視しても問題ありません (BZ#1373129)。

kdump がレガシーの Type 12 永続メモリーで動作しない

レガシーの Type 12 NVDIMM (Non-Volatile Dual In-line Memory Module) を持つシステムでは、真の DIMM (Dual In-line Memory Module) または _memmap=XG!YG カーネルコマンドラインパラメーターを使用したエミュレートのどちらの場合でも、正常にカーネルクラッシュダンプをキャプチャーできません。真の NVDIMM を持つシステムでは、カーネルクラッシュダンプをキャプチャーしようとすると、データが破損することがあります。この問題を回避するには、このようなシステムで kdump 機能を無効にします (BZ#1351098)。

megaraid_sas を更新するとパフォーマンスが劣化することがある

megaraid_sas ドライバーが 06.811.02.00-rh1 に更新され、以前のバージョンにパフォーマンスの改善点が多く加えられました。しかし、場合によっては SSD (Solid-state Drive) ベースの設定でパフォーマンスの劣化が報告されました。この問題を回避し、パフォーマンスを元の状態に戻すには、/sys/ ディレクトリーの対応する can_queue パラメーターをより大きな値 (最大値 256) に設定します (BZ#1367444)。

xgene-enet が空きメモリーが少ない状態を処理しない

現在、xgene_enetドライバーはメモリー不足エラーを適切に処理しません。このようなエラーが発生すると、ドライバーが予期せず終了することがあり、カーネルバックトレースをシリアルコンソールおよび dmesg ログに返します。その結果、システムはネットワーク上で通信できなくなり、再起動する必要があります (BZ#1248185)。

一部の NIC ファームウェアが bnx2x で反応しない

プリブートドライバーのアンロードシーケンスのバグにより、 bnx2x ドライバーがデバイスを引き継いだ後に一部のインターネットアダプターのファームウェアが反応しなくなります。 bnx2x ドライバーはこの問題を検出し、storm stats were not updated for 3 times というメッセージをカーネルログに返します。この問題を回避するには、ハードウェアベンダーが提供する最新の NIC ファームウェアの更新を適用します。これにより、プリブートファームウェアのアンロードが想定どおりに動作し、bnx2x がデバイスを引き継いだ後もファームウェアはハングしないようになります (BZ#1315400)。

kdump メカニズムの適切な機能を利用するために FCoE サーバーのデフォルト設定を変更

FCoE (Fibre Channel over Ethernet) サーバーのディスクは、異なるインターフェースからディスクがシステムに接続できるマルチパスストレージシステムを使用します。システムには複数の論理ディスクが存在しますが、1 つの真のディスクへのみマッピングされます。そのため、デフォルト設定では FCoE サーバーは kdump カーネルで起動できません。kdump メカニズムの正しい機能を利用するため、FCoE ディスクの UUID (Universally Unique Identifier) を指定することが推奨されます。また、ディスクがより効率的に管理されるようにするため、multipath オプションを有効にすることも推奨されます (BZ#1293520)。

iSCSI 接続によって I/O エラーが発生

Red Hat Enterprise Linux 7.3 は、SCSI ディスクの I/O リクエストを最大 512Kib に制限しないようになりました。そのため、Red Hat Enterprise Linux 7.3 で実行しているゲストが、fileio バックストアを使用するよう設定され古いバージョンの Red Hat Enterprise Linux を実行している iSCSI ターゲットに接続すると、ログに警告メッセージが表示され、パフォーマンスも悪影響を受けます。この問題を回避するには、システムに udev ルールをインストールし、I/O リクエストのサイズを最大 4096Kib に制限します。fileio バックストアの問題は、iSCSI ターゲットを Red Hat Enterprise Linux 7.3 にアップグレードすると修正されます (BZ#1387858)。

ディスプレイポートケーブルが接続されていると MST ディスプレイが反応しない

以前のリリースでは、無関係の dp-aux メッセージが I2C デバイスの読み書きを実装した dp-aux メッセージのシーケンスを割り込みしたため、ディスプレイポートケーブルが接続されていると Dell MST ディスプレイが反応しなくなりました。今回の更新により、 I2C-over-dp-aux シーケンスが無関係の MST 設定メッセージによって割り込みされなくなり、このような状況でも MST ディスプレイが反応するようになりました (BZ#1274157)。

IBM Power Systems で fadump が以前に使用された場合に kdump が失敗する (両方がネットワークターゲットを使用する場合)

同じシステムが firmware-assisted dumping (fadump) を使用し、ダンプをリモートで保存するよう以前に設定された場合に、kdump カーネルクラッシュダンプメカニズムがネットワークの場所へのダンプの保存に失敗します。これは、メカニズムが kdump に切り替えられたときに、設定されたネットワークインターフェースに kdump- 接頭辞が追加されるが、fadump により同じ接頭辞がすでに設定されているためです。結果として、インターフェース名は kdump-kdump-eth0 になり、最後の 0 は切り捨てられます。この結果、無効なインターフェース名 kdump-kdump-eth になり、kdump がインターフェースへのアクセスとリモートターゲットへのクラッシュダンプの保存に失敗するようになります。
この問題を回避するには、以下の手順を実行します。
1. 現在の /boot/initramfs-$kver.img initrd を /boot /initramfs-$kver.img.default ファイルに置き換えます。
2. 再起動後にkdump initrd の再ビルドを強制するために touch /etc/kdump.conf コマンドを実行します。
3. システムを再起動します (BZ#1372464)。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。