☰

このカーネル警告は注意が必要な主な問題ですか？

tag-icon • tag-icon networking kernel-modules tcp nas
このカーネル警告は注意が必要な主な問題ですか？

LinuxベースのThecus N12000 NASは、最近のdmesgログでこのメッセージを発見しました。

[2014-05-21 11:34:56]  ------------[ cut here ]------------
[2014-05-21 11:34:56]  WARNING: at net/ipv4/tcp_input.c:2966 tcp_ack+0xd88/0x1a1c()
[2014-05-21 11:34:56]  Hardware name: IRONLAKE & IBEX PEAK Chipset
[2014-05-21 11:34:56]  Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ntfs ses enclosure usblp usb_storage usbhid xhci_hcd uhci_hcd ehci_hcd usbcore sg be2net tehuti igb ixgbe dca e1000e drm_kms_helper drm video backlight sata_sil24 mpt2sas ahci libahci ata_piix
[2014-05-21 11:34:56]  Pid: 1710, comm: smbd Not tainted 2.6.38 #1
[2014-05-21 11:34:56]  Call Trace:
[2014-05-21 11:34:56]   [<ffffffff8103118e>] ? warn_slowpath_common+0x78/0x8c
[2014-05-21 11:34:56]   [<ffffffff81391339>] ? tcp_ack+0xd88/0x1a1c
[2014-05-21 11:34:56]   [<ffffffff81392ca5>] ? tcp_rcv_established+0x780/0x9d1
[2014-05-21 11:34:56]   [<ffffffff81392d42>] ? tcp_rcv_established+0x81d/0x9d1
[2014-05-21 11:34:56]   [<ffffffff8139a52d>] ? tcp_v4_do_rcv+0x1a1/0x377
[2014-05-21 11:34:56]   [<ffffffff8139a52d>] ? tcp_v4_do_rcv+0x1a1/0x377
[2014-05-21 11:34:56]   [<ffffffff81413149>] ? _raw_spin_lock_bh+0x9/0x1f
[2014-05-21 11:34:56]   [<ffffffff8135374c>] ? release_sock+0x19/0x103
[2014-05-21 11:34:56]   [<ffffffff81413149>] ? _raw_spin_lock_bh+0x9/0x1f
[2014-05-21 11:34:56]   [<ffffffff813537cd>] ? release_sock+0x9a/0x103
[2014-05-21 11:34:56]   [<ffffffff8138a89a>] ? tcp_recvmsg+0x48f/0x9f5
[2014-05-21 11:34:56]   [<ffffffff8138c24d>] ? tcp_sendpage+0x595/0x5a7
[2014-05-21 11:34:56]   [<ffffffff81350048>] ? sock_sendmsg+0xc3/0xe0
[2014-05-21 11:34:56]   [<ffffffff813a5f60>] ? inet_recvmsg+0x64/0x75
[2014-05-21 11:34:56]   [<ffffffff8134f84e>] ? sock_sendpage+0x36/0x3d
[2014-05-21 11:34:56]   [<ffffffff8134f7aa>] ? sock_aio_read+0x126/0x13a
[2014-05-21 11:34:56]   [<ffffffff810a0f4d>] ? do_sync_read+0xb1/0xea
[2014-05-21 11:34:56]   [<ffffffff810a1921>] ? vfs_read+0xbd/0x12d
[2014-05-21 11:34:56]   [<ffffffff810a1a47>] ? sys_read+0x45/0x6e
[2014-05-21 11:34:56]   [<ffffffff810027fb>] ? system_call_fastpath+0x16/0x1b
[2014-05-21 11:34:56]  ---[ end trace cdaf61db513385a1 ]---

このエラーメッセージを調べている間次の情報が見つかりました:

if (WARN_ON(!tp->sacked_out && tp->fackets_out))
    tp->fackets_out = 0;

oops.kernel.orgのウェブサイトでも同様のエラーが見つかりました。警告: net/ipv4/tcp_input.c:2966 tcp_ack+0xdbe/0x1f80に位置。

これは無視できる問題のない警告ですか、それとも私が心配しなければならない他の問題の症状ですか？

これは家電製品ではありませんか？

メモ:これはLinuxデバイスですが、実際にはCentOSに基づいています。時にはCentOS 5に構築されたバイナリをコンピュータにインストールしましたが、問題なく実行されました。たとえば、ツールdf。

$ uname -a
Linux tank 2.6.38 #1 SMP Fri Oct 26 14:35:05 CST 2012 x86_64 GNU/Linux

引用する

答え1

WARNに対するあなたのコメントは正しいです。このコードはアップストリームカーネルタグから来ますv2.6.38。

net/ipv4/tcp_input.c
2953 static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
2954 {
...
2964         if (WARN_ON(!tp->sacked_out && tp->fackets_out))
2965                 tp->fackets_out = 0;
2966

これは議論されるここ以下をコミットして修正しました。

commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a
Author: Neal Cardwell <[email protected]>
Date:   Sat Jan 28 17:29:46 2012 +0000

    tcp: fix tcp_trim_head() to adjust segment count with skb MSS

その日にカーネル3.3に修正が適用されました。この修正はRed HatのEL5ソース（5.11カーネル2.6.18-398検証）としてバックポートされていないため、NASがCentOS 5に基づいている場合、この問題はまだ解決されていません。

2.6.38EL5カーネルはリリースされていないため、Red HatまたはCentOSカーネルではないことは注目に値します。あなたのNASベンダーが最新のアップストリームカーネルを採用し、いくつかのパッチを適用してSANのファームウェアイメージで利用できるようにしたとします。

この問題を解決するには、カーネル3.3以降のソースコードを入手し、SANベンダーのパッチを適用した後に独自のカーネルを構築する必要があるかもしれません。この問題が解決したかどうかを確認することをお勧めします。ELRepoのカーネル-ltつまり3.2.63-1.el5、3.3に非常に近いです。それ以外の場合は、ELRepoの.configドキュメントとmake oldconfig新しいカーネルソースを使用して最小限の質問に答えることができます。

そういえば、大きいというのはとにかく大きな問題ではない。これはWARNTCP のアカウントエラーが原因で発生します。パッチを正しく理解すると、TCP分割オフロードを使用してデータを送信する関数が誤った仮定を引き起こし、場合によっては計算されたセグメントの数がガベージになります。WARNセグメント数の 1 つを 0 に戻してこの問題を解決してください。考える最悪のシナリオは、パケット損失が発生し、必要以上に少し多くのデータが再送信される場合です。

TSOを無効にすると、この問題を解決できます。 TSOを使用していることを確認してください。

ethtool -g ethX

その場合は、以下を使用して無効にします。

ethtool -G ethX tso off

これが機能し、ネットワークが通常のCentOS initスクリプト（および友達）によって制御されている場合は、次のようにインターフェイスが起動されるたびに変更を適用するように/etc/init.d/network作成できます。/sbin/ifup-local

#!/bin/bash
if [ $1 == "ethX" ]]; then
  /sbin/ethtool -G $1 tso off
fi

ethXネットワークインタフェースの名前に変更してください。

答え2

これはネットワークコードパスのバグであり、ハードウェアの問題自体とは何の関係もありません。機器自体に対する悩みが多いようですが。 ethtool -Sを使用して問題を引き起こす可能性があるネットワークパケットの損失を確認し、場合によっては他のネットワークデバイスを確認できます。

ネットワークに問題があるか、一部のTCPトラフィックによってカーネルが混乱する可能性があります。

関連情報