Unable to handle kernel paging request at virtual address
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Unable to handle kernel paging request at virtual address
I just converted my server from Redhat 9 to Gentoo and upgraded the motherboard, cpu and memory (Asus A7V600-X, AMD +3200 xp, 2 sticks of Kingston KVR400X64C3A 512mb DIMMs). I'm running a 2.6.7 kernel, 2.6.7-hardened-r16. The system is hanging with the above error whenever there is a lot of disk activity like a large copy. The copy hangs and any subsequent commands like ls in that same directory hang as well. These hung commands can't be killed even with -9. Shutdown hangs as well as soon as it gets to that file system to try and umount. Hard reboot is the only way to get out of it. The system has been running since Monday and so far I have't seen any other signs of instability other than this one, which is a fairly big one. The rest of the hardware in this system, LSI and Adaptec scsi cards, Intel nic, old ATI Mach64 vid card, where working fine with the old motherboard running Redhat 9 with a 2.4 kernel. Anybody having this same problem or know of a solution? I would be most grateful for any help. Here is the error message with kernel debugging turned on:
Code:
Dec 15 14:26:48 blah kernel: Unable to handle kernel paging request at virtual address 54cb1214
Dec 15 14:26:48 blah kernel: printing eip:
Dec 15 14:26:48 blah kernel: c02d50e3
Dec 15 14:26:48 blah kernel: *pde = 00000000
Dec 15 14:26:48 blah kernel: Oops: 0000 [#2]
Dec 15 14:26:48 blah kernel: DEBUG_PAGEALLOC
Dec 15 14:26:48 blah kernel: CPU: 0
Dec 15 14:26:48 blah kernel: EIP: 0060:[<c02d50e3>] Not tainted
Dec 15 14:26:48 blah kernel: EFLAGS: 00010082 (2.6.7-hardened-r16)
Dec 15 14:26:48 blah kernel: EIP is at radix_tree_delete+0x23/0x190
Dec 15 14:26:48 blah kernel: eax: c7b33f6c ebx: c12a93a0 ecx: c7b33f68 edx: 00000000
Dec 15 14:26:48 blah kernel: esi: 0000047b edi: d418bb6c ebp: 652c2bbd esp: d418bb54
Dec 15 14:26:48 blah kernel: ds: 007b es: 007b ss: 0068
Dec 15 14:26:48 blah kernel: Process cp (pid: 3083, threadinfo=d418a000 task=ddb6fa80)
Dec 15 14:26:48 blah kernel: Stack: c023fb30 f7fd5f38 00000002 00000000 d418bb90 00008208 00000000 c6e29f74
Dec 15 14:26:48 blah kernel: f7ffd7e0 eb4feee4 eb4feef0 00000002 e63b3ee4 e63b3fa0 0000002e e0921ee4
Dec 15 14:26:48 blah kernel: e0921f30 00000012 00000001 c144c740 c1107120 c165e760 00000001 c1572f80
Dec 15 14:26:48 blah kernel: Call Trace:
Dec 15 14:26:48 blah kernel: [<c023fb30>] free_buffer_head+0x20/0x40
Dec 15 14:26:48 blah kernel: [<c02774f1>] ext3_releasepage+0x41/0x80
Dec 15 14:26:48 blah kernel: [<c021d5e4>] __remove_from_page_cache+0x24/0x50
Dec 15 14:26:48 blah kernel: [<c0229e0d>] shrink_list+0x2dd/0x410
Dec 15 14:26:48 blah kernel: [<c022a06b>] shrink_cache+0x12b/0x2b0
Dec 15 14:26:48 blah kernel: [<c0279610>] ext3_mark_inode_dirty+0x50/0x60
Dec 15 14:26:48 blah kernel: [<c022a6a9>] shrink_zone+0x89/0xd0
Dec 15 14:26:48 blah kernel: [<c022a743>] shrink_caches+0x53/0x60
Dec 15 14:26:48 blah kernel: [<c022a7f0>] try_to_free_pages+0xa0/0x170
Dec 15 14:26:48 blah kernel: [<c0221a66>] __alloc_pages+0x1c6/0x380
Dec 15 14:26:48 blah kernel: [<c0252d97>] inode_update_time+0xa7/0xe0
Dec 15 14:26:48 blah kernel: [<c021f79f>] generic_file_aio_write_nolock+0x2cf/0xa80
Dec 15 14:26:48 blah kernel: [<c0252ca2>] update_atime+0x92/0xe0
Dec 15 14:26:48 blah kernel: [<c021e68e>] __generic_file_aio_read+0x1ae/0x1e0
Dec 15 14:26:48 blah kernel: [<c0220067>] generic_file_aio_write+0x77/0xa0
Dec 15 14:26:48 blah kernel: [<c02741e4>] ext3_file_write+0x44/0xe0
Dec 15 14:26:48 blah kernel: [<c023b15b>] do_sync_write+0x8b/0xc0
Dec 15 14:26:48 blah kernel: [<c021146f>] do_timer+0xdf/0xf0
Dec 15 14:26:48 blah kernel: [<c020d5fd>] __do_softirq+0x7d/0x80
Dec 15 14:26:48 blah kernel: [<c01f7a75>] do_IRQ+0xd5/0x110
Dec 15 14:26:48 blah kernel: [<c0206a0f>] recalc_task_prio+0x8f/0x190
Dec 15 14:26:48 blah kernel: [<c023b0d0>] do_sync_write+0x0/0xc0
Dec 15 14:26:48 blah kernel: [<c023b248>] vfs_write+0xb8/0x130
Dec 15 14:26:48 blah kernel: [<c023b372>] sys_write+0x42/0x70
Dec 15 14:26:48 blah kernel: [<c01f4ef7>] syscall_call+0x7/0xb
Dec 15 14:26:48 blah kernel:
Dec 15 14:26:48 blah kernel: Code: 3b 34 ad 20 63 1a c0 0f 87 34 01 00 00 8d 44 6d 00 c7 44 24
lspci:
Code:
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:0c.0 VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX] (rev 03)
0000:00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
0000:00:0e.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800 South]
0000:00:13.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
0000:02:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05)
0000:02:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05)
I cannot help you as I am suffering heavily from the same problem. I run Mandrake 10.1 Official on a laptop and I am unable to operate the computer very long at all before I get a kernel paging request fault and the system becomes virtually unusable. My question to you concerns virtual memory addresses. For my system, the initial kernel paging request failure at <address> is not generally the same from fault to fault but the virtual memory hex address that follows is ALWAYS within a short span of memory addresses (01294xx). Do you see something similar? I am refering to the first virtual address indicating where the kernel paging request failed vs the next associated "virtual" address that follows:
Unable to handle kernel paging request at virtual address <some hex address that varies from fault to fault>
printing eip:
0x12942f <--- this is ALWAYS an address from the same short address space (1294xx).
I am trying to determine if this problem is hardware or software. I have run memtest86+ on my system and found not a single memory/cache error after more than 10 hours of testing. I have burned and run the disk diagnostic tests from the Ultimate Boot CD (available online, I highly recommend it - it is free) and it finds no problems with my harddrive so I can't state that my problem is a bad sector in my swap partition. I don't know what the problem is but it is a recent problem and doesn't affect my desktop system running the same software/system at all.
For my system, the initial kernel paging request failure at <address> is not generally the same from fault to fault but the virtual memory hex address that follows is ALWAYS within a short span of memory addresses (01294xx). Do you see something similar?
Wow, somebody does read the posts on this forum. I had given up. Anyway, here are the addresses from most of my crashes:
Some are the same, most aren't but they are all somewhat close. My problem turned out to be the memory. Replacing my shitty Kingston ram with Crucial completely fixed the problem. I was an idiot for picking ram off of Asus's recommended list rather than going with what I knew to be good; Crucial. Never again though. Regardless I think your problem is some sort of hardware conflict. And don't assume that just because memtest86+ didn't find anything wrong that your memory is ok. In searching for a solution I've read a few posts where people ran it and it still turned out to be the memory. Unfortunately the only way to know for sure is to spring for more and replace what you have. I did that and was planning on replacing the motherboard and cpu next if new ram hadn't fixed the problem. Luckily it did. Good luck, this shit can be a bitch.
No, Kingston ram is not shitty. I had that same problem on Linux and similar issues with windows. Kingston Ram needs the voltage increased from the stock 2.6 volts to 2.7 or even 2.8. Once that is done, Your system will run fine.
No, Kingston ram is not shitty. I had that same problem on Linux and similar issues with windows. Kingston Ram needs the voltage increased from the stock 2.6 volts to 2.7 or even 2.8. Once that is done, Your system will run fine.
I'm sure all Kingston ram is not bad or they wouldn't be able to sell any. In my case it was though. This is the only time I've ever bought other than Crucial ram for this server, which is on its 5th hardware upgrade. Never have I had a problem with Crucial which is the retail front end for the memory chip manufacturer Micron. Unfortunately I don't have the luxury of being able to fiddle with ram to get it to work. This server is co-located at an isp so I don't have physical access to it unless I go up there, which is inconvenient, or I pick it up and bring it home which is inconvenient in the extreme and involves down time. I need ram that works as rated the first time without tweaking. Crucial always has for me. Never again will I buy anything else, at least for this machine.
Yea, I see. I thought it kind of strange also when i found out that the voltage needed to be increased, Why would that be i thought, But once I did they worked great.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.