Meu servidor falha. Este é o log. O que é provável que aconteça?

Question

Este é o conteúdo de / var / messages quando as coisas desmoronam:

Dec 21 19:47:45 localhost kernel: ------------[ cut here ]------------
Dec 21 19:47:45 localhost kernel: WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0x26d/0x280() (Not tainted)
Dec 21 19:47:45 localhost kernel: Hardware name: KGP(M)E-D16
Dec 21 19:47:45 localhost kernel: NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
Dec 21 19:47:45 localhost kernel: Modules linked in: ipt_REDIRECT iptable_nat nf_nat xt_multiport xt_owner ext3 jbd nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables autofs4 sunrpc cpufreq_ondemand powernow_k8 freq_table mperf ipv6 e1000e microcode serio_raw k10temp edac_core edac_mce_amd i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sd_mod crc_t10dif ata_generic pata_acpi pata_atiixp ahci dm_mirror dm_region_hash dm_log dm_mod [last unloaded: nf_conntrack]
Dec 21 19:47:45 localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.32-220.el6.x86_64 #1
Dec 21 19:47:45 localhost kernel: Call Trace:
Dec 21 19:47:45 localhost kernel: <IRQ>  [<ffffffff81069b77>] ? warn_slowpath_common+0x87/0xc0
Dec 21 19:47:45 localhost kernel: [<ffffffff81069c66>] ? warn_slowpath_fmt+0x46/0x50
Dec 21 19:47:45 localhost kernel: [<ffffffff8144a54d>] ? dev_watchdog+0x26d/0x280
Dec 21 19:47:45 localhost kernel: [<ffffffff8144a2e0>] ? dev_watchdog+0x0/0x280
Dec 21 19:47:45 localhost kernel: [<ffffffff8107c957>] ? run_timer_softirq+0x197/0x340
Dec 21 19:47:45 localhost kernel: [<ffffffff810a0b70>] ? tick_sched_timer+0x0/0xc0
Dec 21 19:47:45 localhost kernel: [<ffffffff8102ad2d>] ? lapic_next_event+0x1d/0x30
Dec 21 19:47:45 localhost kernel: [<ffffffff81072161>] ? __do_softirq+0xc1/0x1d0
Dec 21 19:47:45 localhost kernel: [<ffffffff81095770>] ? hrtimer_interrupt+0x140/0x250
Dec 21 19:47:45 localhost kernel: [<ffffffff8100c24c>] ? call_softirq+0x1c/0x30
Dec 21 19:47:45 localhost kernel: [<ffffffff8100de85>] ? do_softirq+0x65/0xa0
Dec 21 19:47:45 localhost kernel: [<ffffffff81071f45>] ? irq_exit+0x85/0x90
Dec 21 19:47:45 localhost kernel: [<ffffffff814f4de0>] ? smp_apic_timer_interrupt+0x70/0x9b
Dec 21 19:47:45 localhost kernel: [<ffffffff8100bc13>] ? apic_timer_interrupt+0x13/0x20
Dec 21 19:47:45 localhost kernel: <EOI>  [<ffffffff810375ab>] ? native_safe_halt+0xb/0x10
Dec 21 19:47:45 localhost kernel: [<ffffffff810145dd>] ? default_idle+0x4d/0xb0
Dec 21 19:47:45 localhost kernel: [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110
Dec 21 19:47:45 localhost kernel: [<ffffffff814d411a>] ? rest_init+0x7a/0x80
Dec 21 19:47:45 localhost kernel: [<ffffffff81c1ff76>] ? start_kernel+0x424/0x430
Dec 21 19:47:45 localhost kernel: [<ffffffff81c1f33a>] ? x86_64_start_reservations+0x125/0x129
Dec 21 19:47:45 localhost kernel: [<ffffffff81c1f438>] ? x86_64_start_kernel+0xfa/0x109
Dec 21 19:47:45 localhost kernel: ---[ end trace 1c035fe603219926 ]---
Dec 21 19:47:45 localhost kernel: e1000e 0000:03:00.0: eth0: Reset adapter
Dec 21 19:47:46 localhost abrt-dump-oops: Reported 1 kernel oopses to Abrt
Dec 21 19:47:46 localhost abrtd: Directory 'oops-2012-12-21-19:47:46-12170-0' creation detected
Dec 21 19:47:47 localhost abrtd: Can't open file '/var/spool/abrt/oops-2012-12-21-19:47:46-12170-0/uid': No such file or directory
Dec 21 19:47:54 localhost kernel: Bridge firewalling registered
Dec 21 19:49:05 localhost abrtd: Sending an email...
Dec 21 19:49:05 localhost abrtd: Email was sent to: root@localhost
Dec 21 19:49:05 localhost abrtd: New problem directory /var/spool/abrt/oops-2012-12-21-19:47:46-12170-0, processing
Dec 21 19:49:05 localhost abrtd: Can't open file '/var/spool/abrt/oops-2012-12-21-19:47:46-12170-0/uid': No such file or directory

Parece que um hardware chamado KGP (M) E-D16 parou ou algo assim. Olhando para o google mostra que é a placa-mãe.

O que mais devo verificar? Eu já relatei isso para fdcservers.net.

Eles alegaram que é um bug do kernel. Em vez de problema de hardware. Qual bug do kernel? Por que isso faz com que o servidor trave? O que devo fazer?

Verificando o driver da placa de rede, recebi este

root@host [/var/log]# ethtool -i eth0
driver: e1000e
version: 1.9.5-k
firmware-version: 1.8-0
bus-info: 0000:03:00.0
root@host [/var/log]# ethtool -i eth1
driver: e1000e
version: 1.9.5-k
firmware-version: 1.8-0
bus-info: 0000:02:00.0
root@host [/var/log]# ethtool -i eth2
Cannot get driver information: No such device

Dito isto,

Nome do hardware: KGP (M) E-D16 é a placa mãe asus. Além disso, se você pesquisar o nome do hardware: KGP (M) E-D16 esta classificação de página no top 3.

    

Answer 1

O problema é como se afirma. Linha 261 de net/sched/sch_generic.c , que é uma rotina genérica do agendador de pacotes.

O próprio pânico está aqui

Dec 21 19:47:45 localhost kernel: [<ffffffff8144a54d>] ? dev_watchdog+0x26d/0x280

Assim, o dispositivo de rede atingiu o tempo limite. Como o código-fonte diz, algumas filas foram bloqueadas e o timer expirou. Era suposto que segurasse o dispositivo durante certo tempo particular mas o contador terminou. Aqui está a parte relevante do código.

if (!mod_timer(&dev->watchdog_timer,
258 round_jiffies(jiffies +
259 dev->watchdog_timeo)))
260 dev_hold(dev);

Você vê que há um temporizador de watchdog e o contador é medido em intervalos. Quando este temporizador acabou, ele lança um aviso.

Isso tem algo a ver com a sua placa de rede ou driver. Eu vou imediatamente rejeitar a teoria do bug do kernel, a menos que eles possam provar isso. E não há como avisar, a menos que alguém tenha informado o rastreamento de chamada exato ou a Intel saiba sobre esse rastreamento e isso acontece no mesmo hardware, mesmo driver, mesmo firmware. Em poucas palavras, sem verificar o dump do kernel ou vmcore, nenhuma pessoa experiente dirá que isso é um bug do kernel. A parte do kernel que lida com o timer, é cuidadosamente elaborada e o e1000 não é um driver obscuro para se lidar.

Eu não quero dissecar seus servidores, mas esta é a minha opinião. Vale a pena conferir suas saídas ethtool -S ethX para ver se há alguma queda, excesso, timeouts, etc.