Bug 14864
| Summary: | OOPS - Unable to handle kernel paging request | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Richard Ames <richard> |
| Component: | kernel | Assignee: | Alan Cox <alan> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2 | CC: | fpotter, trev |
| 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-10-30 20:28:39 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
Richard Ames
2000-07-31 00:25:33 UTC
I encountered the same bug under the same conditions.
During the cron.daily ( 'locate' script) my kernel reported the following
error.
Then the system started to misbehave (process freezing, inetd malfunction
etc...). I had to reboot the system to recover normal operations.
about 15 days of uptime before it occured.
This Kernel supports an Intelligent Network Peripheral in a TELCO network in
France. This 'strange' and 'step-by step' kernel failure resulted in a
function outage on that network. Any news & feedback appreciated.
Thanks for your help
Fred
Sep 3 04:02:14 ss7orleans kernel: Unable to handle kernel paging request at vir
tual address c924ddd0
Sep 3 04:02:14 ss7orleans kernel: current->tss.cr3 = 0457d000, %cr3 = 0457d000
Sep 3 04:02:14 ss7orleans kernel: *pde = 00000000
Sep 3 04:02:14 ss7orleans kernel: Oops: 0002
Sep 3 04:02:14 ss7orleans kernel: CPU: 0
Sep 3 04:02:14 ss7orleans kernel: EIP: 0010:[prune_dcache+126/300]
Sep 3 04:02:14 ss7orleans kernel: EFLAGS: 00010286
Sep 3 04:02:14 ss7orleans kernel: eax: c124ddd0 ebx: c3ceec80 ecx: c924ddd0
edx: c3ceec98
Sep 3 04:02:14 ss7orleans kernel: esi: c3ceec60 edi: c124ddc0 ebp: 00000873
esp: c4fc7e8c
Sep 3 04:02:14 ss7orleans kernel: ds: 0018 es: 0018 ss: 0018
Sep 3 04:02:14 ss7orleans kernel: Process slocate (pid: 25956, process nr: 106,
stackpage=c4fc7000)
Sep 3 04:02:14 ss7orleans kernel: Stack: c0254a04 00001006 c4fc7ecc 00000000 00
001006 c0135308 fffff86d 00001006
Sep 3 04:02:14 ss7orleans kernel: 00000000 c0283720 c0254a04 c0283720 c4
3cdba0 c7097210 c709725c 00000000
Sep 3 04:02:14 ss7orleans kernel: c4fc7ecc c4fc7ecc c0135396 00001006 00
000000 c0283720 c0254a04 c0283720
Sep 3 04:02:14 ss7orleans kernel: Call Trace: [try_to_free_inodes+316/396] [gro
w_inodes+30/440] [get_new_inode+182/300] [get_new_inode+197/300] [iget+112/120]
[ext2_lookup+84/124] [real_lookup+80/160]
Sep 3 04:02:14 ss7orleans kernel: [lookup_dentry+296/488] [__namei+40/88
] [sys_newlstat+42/140] [system_call+52/56] [startup_32+43/164]
Sep 3 04:02:14 ss7orleans kernel: Code: 89 01 89 56 38 89 56 3c 83 7f 1c 01 0f
94 c0 31 c9 88 c1 89
Can you run memtest86 on the hardware and check the ram passes. A lot of these problems seem to be hardware (bad ram or psu underpowered and very high disk load) - but not all... We ran memtest86 on this box for a full weekend (2xx passes) in the middle of August. No faults. As of last Wednesday the problem was still occuring, interval from about 2 days to a week. The start of the issue was after the machine was powered down by pulling the plug from the wall :-) so we suspect some kind of hardware fault or SW / disk corruption. As it always says 'kernel paging' we decided to change the swap file... We had a 600+ megabyte partition as swap (too big, config mistake), bad block scan said the partition was OK. Anyway, we now have a 16 mbyte file as swap... and we are waiting for developments. We are willing to do your bidding to help correct this..... +Can you run memtest86 on the hardware and check the ram passes. A lot of these +problems seem to be hardware (bad ram or psu underpowered and very high disk +load) - but not all... I agree with you. Some of those problems seem to be hardware. In fact, the computer ran kernel 2.0.36 for like 'one year' before being update to 2.2.16 whithout any problems. After 15 days of 2.2.16 it then crashed like previously described. I don't suspect it is an hardware issue. fred Since changing the swap file on 16 September (see above), this crash has not happened again...... so that may lead one to suspect swap file corruption ????? Richard. I'm experiencing a similar problem, crashing every 2 to 10 days, and those names slocate and kswapd are very framilar in these Oops problems. I've commented on Bug #2005 about the problem. However, I have repartitioned and reformatted the harddrive in an attempt to clean up teh problem, but haven't had any luck. My swap partition is 128 MB and usually there's about 2 MB of that used at any given time. The system is a Pentium 150 with 48 MB Ram installed -- I read somewhere that one user fixed this exact problem by recompiling the kernel without CONFIG_APM disabled.. could that have anything to do with it? Right now I've got the kernel that ships with RH 6.2. Woops, Bug #20005 System has been running now for about 9 months without a reapperance of the\is problem .... |