Este kernel é um grande problema que precisa da minha atenção?

Question

Nosso NAS N12000 da Thecus baseado em Linux experimentou recentemente esta mensagem em seu log 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 ]---

Ao pesquisar essa mensagem de erro, tenho apenas encontrou as seguintes informações :

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

Também encontrei este erro semelhante no site oops.kernel.org, AVISO: em net / ipv4 / tcp_input.c: 2966 tcp_ack + 0xdbe / 0x1f80 .

Este é apenas um aviso sem problemas que podemos ignorar que é sintomático de alguma outra coisa com a qual eu deveria me preocupar?

Este não é um aparelho?

OBSERVAÇÃO: Embora este seja um dispositivo Linux, ele é baseado no CentOS. Trouxe binários criados no CentOS 5 de vez em quando para a caixa e eles funcionam sem problemas. Ferramentas como df , por exemplo.

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

Referências

• Manual do usuário do N12000
• Páginas do produto N12000

Answer 1

Você está correto sobre a localização do WARN, este código é da tag do kernel upstream 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 

Isso é discutido aqui e corrigido com commit:

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

A data coloca sua correção no kernel 3.3. Esta correção não foi backportada para a fonte EL5 da Red Hat (eu verifiquei o kernel 5.11 2.6.18-398) então se o seu NAS é baseado no CentOS 5 então isso não é fixo.

Vale a pena notar que nunca houve um 2.6.38 liberado para o EL5, então este não é um kernel Red Hat ou CentOS. Eu suponho que seu fornecedor NAS tenha um kernel upstream posterior, talvez tenha aplicado alguns patches e fornecido esse kernel na imagem de firmware de sua SAN.

Se você quiser corrigir isso, provavelmente precisará obter a origem do kernel 3.3 ou posterior, aplicar os patches de seu fornecedor de SAN e construir seu próprio kernel. Provavelmente vale a pena verificar se isso está corrigido no kernel do ltRe-lt que é 3.2.63-1.el5 , é muito perto de 3.3. Caso contrário, você poderia usar o arquivo .config do ELRepo e make oldconfig na nova fonte do kernel para responder a um mínimo de perguntas.

Dito isto, o grande não é um grande negócio de qualquer maneira. O WARN ocorre devido a um erro de contabilidade no TCP. Se eu entendi o patch corretamente, as funções que consideram os dados transmitidos usando o TCP Segmentation Offloading fazem algumas suposições incorretas, resultando em um número de lixo de segmentos sendo contados sob algumas condições. O WARN corrige isso retornando uma das contagens do segmento para 0. Eu acho que o pior que pode acontecer é que um pouco mais de dados do que o necessário seja retransmitido quando houver perda de pacotes.

Você pode conseguir contornar isso desabilitando o TSO. Verifique se você está usando o TSO com:

ethtool -g ethX

Se sim, desative-o com:

ethtool -G ethX tso off

Se isso funcionar, e sua rede for controlada pelos scripts internos do CentOS ( /etc/init.d/network e amigos), então você pode escrever /sbin/ifup-local para que a mudança se aplique toda vez que a interface for iniciada, assim:

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

Substitua ethX pelo nome da sua interface de rede.

    

Answer 2

Este é um erro no caminho do código de rede e não tem relação com o problema de hardware sozinho. Duvido que você tenha muita preocupação com o dispositivo em si. Você pode verificar se há quedas de pacotes de rede que podem causar problemas usando ethtool -S e em outros dispositivos de rede, apenas no caso.

É possível que você tenha algum problema de rede ou que o kernel tenha ficado confuso sobre algum tráfego TCP.