Problema de gravação journal

Caros,

Estou tendo uma dificuldade com o meu RED HAT 7.3, rodo neste linux o ORACLE 8i e por algumas vezes ele travou e no arquivo VAR/LOG/MESSAGES apareceu a seguinte mensagem antes do travamento:

-----------------------------------
Feb 7 15:37:19 WorkOra03 kernel: Assertion failure in journal_commit_transaction() at commit.c:535: "buffer_jdirty(b
h)"
Feb 7 15:37:19 WorkOra03 kernel: ------------[ cut here ]------------
Feb 7 15:37:19 WorkOra03 kernel: kernel BUG at commit.c:535!
Feb 7 15:37:19 WorkOra03 kernel: invalid operand: 0000
Feb 7 15:37:19 WorkOra03 kernel: autofs eepro100 st usb-uhci usbcore ext3 jbd aacraid aic7xxx sd_mod scsi_mod
Feb 7 15:37:19 WorkOra03 kernel: CPU: 3
Feb 7 15:37:19 WorkOra03 kernel: EIP: 0010:[<f88610e4>] Not tainted
Feb 7 15:37:19 WorkOra03 kernel: EFLAGS: 00010286
Feb 7 15:37:19 WorkOra03 kernel:
Feb 7 15:37:19 WorkOra03 kernel: EIP is at journal_commit_transaction [jbd] 0xb04 (2.4.18-3smp)
Feb 7 15:37:19 WorkOra03 kernel: eax: 0000001c ebx: 0000000a ecx: c02eee60 edx: 000055be
Feb 7 15:37:19 WorkOra03 kernel: esi: f5963e20 edi: d44b4320 ebp: f680a000 esp: f680be78
Feb 7 15:37:19 WorkOra03 kernel: ds: 0018 es: 0018 ss: 0018
Feb 7 15:37:19 WorkOra03 kernel: Process kjournald (pid: 263, stackpage=f680b000)
-----------------------------------------

Pesquisei em alguns sites e a maioria fala que é BUG de KERNEL na gravação do JOURNAL.

Agora fica a duvida, este bug é por causa do ORACLE 8i ou é BUG do meu LINUX e o que posso fazer para corrigi-lo.


Muito obrigado a todos!!

ali diz claramente que é um "kernel" bug..

"Feb 7 15:37:19 WorkOra03 kernel: ------------[ cut here ]------------
Feb 7 15:37:19 WorkOra03 kernel: kernel BUG at commit.c:535!
Feb 7 15:37:19 WorkOra03 kernel: invalid operand: 0000
"

contudo (minha opinião, claro) quem está dizendo isso é um aplicativo do Oracle..

como refere-se ao "commit" - pelo que se lê, claro - eu verificaria TAMBÉM a atuação do Oracle, mas isso pode ser complicado.

Qual o fs que vc usa? eu tive problemas (não com Oracle, não uso) com o reiserfs, há algum tempo. Coisa simples: apenas perdeu tudo, de maneira irrecuperável ;)

bem.. em relendo eu concluo que não apenas não ajudei em coisa alguma como ainda consegui confundir as coisas. Coisas da vida.

Divirta-se.

Obrigado amigo!!

Mas ja verifiquei toda a configuração do oracle!!!
Mas ocorreu de travar o servidor sem ter ninguem acessando o banco (a noite).

O que estou achando estranho é que tenho um outro servidor com Red Hat 7.2 que suporta 3x mais dados que o que esta com o Red Hat 7.3.
Ja falaram em outros foruns que este problema é de Kernel e eu teria q atualizar o Kernel, mas o meu ORACLE 8i não é suportado pelo Kernel mais atual!!!!

[]s
Regis Araujo

bem.. a maior parte do trabalho vc já fez, que é examinar a fundo o oracle. Resta o kernel. Se vc tem (/usr/src/linux) o anterior, então vc pode baixar o kernel mais novo (2.19.2, salvo engano) e TENTAR recompilar.. afinal, já tá tudo lascado mesmo, o q vc vai perder? algum tempo, não?

então, faça assim:

baixe e expanda o novo kernel, faça o link simbólico como é normal, MASSSS... depois copie o .config do antigo kernel para cá (o novo) e:

make oldconfig

será lido o seu antigo e vc vai ter que acertar um que outro detalhe para o novo kernel. Depois:

make && make modules modules_install install

atenção: o install vai usar o que vc tiver no /boot sob nome vmlinuz, então convém vc fazer uma alteração no lilo para usar (por exemplo):

vmlinuz-configvelho (default)
vmlinuz (teste)

se NÃO funcionar, vc ainda pode tentar usar o .config do outro servidor, até diretamente, se forem iguais (oldconfig, etc). Se não forem - vai que é um AMD lá e um Lentium aqui? - ANTES dos "make" vc fará um "make menuconfig", para alterar diretamente o modêlo de máquina.

Eu acho que já no primeiro vc vai correr pro abraço. Divirta-se :)