Bug 81061 - Unable to handle kernel paging request at virtual address 88d55d7c
Unable to handle kernel paging request at virtual address 88d55d7c
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-03 17:34 EST by Jongmin So
Modified: 2007-04-18 12:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-05 15:21:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jongmin So 2003-01-03 17:34:26 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
System hangs randomly. All services stop responding except Apache.

System log -
Jan  3 11:42:01 ibox kernel: Unable to handle kernel paging request at virtual
address 88d55d7c
Jan  3 11:42:01 ibox kernel:  printing eip:
Jan  3 11:42:01 ibox kernel: c0135800
Jan  3 11:42:01 ibox kernel: *pde = 00000000
Jan  3 11:42:01 ibox kernel: Oops: 0000
Jan  3 11:42:01 ibox kernel: ide-cd cdrom soundcore mousedev input autofs 3c59x
eepro100 iptable_filter ip_tables ext3 jbd  
Jan  3 11:42:01 ibox kernel: CPU:    0
Jan  3 11:42:01 ibox kernel: EIP:    0010:[<c0135800>]    Not tainted
Jan  3 11:42:01 ibox kernel: EFLAGS: 00010012
Jan  3 11:42:01 ibox kernel: 
Jan  3 11:42:01 ibox kernel: EIP is at __kmem_cache_alloc [kernel] 0x50
(2.4.18-19.8.0)
Jan  3 11:42:01 ibox kernel: eax: 6a555b59   ebx: 6a555b59   ecx: df7ff000  
edx: df7ff0a0
Jan  3 11:42:01 ibox kernel: esi: c25a6f84   edi: 00000246   ebp: 00000080  
esp: cf92beb8
Jan  3 11:42:01 ibox kernel: ds: 0018   es: 0018   ss: 0018
Jan  3 11:42:01 ibox kernel: Process python (pid: 14563, stackpage=cf92b000)
Jan  3 11:42:01 ibox kernel: Stack: 15a1d067 c14bb688 fffffff4 c25a03ec c25a0380
c259f1a0 c0154010 c25a6f84 
Jan  3 11:42:01 ibox kernel:        000001f0 00000007 fffffff4 c25a03ec c25a0380
c259f1a0 c014a8c1 c259f1a0 
Jan  3 11:42:01 ibox kernel:        cf92bf2c 00000000 dd71500d fffffdee cf92bf78
c014ae3f c259f1a0 cf92bf2c 
Jan  3 11:42:01 ibox kernel: Call Trace: [<c0154010>] d_alloc [kernel] 0x20
(0xcf92bed0))
Jan  3 11:42:01 ibox kernel: [<c014a8c1>] real_lookup [kernel] 0xb1 (0xcf92bef0))
Jan  3 11:42:01 ibox kernel: [<c014ae3f>] link_path_walk [kernel] 0x40f
(0xcf92bf0c))
Jan  3 11:42:01 ibox kernel: [<c014b429>] path_lookup [kernel] 0x39 (0xcf92bf4c))
Jan  3 11:42:01 ibox kernel: [<c014b9f7>] filp_open [kernel] 0x97 (0xcf92bf5c))
Jan  3 11:42:01 ibox kernel: [<c013f3f3>] sys_open [kernel] 0x53 (0xcf92bfa8))
Jan  3 11:42:01 ibox kernel: [<c0109127>] system_call [kernel] 0x33 (0xcf92bfc0))
Jan  3 11:42:01 ibox kernel: 
Jan  3 11:42:01 ibox kernel: 
Jan  3 11:42:01 ibox kernel: Code: 8b 44 81 18 0f af dd 89 41 14 01 d3 40 74 18
57 9d 89 d8 8b 

I won't be able to login, no ssh, no sendmail but oddly, httpd continues to work.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Let the system idles for 20-30 min. Sometimes it take more than a day to reproduce
2.It seems when no one is talking to the system, it goes to sleep? haha
3.need further information?
    

Actual Results:  Nothing runs!! Can't login, can't restart, can't do anything.
Should I go back to Windows?

Expected Results:  It should continue to run right?

Additional info:
Comment 1 Michael Lee Yohe 2003-01-03 17:57:26 EST
Is this an unmodified (hardware-wise) system, for example: non-overlocked?

Have you run memtest86 (Google for it)?
Comment 2 Michael Lee Yohe 2003-01-03 17:57:53 EST
Component == kernel
Comment 3 Jongmin So 2003-01-03 18:42:23 EST
No. Everything is running with their default values. No overclocking what so 
ever. But I haven't tried memtest86.
I am going to test it and let you know how it runs.
Thanks.
Comment 4 Jongmin So 2003-01-04 13:13:42 EST
memtest86 ran fine.
Now what?
Comment 5 Michael Lee Yohe 2003-01-06 10:57:40 EST
Hmm - that's strange.  Could you please attach the output of "lsmod" (shows the
modules that are currently loaded in the running kernel).  Also - provide "cat
/proc/pci".

This will show all the currently attached PCI devices that kernel has found. 
There definitely appears to be a driver conflict or a hardware problem - seeing
the configuration could be beneficial to Red Hat developers.
Comment 6 Alan Cox 2003-06-05 09:49:51 EDT
It certainly looks like a random corruption It would be good to know if this
still occurs with current errata kernel. 

Note You need to log in before you can comment on or make changes to this bug.