這個核心警告是一個需要我注意的主要問題嗎？
我們基於 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 站點上發現了類似的錯誤，WARNING: at 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參考
您對 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 <ncardwell@google.com> 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.38，EL5 從未發布過，所以這不是 Red Hat 或 CentOS 核心。我假設您的 NAS 供應商採用了較晚的上游核心，可能應用了一些更新檔，並在您的 SAN 的韌體映像中提供了該核心。如果您想解決這個問題，您可能需要獲取核心 3.3 或更高版本的原始碼，應用您的 SAN 供應商的更新檔，並建構您自己的核心。可能值得檢查這是否已在ELRepo 的 kernel-lt中修復
3.2.63-1.el5，即非常接近 3.3。如果沒有，您可以使用 ELRepo 的.config文件和make oldconfig新核心原始碼來回答最少的問題。話雖如此，無論如何，大並不是什麼大不了的事。這
WARN是由於 TCP 中的記帳錯誤而發生的。如果我對更新檔的理解正確，那麼使用 TCP 分段解除安裝計算數據傳輸的函式會做出一些不正確的假設，從而導致在某些情況下計算的段數是垃圾。通過WARN將其中一個段計數返回為 0 來解決此問題。我認為可能發生的最壞情況是，當丟包時重新傳輸的數據比必要的多一點。您可以通過禁用 TSO 來解決此問題。檢查您是否將 TSO 用於：
ethtool -g ethX如果是這樣，請使用以下命令禁用它：
ethtool -G ethX tso off如果可行，並且您的網路由正常 CentOS 初始化腳本（
/etc/init.d/network和朋友）控制，那麼您可以編寫/sbin/ifup-local以在每次界面啟動時應用更改，如下所示：#!/bin/bash if [ $1 == "ethX" ]]; then /sbin/ethtool -G $1 tso off fi替換
ethX為您的網路介面的名稱。