Mensagem estranha no log Pid: 0, comm: swapper Not tainted 2.6.32-5 [RESOLVIDO]

ferrarezux
(usa Debian)

Enviado em 28/08/2012 - 15:29h

Caros colegas, primeira vez que peço ajuda à comunidade. Estou num beco sem saída com um servidor samba.
Peço que me ajudem pois esse problema pode ocorrer com outros colegas da comunidade também.
Depois de alguns meses configurar um servidor samba em um escritório estou recebendo algumas mensagens estranhas em /var/log/messages.
Aparece a mensagem abaixo e a performance da máquina cai 96%.
Fazendo algumas pesquisas em sites em ingles, parece se tratar de problemas de hardware, mas com as ferramentas de diagnóstico que usei não consegui encontrar nada de errado com o hardware.
Desconfio do HD onde está montada a raiz (/), que é antigo. Fora esse HD tenho mais 4 em raid 6, mas são novos e o mdadm sai conforme log abaixo.
Outra desconfiança é sobre a própria placa mãe da máquina estar com defeito, pois a placa de rede é nova, e o motivo da troca da placa de rede anterior foi justamente esse problema e continua do mesmo jeito.
Algum palpite???:

Segue: /var/log/messages

Aug 28 13:55:47 srvsmb kernel: [ 8238.871304] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1
Aug 28 13:55:47 srvsmb kernel: [ 8238.871307] Call Trace:
Aug 28 13:55:47 srvsmb kernel: [ 8238.871309] <IRQ> [<ffffffff81095da1>] ? __report_bad_irq+0x30/0x7d
Aug 28 13:55:47 srvsmb kernel: [ 8238.871321] [<ffffffff81095ef3>] ? note_interrupt+0x105/0x16e
Aug 28 13:55:47 srvsmb kernel: [ 8238.871325] [<ffffffff81096558>] ? handle_fasteoi_irq+0x93/0xb5
Aug 28 13:55:47 srvsmb kernel: [ 8238.871330] [<ffffffff8101327f>] ? handle_irq+0x17/0x1d
Aug 28 13:55:47 srvsmb kernel: [ 8238.871333] [<ffffffff810128d9>] ? do_IRQ+0x57/0xb6
Aug 28 13:55:47 srvsmb kernel: [ 8238.871337] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
Aug 28 13:55:47 srvsmb kernel: [ 8238.871339] <EOI> [<ffffffffa01de651>] ? acpi_idle_enter_simple+0x116/0x148 [processor]
Aug 28 13:55:47 srvsmb kernel: [ 8238.871357] [<ffffffffa01de64a>] ? acpi_idle_enter_simple+0x10f/0x148 [processor]
Aug 28 13:55:47 srvsmb kernel: [ 8238.871363] [<ffffffff8123a2c6>] ? cpuidle_idle_call+0x94/0xee
Aug 28 13:55:47 srvsmb kernel: [ 8238.871368] [<ffffffff8100fe97>] ? cpu_idle+0xa2/0xda
Aug 28 13:55:47 srvsmb kernel: [ 8238.871372] [<ffffffff8151c140>] ? early_idt_handler+0x0/0x71
Aug 28 13:55:47 srvsmb kernel: [ 8238.871376] [<ffffffff8151ccdd>] ? start_kernel+0x3dc/0x3e8
Aug 28 13:55:47 srvsmb kernel: [ 8238.871380] [<ffffffff8151c3b7>] ? x86_64_start_kernel+0xf9/0x106

Segue: mdadm /dev/md0

