LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   CentOS release 4.6 (Final) - Kernel Oops (https://www.linuxquestions.org/questions/linux-server-73/centos-release-4-6-final-kernel-oops-628331/)

harry edwards 03-15-2008 07:12 PM

CentOS release 4.6 (Final) - Kernel Oops
 
A server of mine has recently been suffering a “Kernel Oops”. I have been using the following link to diagnose the problem http://users.sosdg.org/~qiyong/lxr/s...g.txt?v=2.6.16

If contains information on how to trace and log a “Kernel Oops” problem. I believe the ksysmoops utility in my case is useless, to quote the above link ‘NOTE: ksymoops is useless on 2.6.’; hence, I am stumped. I have emailed the address in the link; however, I though I'd post here as well.

The server in question is running the following:
Code:

home# uname -a

Linux <xyz> 2.6.9-55.0.9.ELsmp #1 SMP Thu Sep 27 18:27:41 EDT 2007 i686 i686 i386 GNU/Linux

home# cat /etc/redhat-release

CentOS release 4.6 (Final)

The Oops seems to occur at a random interval, but, has constant detail in the report:

Code:

home# tail -n80000 /var/log/messages  | grep  "Oops"

Mar 10 19:15:58 home kernel: Oops: 0000 [#1]
Mar 11 01:50:33 home kernel: Oops: 0000 [#1]
Mar 12 10:44:38 home kernel: Oops: 0000 [#1]
Mar 15 00:58:24 home kernel: Oops: 0000 [#1]

The detail obtained so far is:

Code:

Unable to handle kernel paging request at virtual address 00100100

printing eip:
c011e7ea
*pde = 3584d001
Oops: 0000 [#1]
SMP

Modules linked in: loop ipt_owner parport_pc lp parport autofs4 md5 ipv6 ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables button battery ac tg3 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod cciss sd_mod scsi_mod

CPU:    1
EIP:    0060:[<c011e7ea>]    Not tainted VLI
EFLAGS: 00010046  (2.6.9-55.0.9.ELsmp)
EIP is at __wake_up_common+0x13/0x51
eax: 00000000  ebx: e964500c  ecx: c282dde0  edx: 00100100
esi: 00000000  edi: f3fb5118  ebp: c2b75f1c  esp: c2b75f04
ds: 007b  es: 007b  ss: 0068

Process authdaemond (pid: 2574, threadinfo=c2b75000 task=f59c4230)
Stack: 00000000 00100100 00000001 f3fb5118 00000000 00000000 c2b75f40 c011e851
      00000000 00000000 00000246 00000001 f3fb5118 f5fb7980 f2458c80 f7e0be00
      c027c767 00000000 f5fb7980 00000000 c02cecc9 00000001 f575f5a4 00000000

Call Trace:

 [<c011e851>] __wake_up+0x29/0x3c
 [<c027c767>] sock_def_wakeup+0x2e/0x3c
 [<c02cecc9>] unix_release_sock+0x118/0x209
 [<c0279676>] sock_release+0x11/0x85
 [<c027a0dd>] sock_close+0x26/0x2a
 [<c015c1b6>] __fput+0x55/0x100
 [<c015add0>] filp_close+0x59/0x5f
 [<c015ae31>] sys_close+0x5b/0x92
 [<c02d64db>] syscall_call+0x7/0xb

Code: 83 c4 1c 5b 5e 5f 5d e9 64 fb ff ff 55 89 e5 5d 8b 40 04 e9 8f e8 ff ff 55 89 e5 57 89 c7 56 89 ce 53 83 ec 0c 89 55 f0 8b 50 08 <8b> 02 89 45 ec 8d 47 08 39 c2 74 2a 8d 5a f4 8b 52 f4 8b 4d 08

 <0>Fatal exception: panic in 5 seconds


Any advice either on the correct way to report this or extra commands to run to obtain the reason or fix would be gratefully appreciated.

vwvr9 03-17-2008 04:11 AM

Have you tried downgrading your kernel?

harry edwards 03-17-2008 05:11 PM

I've tried the opposite. Originally the kernel version was lower and I still had the same problem, so I upgraded.


All times are GMT -5. The time now is 10:31 AM.