Bug 13773
Summary: | Kernel panic in redhat 6.2 with slocate-2.1-2.i386.rpm | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Nicolas CROISET <ncroiset> |
Component: | kernel | Assignee: | Michael K. Johnson <johnsonm> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 1.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-08-22 16:25:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Nicolas CROISET
2000-07-12 09:10:06 UTC
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. |