root@srvsmb:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sat Aug 25 12:16:31 2012
Raid Level : raid6
Array Size : 976765952 (931.52 GiB 1000.21 GB)
Used Dev Size : 488382976 (465.76 GiB 500.10 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent

Update Time : Tue Aug 28 14:21:13 2012
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : srvsmb:0 (local to host srvsmb)
UUID : ed13dcc4:e75bab23:6be26db8:d1bf5906
Events : 72

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 65 3 active sync /dev/sde1


Segue: cat /proc/interrupts (depois do travamento)

root@srvsmb:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 48 0 0 0 IO-APIC-edge timer
1: 2 0 0 0 IO-APIC-edge i8042
8: 1 0 0 0 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 9 0 0 0 IO-APIC-edge i8042
16: 0 0 0 0 IO-APIC-fasteoi nouveau
17: 6530 0 0 0 IO-APIC-fasteoi pata_via, HDA Intel
18: 600001 0 0 0 IO-APIC-fasteoi eth0
19: 0 0 0 0 IO-APIC-fasteoi xhci_hcd:usb1
20: 725 0 0 0 IO-APIC-fasteoi ata_piix, ata_piix
23: 89 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, ehci_hcd:usb3
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 28313 13226 9662 7119 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
PND: 0 0 0 0 Performance pending work
RES: 1425 888 352 150 Rescheduling interrupts
CAL: 27 76 89 88 Function call interrupts
TLB: 117 355 209 75 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 7 7 7 7 Machine check polls
ERR: 0
MIS: 0

ferrarezux
(usa Debian)

Enviado em 28/08/2012 - 15:31h

PS: Já rodei os utilitários memtest e badblocks e não deu nada.

removido
(usa Nenhuma)

Enviado em 28/08/2012 - 18:51h

As mensagens parecem ser de algum erro de IRQ(pensei que não veria mais isso), mas não tenho certeza se é algum conflito de hardware.

Qual é a sua placa de rede? poderia postar as configurações de hardware(CPU/RAM/Fonte).




Notou se isso ocorre em alguma situação especifica(acesso a determinados arquivos, muitos usuários acessando o servidor, algum processo consumindo muitos recursos de CPU...) ou acontece independentemente de uso do servidor.


Se desconfia de um dos discos, baixe o smartmontools e verifique com o smartctl:
http://www.hardware.com.br/livros/ferramentas-linux/monitorando-saude-com-smart.html

Você pode verificar também a temperatura(CPU e demais sensores que forem reconhecidos)com:
http://www.hardware.com.br/guias/debian-desktops/monitorando-lmsensors.html

No caso de ser apenas conflito de IRQ mesmo, se for possível, experimente trocar a placa de rede de slot(os problemas começaram com a placa antiga e esta nova certo?).
E caso o seu servidor possua, desabilite dispositivos não usados(serial, paralela,rede onboard, IDE etc...). O parâmetro irqpoll(ao kernel na inicialização, também pode ser útil).

ferrarezux
(usa Debian)

Enviado em 29/08/2012 - 10:07h

Olá, obrigado pela resposta.

Eu acho estranho aparecer um erro de IRQ, pois a máquina já estava a meses funcionando sem problemas, e nenhuma modificação de hardware foi feita antes do problema aparecer.

Minha placa de rede é uma Mymax com chip RTL8139C;
Processador é um core i5-2300 CPU @ 2.80GHz;
+ 8GB de RAM DDR3;
A fonte é uma fonte de 500W reais.

Eu anotei os horários que o erro acontece, são horários em que a máquina fica ociosa, e analizando os processos e consumo de recursos, quando o problema acontece a situação do sistema é mais pra recursos sem uso.

Depois de o problema aparecer, na BIOS eu já havia desativado tudo o que não está em uso, inclusive a rede on-board.
Referente a placa de rede eu estava usando a placa on-board, aí quando o problema apareceu coloquei a placa acima e desativei a on, mas mesmo assim vou trocar de slot agora e ver o que acontece, se não resolver vou usar as ferramentas de análise sugeridas e o irqpoll.

Também estou suspeitando de problemas com a rede elétrica. O nobreak foi trocado por um novo e bem maior, aqui tem muito pico de energia.

Vale falar que no fim de semana cheguei ao ponto de formatar a máquina, agora ela está rodando a ultima versão do Debian 64bits (6.0.5) e o problema continua...

ferrarezux
(usa Debian)

Enviado em 29/08/2012 - 11:42h

Agora sei que energia não é, foi adicionado um nobreak de 1400va dedicado para essa máquina. E o erro ocorreu logo em seguida.
Mudei o slot da placa de rede, se voltar a ocorrer só pode ser HD ou a própria placa mãe.

ferrarezux
(usa Debian)

Enviado em 29/08/2012 - 16:06h

erisrjr, parece que o erro se foi mudando o slot da placa de rede e substituindo o nobreak...
Agora a placa está no IRQ 16. Segue saída mostrando como ficou minha tabela de IRQs.
Bom... pelo menos até agora estou sem erro, desde 09:56 AM. O erro acontecia toda hora. Vamos ver se até amanhã estará assim.
Minha explicação é que só pode ter sido algo relacionado a pico de energia que "estragou" algo no slot que levava o IRQ 18 e também na saída da placa de rede on-board.


root@srvsmb:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 98 0 0 0 IO-APIC-edge timer
1: 8 0 0 0 IO-APIC-edge i8042
8: 1 0 0 0 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 135 0 0 0 IO-APIC-edge i8042
16: 1894792 0 0 0 IO-APIC-fasteoi nouveau, eth0
17: 21996 0 0 0 IO-APIC-fasteoi pata_via, HDA Intel
19: 0 0 0 0 IO-APIC-fasteoi xhci_hcd:usb1
20: 16277 0 0 0 IO-APIC-fasteoi ata_piix, ata_piix
23: 55 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, ehci_hcd:usb3
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 114781 85326 66057 98966 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
PND: 0 0 0 0 Performance pending work
RES: 5996 12370 6826 1152 Rescheduling interrupts
CAL: 25 67 79 79 Function call interrupts
TLB: 159 301 226 94 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 57 57 57 57 Machine check polls
ERR: 0
MIS: 0

removido
(usa Nenhuma)

Enviado em 29/08/2012 - 21:34h

Como diria o Prudente: "Vamos aguardar os acontecimentos"

Trabalho com manutenção a algum tempo e ja vi todo o tipo de coisa acontecer. Nesse caso, como você tem tido variações de energia, uma sobretensão pode ter "atingido" seu modem ou switch -> sua placa de rede onboard e afetado além dela o chip responsável pelo barramento PCI(o equipamento que esta conectado ao servidor esta no nobreak? sua rede possui aterramento?), porem nesse caso você deveria ter problemas em outros equipamentos na rede.

Houve casos onde alguns componentes "queimaram" ou passaram a funcionar de maneira errática após tempestades ou problemas na rede elétrica("curto" em tomadas, problemas em transformadores...). Tenho um computador aqui, que alem da rede onboard, "foram-se": portas Serial, PS2, áudio e as USB do painel traseiro da placa mãe(Junto com um switch).

Outra possibilidade, como você substituiu o nobreak(o anterior estava com algum defeito?), é ele ter causado o problema, fornecendo energia de forma incorreta ou mesmo danificando sua fonte de alimentação, o que pode lhe trazer problemas no futuro.
Tendo um pouco de conhecimento em eletrônica, pode-se fazer uma inspeção visual nos componente e verificar tenções de saída nos conectores com auxilio de um "multímetro".

Se houver disponibilidade, mesmo com este problema resolvido, investigue a origem para evitar futuras "dores de cabeça".

Até.

ferrarezux
(usa Debian)

Enviado em 30/08/2012 - 17:25h

Ontem na parte da tarde voltou a ocorrer o erro. Não é o slot PCI.

Aqui é tudo no nobreak, a rede eletrica é extremamente ruim, modem, switch, roteador, clientes tudo tem nobreak.
Nesse bairro tem muita arvore, em Campo Grande tem muita arvore, mas nesse bairro tem arvore² (ao quadrado) rsrs, e nessa época do ano venta muito e a rede elétrica fica pirada. Hoje a cada 20/30 segundos os nobreaks estalam, hoje está sendo o pior dia do mês.
Mas finalmente acho que decobri quem era o vilão:

Esse servidor guarda arquivos importantes e é muito acessado, então montei ele em raid 6 com 4 HDs na /srv e o / ficava em um outo HD IDE pequeno. Foi esse HD IDE que ficou maluco.
Hoje de manhã fiz um clone da / para outro HD SATA. Está tudo normal até agora, isso indica que a PSU deve estar normal também.
O que aconteceu deve ter sido que o nobreak passou corrente errada pra fonte e ela repassou pro HD IDE que deve ter abrido o bico. Muito louco!

removido
(usa Nenhuma)

Enviado em 31/08/2012 - 12:43h

Ou como esse HD ja tem um tempo de uso/vida(HD IDE e pequeno) simplesmente chegou ao fim da vida útil. Ao rodar o smartctl neste HD, havia algum "erro"?
De todo o modo, se o problema voltar, de uma olhada na fonte ou a substitua, Como sua rede elétrica e instável, é interessante ter algumas de "reserva".

removido
(usa Nenhuma)

Enviado em 05/09/2012 - 23:23h

O que aconteceu após substituir a fonte? o erro voltou a ocorrer?

andrecanhadas
(usa Debian)

Enviado em 06/09/2012 - 00:11h

Tente editar o grub.conf e colocar o parametro:

acpi=noirq

 

Me parece algum problema com o ACPI ou conflito de IRQ.

Tente desativar o ACPI caso o primeiro não funcione (#acpi=off)

ferrarezux
(usa Debian)

Enviado em 06/09/2012 - 10:40h

Enviei essa máquina para uma assistencia técnica de hardhare, segundo eles não há problemas com o hardware.
Eu substitui apenas um HD, o HD da / , mas não adiantou.

Mas, olhando melhor na sída do dmesg vi que o erro de IRQ acontecia logo após um outro erro:

JBD: Barrier-based Sync Failed On md0-8 – Disabling Barriers

Pesquisando vi que isso está relacionado a uma política do sistema de arquivos ext4.
Eu já não gostava do ext4, então resolvi migrar de vez pra ext3 e a mensagem sumiu.
Coincidentemente ou não o erro não aconteceu ainda.