This is the log messages : Jul 12 04:02:01 ftclient1 anacron[10557]: Updated timestamp for job `cron.daily' to 2000-07-12 Jul 12 04:02:03 ftclient1 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Jul 12 04:02:03 ftclient1 kernel: current->tss.cr3 = 06f9e000, %cr3 = 06f9e000 Jul 12 04:02:03 ftclient1 kernel: *pde = 00000000 Jul 12 04:02:03 ftclient1 kernel: Oops: 0002 Jul 12 04:02:03 ftclient1 kernel: CPU: 0 Jul 12 04:02:03 ftclient1 kernel: EIP: 0010:[truncate_inode_pages+72/239] Jul 12 04:02:03 ftclient1 kernel: EFLAGS: 00010206 Jul 12 04:02:03 ftclient1 kernel: eax: 00000000 ebx: c4eb55b8 ecx: 00000014 edx: c0337740 Jul 12 04:02:03 ftclient1 kernel: esi: c4eb5540 edi: 0000041a ebp: c4eb55b8 esp: c6f9de88 Jul 12 04:02:03 ftclient1 kernel: ds: 0018 es: 0018 ss: 0018 Jul 12 04:02:03 ftclient1 kernel: Process slocate (pid: 10694, process nr: 55, stackpage=c6f9d000) Jul 12 04:02:03 ftclient1 kernel: Stack: 0000041a 00000fff c0131154 c4eb5540 00000000 c479f548 c01311c6 c4eb5540 Jul 12 04:02:03 ftclient1 kernel: c6f9dedc c6f9dedc c021a204 c013142d c6f9dedc 00000000 c024c630 c021a204 Jul 12 04:02:03 ftclient1 kernel: c024c630 00000000 c6f9df08 00000000 00000000 c482cee8 c4f76778 c0131471 Jul 12 04:02:03 ftclient1 kernel: Call Trace: [clear_inode+19/111] [dispose_list+22/76] [try_to_free_inodes+217/253] [grow_inodes+26/351] [get_new_inode+185/278] [iget+88/96] [ext2_lookup+84/123] Jul 12 04:02:03 ftclient1 kernel: [real_lookup+79/154] [lookup_dentry+291/481] [__namei+40/87] [sys_newlstat+14/95] [system_call+52/56] [startup_32+43/285] Jul 12 04:02:03 ftclient1 kernel: Code: 89 41 04 c7 02 00 00 00 00 c7 42 04 00 00 00 00 8b 4a 20 85
No matter what slocate is doing, it shouldn't cause a kernel oops; reassigning to kernel.
Perhaps these informations will help you. on this machine we have two PPP connections one named ppp0 and the other one ppp1, in the options we have NODEFAULTROUTE with PAP protocol. Then, we make every 5 minutes an addroute default to ppp0 then we delete it. we make a default route to PPP1 and then we delete it. This kernel panic was done when the ppp0 or ppp1 was killed because the connection was loss. When we verify if the connection is loss we del the default route manually, because this route was not del automatically. This night we had excactly the same problem at the same time but we had stop slocate two days before this new crash.
Hello, I have a second kernel panic when I make the command route : Jul 25 14:12:56 ftclient1 pppd[677]: Connection terminated. Jul 25 14:12:56 ftclient1 pppd[677]: Connect time 3.9 minutes. Jul 25 14:12:56 ftclient1 pppd[677]: Sent 3388 bytes, received 735 bytes. Jul 25 14:12:57 ftclient1 pppd[677]: Exit. Jul 25 14:14:39 ftclient1 kernel: Unable to handle kernel paging request at virtual address ffffffff Jul 25 14:14:39 ftclient1 kernel: current->tss.cr3 = 05e69000, %cr3 = 05e69000 Jul 25 14:14:39 ftclient1 kernel: *pde = 00000000 Jul 25 14:14:39 ftclient1 kernel: Oops: 0000 Jul 25 14:14:39 ftclient1 kernel: CPU: 0 Jul 25 14:14:39 ftclient1 kernel: EIP: 0010:[<ffffffff>] Jul 25 14:14:39 ftclient1 kernel: EFLAGS: 00010246 Jul 25 14:14:39 ftclient1 kernel: eax: 00000000 ebx: c674bce0 ecx: 00000000 edx: c0229278 Jul 25 14:14:39 ftclient1 kernel: esi: c674bce0 edi: c7fbc210 ebp: 00000000 esp: c5e57e84 Jul 25 14:14:39 ftclient1 kernel: ds: 0018 es: 0018 ss: 0018 Jul 25 14:14:39 ftclient1 kernel: Process route (pid: 1098, process nr: 32, stackpage=c5e57000) Jul 25 14:14:39 ftclient1 kernel: Stack: c5e57ecc c5e57f3c c674bd40 00000001 c674bd10 00000000 00000000 c01747ac Jul 25 14:14:39 ftclient1 kernel: c7fbc210 c5e57edc c5e57f3c c5e57ecc 00000000 0000890c c6569a10 bffffba4 Jul 25 14:14:39 ftclient1 kernel: c014cf08 c5e57ecc 0000001c 00000019 00000000 00000000 00000000 01ff0000 Jul 25 14:14:39 ftclient1 kernel: Call Trace: [ip_rt_ioctl+292/344] [sock_ioctl+0/32] [inet_ioctl+339/524] [sock_ioctl+26/32] [sys_ioctl+414/452] [system_call+52/56] Jul 25 14:14:39 ftclient1 kernel: Code: Bad EIP value. This kernel panic was done with the last kernel : 2.2.16-3 in redhat 6.2 Bye.
Please run a memory tester on that box firstly
It was a problem with the RAM.