Unable to handle kernel paging request at virtual address

Unable to handle kernel paging request at virtual address

[Dominik Sacher]

hi !
i not a kernel hacker, so i don't know, whom to write to.
maybe you can help !
i get several application-crashs on my redhat7.1 (updated to kernel 2.4.3-12) 
and every crash produces some kind of this:

----------------------------------------------------------------------------
Jul 16 20:04:35 jukebox kernel:  <1>Unable to handle kernel paging request at 
virtual address 41648370
Jul 16 20:04:35 jukebox kernel:  printing eip:
Jul 16 20:04:35 jukebox kernel: c013f6bc
Jul 16 20:04:35 jukebox kernel: pgd entry c8dd6414: 0000000000000000
Jul 16 20:04:35 jukebox kernel: pmd entry c8dd6414: 0000000000000000
Jul 16 20:04:35 jukebox kernel: ... pmd not present!
Jul 16 20:04:35 jukebox kernel: Oops: 0000
Jul 16 20:04:35 jukebox kernel: CPU:    0
Jul 16 20:04:35 jukebox kernel: EIP:    0010:[d_lookup+96/260]
Jul 16 20:04:35 jukebox kernel: EIP:    0010:[<c013f6bc>]
Jul 16 20:04:35 jukebox kernel: EFLAGS: 00010a87
Jul 16 20:04:35 jukebox kernel: eax: c1640000   ebx: 41648328   ecx: 0000000f 
  edx: 134b8ec9
Jul 16 20:04:35 jukebox kernel: esi: 134b8ec9   edi: c6c99f84   ebp: 41648340 
  esp: c6c99eb4
Jul 16 20:04:35 jukebox kernel: ds: 0018   es: 0018   ss: 0018
Jul 16 20:04:35 jukebox kernel: Process gkrellm (pid: 6233, 
stackpage=c6c99000)
Jul 16 20:04:35 jukebox kernel: Stack: c1648340 c43e000a 134b8ec9 00000005 
c6c99f18 134b8ec9 c6c99f84 c43e000f 
Jul 16 20:04:35 jukebox kernel:        c01377f6 ca020f60 c6c99f18 c6c99f18 
c0137eb7 ca020f60 c6c99f18 00000000 
Jul 16 20:04:35 jukebox kernel:        c6c99f04 c6c99f04 00000001 00000000 
00000000 c33df7e0 000009f7 000001f4 
Jul 16 20:04:35 jukebox kernel: Call Trace: [cached_lookup+14/72] 
[path_walk+1275/1880] [open_namei+145/1456] [filp_open+50/80] [getname+92/
152] 
Jul 16 20:04:35 jukebox kernel: Call Trace: [<c01377f6>] [<c0137eb7>] 
[<c01385c1>] [<c012dd72>] [<c0137608>] 
Jul 16 20:04:35 jukebox kernel:    [sys_open+49/148] [system_call+51/56] 
Jul 16 20:04:35 jukebox kernel:    [<c012e029>] [<c0106c1f>] 
Jul 16 20:04:35 jukebox kernel: 
Jul 16 20:04:35 jukebox kernel: Code: 39 53 48 8b 6d 00 0f 85 80 00 00 00 8b 
44 24 24 39 43 0c 75 
----------------------------------------------------------------------------

i even can compile me a new kernel (2.4.6 / 2.2.19), because everytime i try, 
i get this bug and the "make" process dies.
maybe someone can give a hint.

thanks a lot !
d.sacher

Re: Unable to handle kernel paging request at virtual address

[Jesse Wyant]

> hi !
> i not a kernel hacker, so i don't know, whom to write to.
> maybe you can help !
> i get several application-crashs on my redhat7.1 (updated to kernel 2.4.3-12) 
> and every crash produces some kind of this:

I've seen similar `Oopses' when I've compiled my ALSA sound drivers (for
my i815e motherboard's AC'97 audio) for the wrong kernel, or didn't do a 
`make clean' before recompiling ALSA.  But, to determine the problem, you
need to run your Oops output through 'ksymoops', do a 'man ksymoops' for
usage instructions.  This will attach library calls to all those pointers
in the Oops outputs.  That is where I would see that my Oopses were due
to ALSA, you should be able to better root-cause the problem this way.

-jesse

Jesse Wyant
------------------------------------------------------------
An Englishman never enjoys himself, except for a noble purpose.
		-- A.P. Herbert

Unable to handle kernel paging request at virtual address....

[Femitha Majeed]

Hi,

I am trying to write a kernel module which reads the files in the /proc 
directory.

When I do an insmod filename.o, I get the following error:
Unable to handle kernel paging request at virtual address....

In the module, I use kmalloc to allocate memory. Is that the reason I am 
getting this error?

I am very new to writing kernel modules, I would really appreciate a reply.

Thanks,
Femitha Majeed

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: Unable to handle kernel paging request at virtual address....

[Erik Mouw]

On Sat, Nov 10, 2001 at 04:23:03AM +0000, Femitha Majeed wrote:
> I am trying to write a kernel module which reads the files in the /proc 
> directory.

The idea behind /proc is that it allows userland to read or write
certain kernel variables. You shouldn't read a /proc file from within
the kernel.

> When I do an insmod filename.o, I get the following error:
> Unable to handle kernel paging request at virtual address....
> 
> In the module, I use kmalloc to allocate memory. Is that the reason I am 
> getting this error?

Without having your source it's impossible to tell. Please read the
procfs guide in your kernel tree or at
http://www.kernelnewbies.org/documents/ .

> I am very new to writing kernel modules, I would really appreciate a reply.

Go to the www.kernelnewbies.org website and subscribe to the
kernelnewbies mailing list. The #kernelnewbies IRC channel is also
quite helpful.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Unable to handle kernel paging request at virtual address

[pavankvk]

Reference to my previous mail..the actual error message on console is given below..
Unable to handle kernel paging request at virtual address c2acc6d8
current->tss.cr3 = 0116e000, ^Pr3 = 0116e000
*pde = 0009e067
*pte = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[dev_close+52/184]
EFLAGS: 00010206
eax: 00000000   ebx: 02acc6d8   ecx: 00000002   edx: 73cb2605
esi: 00000000   edi: 0001fdfc   ebp: 00001143   esp: 00b38ef8
ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
Process ifconfig (pid: 4602, process nr: 98, stackpage=00b38000)
Stack: 02acc6d8 00000002 0001fdfc 0001fdfc bffff9b8 00b38f60 001397e8 0001fdfc
       bffff998 00008914 0804c983 00b47810 00000000 0098a1d4 40075000 010c0c98
       0006d000 ffffffed 31687465 0804e000 0804c921 08048bc8 08041142 0804cdef
Call Trace: [<02acc6d8>] [dev_ifsioc+708/1628] [dev_ioctl+439/508] [inet_ioctl+871/960] [sock_ioctl+33/40] [sys_ioctl+255/272] [system_call+85/124] 

Code: 8b 03 ff d0 83 c4 0c 66 85 c0 7c 07 8b 5b 04 85 db 75 e9 57





Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com

 Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

Unable to handle kernel paging request at virtual address

[shacky]

Hi.
I installed Ubuntu 7.04 and then upgraded to the future 7.10 on my
system based on an Asus Pundit barebone with 512 mb RAM and 120 Gb IDE
hard disk.
The system works without any problem, but when I try to shutdown or
restart the system, after a while during the shutdown process, the
system hangs and I see this error:

[87.935473] BUG: unable to handle kernel paging request at virtual
address 6d207972
[...........] printing eip:
[...........] 6d207972
[...........] *pde = 00000000
[...........] Oops: 000 [#2]
[...........] SMP
[...........] Modules linked in: bluetooth capability lirc_dev
speedstep_lib cpufreq_powersave cpufreq_stats cpufreq_userspace
cpufreq_ondemand cpufreq_conservative freq_table video container sbs
button dock ac battery ipv6 sbp2 lp fuse snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul  [....] etc.

I'm using the kernel 2.6.22.

I'm omitting the rest of the error because it is very very long and I
have to rewrite it because I can't copy&paste it. If you need some
other information please ask. :-)

Could you help me, please? What could be the problem?

Thank you very much!
Bye.

Re: Unable to handle kernel paging request at virtual address

[Dave Jones]

On Fri, Aug 10, 2007 at 01:17:14AM +0200, shacky wrote:

 > [87.935473] BUG: unable to handle kernel paging request at virtual
 > address 6d207972
 > [...........] printing eip:
 > [...........] 6d207972
 > [...........] *pde = 00000000
 > [...........] Oops: 000 [#2]
 > [...........] SMP
 > [...........] Modules linked in: bluetooth capability lirc_dev
 > speedstep_lib cpufreq_powersave cpufreq_stats cpufreq_userspace
 > cpufreq_ondemand cpufreq_conservative freq_table video container sbs
 > button dock ac battery ipv6 sbp2 lp fuse snd_emu10k1_synth
 > snd_emux_synth snd_seq_virmidi snd_seq_midi_emul  [....] etc.
 > 
 > I'm using the kernel 2.6.22.
 > 
 > I'm omitting the rest of the error because it is very very long and I
 > have to rewrite it because I can't copy&paste it. If you need some
 > other information please ask. :-)

You snipped the most important part.  Even a digital photo of the
crash would be more useful than what we have above.
So far, there's not really much to go on.

	Dave

-- 
http://www.codemonkey.org.uk

Re: Unable to handle kernel paging request at virtual address

[shacky]

> You snipped the most important part.  Even a digital photo of the
> crash would be more useful than what we have above.
> So far, there's not really much to go on.

Could you tell me what is the most important part, so I try to rewrite
it by hand?
I don't think a digital photo will be much useful because the whole
error is writed on a simple black screen with white caracters.

Re: Unable to handle kernel paging request at virtual address

[Dave Jones]

On Fri, Aug 10, 2007 at 01:44:24AM +0200, shacky wrote:
 > > You snipped the most important part.  Even a digital photo of the
 > > crash would be more useful than what we have above.
 > > So far, there's not really much to go on.
 > 
 > Could you tell me what is the most important part, so I try to rewrite
 > it by hand?

It's hard to blindly guess because there's so little to go on.
At the least, a complete list of the modules loaded, the EIP/RIP
and the call trace. (This makes up 90% of the output, hence the
suggestion to take a photograph).

 > I don't think a digital photo will be much useful because the whole
 > error is writed on a simple black screen with white caracters.

That's expected. We usually cope with that quite well.

	Dave

-- 
http://www.codemonkey.org.uk

Re: Unable to handle kernel paging request at virtual address

[shacky]

> It's hard to blindly guess because there's so little to go on.
> At the least, a complete list of the modules loaded, the EIP/RIP
> and the call trace. (This makes up 90% of the output, hence the
> suggestion to take a photograph).

Ok, I wrote down all the error:

===========================================================
[9271.829711] BUG: unable to handle kernel paging request at virtual
address 6d207972
[9271.829805] printing eip:
[9271.829845] 6d207972
[9271.829883] *pde = 00000000
[9271.829926] Oops: 000 [#2]
[9271.829965] SMP
[9271.830067] Modules linked in: bluetooth capability lirc_dev ppdev
speedstep_lib cpufreq_powersave cpufreq_stats cpufreq_userspace
cpufreq_ondemand cpufreq_conservative freq_table video container sbs
button dock ac battery ipv6 sbp2 lp fuse snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1
snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
snd_page_alloc and_util_mem snd_hwdep snd_seq_dummy snd_seq_oss
snd_seq_midi snd_rawmidi snd_seq_midi_event pcmcia snd_seq snd_timer
snd_seq_device parport_pc snd parport serio_raw psmouse pcspkr
emu10k1_gp soundcore yenta_socket rsrc_nonstatic pcmcia_core gameport
i2c_sis96x shpchp i2c_core pci_hotplug sis_agp agpgart af_packet evdev
reiserfs sg sr_mod cdrom sd_mod b44 mii ehci_hcd ohci_hcd usbcore
pata_sis ata_generic libata scsi_mod ohci1394 ieee1394 thermal
processor fan apparmor commoncap aamatch_pcre
[9271.833075] CPU:    0
[9271.833076] EIP:    0060:[<6d207972>]    Not tainted VLI
[9271.833078] EFLAGS: 00010206   (2.6.22-9-generic #1)
[9271.833212] EIP is at 0x6d207972
[9271.833255] eax: d55f5c08   ebx: d26f0a00   ecx: 00000000   edx: 6d207972
[9271.833305] esi: 01234567   edi: b7f8fff4   ebp: d3218000   esp: d3219e8c
[9271.833371] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[9271.833435] Process reboot (pid: 9650, ti=d3218000 task=d8b2af60
task.ti=d3218000)
[9271.833501] Stack: c026326c 00000000 c013585b c02f2c7e 28121969
28121969 c0135a4a 000000c3
[9271.833868]        c158fcd4 c158fcd4 c015e660 00000148 c13b5b00
c0161001 c0284a32 00000000
[9271.834236]        d3219f50 ddf6d420 dc2ada80 dc2adac8 c158fc30
00000000 00000000 c043ac20
[9271.843603] Call trace:
[9271.834704]  [<c026326c>] device_shutdown+0x3c/0x90
[9271.834818]  [<c013585b>] kernel_restart+0xb/0x50
[9271.834915]  [<c02f2c7e>] lock_kernel+0x1e/0x40
[9271.835028]  [<c0135a4a>] sys_reboot+0x19a/0x1e0
[9271.835140]  [<c015e660>] find_get_page+0x20/0x60
[9271.835249]  [<c0161001>] filemap_nopage+0x181/0x340
[9271.835344]  [<c0284a32>] netdev_run_todo+0x142/0x250
[9271.835512]  [<c02f2a58>] _spin_lock_bh+0x8/0x20
[9271.835624]  [<c01a32fe>] invalidate_inode_buffers+0xe/0xc0
[9271.835719]  [<c02f2a58>] _spin_lock_bh+0x8/0x20
[9271.835878]  [<c0193d9e>] destroy_inode+0x2e/0x50
[9271.835993]  [<c0191758>] d_kill+0x38/0x50
[9271.836098]  [<c0192457>] dput+0x87/0x100
[9271.836197]  [<c01814eb>] __fput+0x12b/0x1a0
[9271.836318]  [<c0196884>] mntput_no_expire+0x24/0xa0
[9271.836430]  [<c017e8f7>] filp_close+0x47/0x80
[9271.836548]  [<c017fc6b>] sys_close+0x6b/0xd0
[9271.836658]  [<c01041d2>] sysenter_pat_esp+0x6b/0xa9
[9271.836848]  =======================
[9271.836905] Code:  Bad EIP value.
[9271.837024] EIP: [<6d207972>] 0x6d207972 SS:ESP 0068:d3219e8c
===========================================================

Thank you very much!
Bye.

Re: Unable to handle kernel paging request at virtual address

[shacky]

I think this problem is caused by the lirc_serial module, because if I
try to modprobe the lirc_serial module I get this error:

kobject_add failed for lirc_serial.0 with -EEXIST, don't try to
register things whith the same name in the same directory.
kobject_shadow_add
kobject_set_name
device_add
platform_device_add
init_module
sys_init_module
prio_tree_insert
sysenter_past_esp

But I don't understand why it happens...

Have you any idea?
Thank you very much! :-)

unable to handle kernel paging request at virtual address

[Christopher S. Aker]

Xen : 3.2.0 64bit
dom0: 2.6.16.33 32pae
domU: linux-2.6.18-xen.hg @ 416:08e85e79c65d 32pae

Our server infrastructure automatically logs console output from domUs 
that panic.  I have available to me another dozen or so BUG outputs 
similar but not identical to the example below, if this piques anyone's 
interest...

BUG: unable to handle kernel paging request at virtual address 915536e9
  printing eip:
03e45000 -> *pde = 00000002:d2d46027
15b9a000 -> *pme = 00000000:00000000
Oops: 0000 [#1]
SMP
Modules linked in:
CPU:    0
EIP:    0061:[<c01750f4>]    Not tainted VLI
EFLAGS: 00010286   (2.6.18.8-domU-linode7 #1)
EIP is at iput+0xd/0x6b
eax: 915536c9   ebx: c6e130d4   ecx: c6e130ec   edx: c6e130ec
esi: 0000002f   edi: 00000000   ebp: d61b983c   esp: d5e2fee4
ds: 007b   es: 007b   ss: 0069
Process kswapd0 (pid: 114, ti=d5e2e000 task=d5dc0ab0 task.ti=d5e2e000)
Stack: d20b9214 c0173edf d20b9214 0000002f c0174031 00000080 00000050 
00003d54
        c137eac0 00000088 00013c51 c0174094 c01439a0 c012eb7b 00000000 
c0513400
        0000000c 00000000 c05c6fe0 00000080 000000d0 00000000 00000002 
c0513400
Call Trace:
  [<c0173edf>] prune_one_dentry+0x54/0x75
  [<c0174031>] prune_dcache+0x131/0x15b
  [<c0174094>] shrink_dcache_memory+0x39/0x3b
  [<c01439a0>] shrink_slab+0x111/0x186
  [<c012eb7b>] finish_wait+0x25/0x4b
  [<c0144d5b>] kswapd+0x2e9/0x3eb
  [<c012e960>] autoremove_wake_function+0x0/0x37
  [<c0144a72>] kswapd+0x0/0x3eb
  [<c012e89a>] kthread+0xde/0xe2
  [<c012e7bc>] kthread+0x0/0xe2
  [<c0102b75>] kernel_thread_helper+0x5/0xb
Code: 06 89 d8 ff d2 5b c3 89 da a1 00 de 58 c0 5b e9 4f 52 fe ff 0f 0b 
ae 00 26 6b 4c c0 eb c5 53 89 c3 85 c0 74 58 8b 80 9c 00 00 00 <8b> 40 
20 83 bb
  40 01 00 00 20 74 48 85 c0 74 0e 8b 50 14 85 d2
EIP: [<c01750f4>] iput+0xd/0x6b SS:ESP 0069:d5e2fee4
  <1>BUG: unable to handle kernel paging request at virtual address 0424cb05
  printing eip:
c01750f4
03e45000 -> *pde = 00000003:30e43027
0629d000 -> *pme = 00000000:00000000
Oops: 0000 [#2]
SMP
Modules linked in:
CPU:    0
EIP:    0061:[<c01750f4>]    Not tainted VLI
EFLAGS: 00210282   (2.6.18.8-domU-linode7 #1)
EIP is at iput+0xd/0x6b
eax: 0424cae5   ebx: c6e132c8   ecx: c6e132e0   edx: c6e132e0
esi: 0000007f   edi: 00000000   ebp: d61b983c   esp: d09bfd1c
ds: 007b   es: 007b   ss: 0069
Process httpd (pid: 3677, ti=d09be000 task=d5ce8ab0 task.ti=d09be000)
Stack: d20b9094 c0173edf d20b9094 0000007f c0174031 00000080 00000000 
00003d54
        c137eac0 00000090 00013d55 c0174094 c01439a0 00000003 d5c2c878 
d5c2c874
        00000018 00000000 c05c6fe0 00000100 000280d2 00000000 0000000a 
00000040
Call Trace:
  [<c0173edf>] prune_one_dentry+0x54/0x75
  [<c0174031>] prune_dcache+0x131/0x15b
  [<c0174094>] shrink_dcache_memory+0x39/0x3b
  [<c01439a0>] shrink_slab+0x111/0x186
  [<c0144f94>] try_to_free_pages+0x137/0x1f3
  [<c0140ae7>] __alloc_pages+0x12e/0x2d2
  [<c0158316>] shmem_swp_alloc+0x8b/0x277
  [<c015894f>] shmem_getpage+0x10e/0x5e1
  [<c01598fc>] shmem_nopage+0x97/0xce
  [<c014bc6c>] __handle_mm_fault+0x28a/0x15db
  [<c013de28>] __generic_file_aio_read+0x16e/0x243
  [<c013bc05>] file_read_actor+0x0/0xc7
  [<c015db64>] do_sync_read+0xc1/0x11c
  [<c0166e61>] cp_new_stat64+0xf4/0x106
  [<c01103ea>] do_page_fault+0x10f/0xc70
  [<c015daa3>] do_sync_read+0x0/0x11c
  [<c015df67>] vfs_read+0xa2/0x160
  [<c015ea2e>] sys_read+0x41/0x6a
  [<c01102db>] do_page_fault+0x0/0xc70
  [<c01052e3>] error_code+0x2b/0x30
Code: 06 89 d8 ff d2 5b c3 89 da a1 00 de 58 c0 5b e9 4f 52 fe ff 0f 0b 
ae 00 26 6b 4c c0 eb c5 53 89 c3 85 c0 74 58 8b 80 9c 00 00 00 <8b> 40 
20 83 bb
  40 01 00 00 20 74 48 85 c0 74 0e 8b 50 14 85 d2
EIP: [<c01750f4>] iput+0xd/0x6b SS:ESP 0069:d09bfd1c
  <1>BUG: unable to handle kernel paging request at virtual address 010d9559
  printing eip:
c015a531
06139000 -> *pde = 00000003:69252027
0768e000 -> *pme = 00000000:00000000
Oops: 0002 [#3]
SMP
Modules linked in:
CPU:    0
EIP:    0061:[<c015a531>]    Not tainted VLI
EFLAGS: 00210082   (2.6.18.8-domU-linode7 #1)
EIP is at free_block+0x83/0xfe
eax: c5883000   ebx: d5c2fa80   ecx: c6e13000   edx: 010d9555
esi: c6e13a00   edi: d5cac080   ebp: d5e30dd8   esp: c6679d24
ds: 007b   es: 007b   ss: 0069
Process httpd (pid: 3680, ti=c6678000 task=d4c54030 task.ti=c6678000)
Stack: c01426ea 0000001b 00000011 d5e30d94 d5cac080 c7a28618 d5cb5400 
c015a6df
        00000000 d5e30d80 0000001b d5c2fa80 d5e30d80 00000000 c7a28618 
00000000
        c015a3f4 c7a286b0 c7a286b0 c6679da0 00000029 c01750ce c7a286b8 
c0175b6f
Call Trace:
  [<c01426ea>] pagevec_lookup+0x1c/0x24
  [<c015a6df>] cache_flusharray+0x55/0xc1
  [<c015a3f4>] kmem_cache_free+0xc8/0xee
  [<c01750ce>] destroy_inode+0x2e/0x47
  [<c0175b6f>] dispose_list+0x6e/0xcf
  [<c0175db6>] shrink_icache_memory+0x1e6/0x223
  [<c01439a0>] shrink_slab+0x111/0x186
  [<c0144f94>] try_to_free_pages+0x137/0x1f3
  [<c0140ae7>] __alloc_pages+0x12e/0x2d2
  [<c014c9a5>] __handle_mm_fault+0xfc3/0x15db
  [<c013de28>] __generic_file_aio_read+0x16e/0x243
  [<c013bc05>] file_read_actor+0x0/0xc7
  [<c014e8fb>] vma_adjust+0x11a/0x412
  [<c0166e61>] cp_new_stat64+0xf4/0x106
  [<c01103ea>] do_page_fault+0x10f/0xc70
  [<c015dfc5>] vfs_read+0x100/0x160
  [<c014f5a1>] sys_brk+0xe5/0xef
  [<c01102db>] do_page_fault+0x0/0xc70
  [<c01052e3>] error_code+0x2b/0x30
Code: 00 40 c1 ea 0c c1 e2 05 03 15 a8 2a 5e c0 8b 02 f6 c4 40 75 7c 8b 
02 84 c0 79 7e 8b 4a 1c 8b 44 24 20 8b 5c 87 50 8b 11 8b 41 04 <89> 42 
04 89 10
  c7 01 00 01 10 00 c7 41 04 00 02 20 00 2b 71 0c
EIP: [<c015a531>] free_block+0x83/0xfe SS:ESP 0069:c6679d24


-Chris

Re: unable to handle kernel paging request at virtual address

[Keir Fraser]

The virtual addresses being faulted on are all rubbish non-kernel addresses.
How long do you run a VM for to see this? Our own (not very in-depth)
testing hasn't shown up anything like this.

 -- Keir

On 3/3/08 00:44, "Christopher S. Aker" <caker@theshore.net> wrote:

> Xen : 3.2.0 64bit
> dom0: 2.6.16.33 32pae
> domU: linux-2.6.18-xen.hg @ 416:08e85e79c65d 32pae
> 
> Our server infrastructure automatically logs console output from domUs
> that panic.  I have available to me another dozen or so BUG outputs
> similar but not identical to the example below, if this piques anyone's
> interest...
> 
> BUG: unable to handle kernel paging request at virtual address 915536e9
>   printing eip:
> 03e45000 -> *pde = 00000002:d2d46027
> 15b9a000 -> *pme = 00000000:00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in:
> CPU:    0
> EIP:    0061:[<c01750f4>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.18.8-domU-linode7 #1)
> EIP is at iput+0xd/0x6b
> eax: 915536c9   ebx: c6e130d4   ecx: c6e130ec   edx: c6e130ec
> esi: 0000002f   edi: 00000000   ebp: d61b983c   esp: d5e2fee4
> ds: 007b   es: 007b   ss: 0069
> Process kswapd0 (pid: 114, ti=d5e2e000 task=d5dc0ab0 task.ti=d5e2e000)
> Stack: d20b9214 c0173edf d20b9214 0000002f c0174031 00000080 00000050
> 00003d54
>         c137eac0 00000088 00013c51 c0174094 c01439a0 c012eb7b 00000000
> c0513400
>         0000000c 00000000 c05c6fe0 00000080 000000d0 00000000 00000002
> c0513400
> Call Trace:
>   [<c0173edf>] prune_one_dentry+0x54/0x75
>   [<c0174031>] prune_dcache+0x131/0x15b
>   [<c0174094>] shrink_dcache_memory+0x39/0x3b
>   [<c01439a0>] shrink_slab+0x111/0x186
>   [<c012eb7b>] finish_wait+0x25/0x4b
>   [<c0144d5b>] kswapd+0x2e9/0x3eb
>   [<c012e960>] autoremove_wake_function+0x0/0x37
>   [<c0144a72>] kswapd+0x0/0x3eb
>   [<c012e89a>] kthread+0xde/0xe2
>   [<c012e7bc>] kthread+0x0/0xe2
>   [<c0102b75>] kernel_thread_helper+0x5/0xb
> Code: 06 89 d8 ff d2 5b c3 89 da a1 00 de 58 c0 5b e9 4f 52 fe ff 0f 0b
> ae 00 26 6b 4c c0 eb c5 53 89 c3 85 c0 74 58 8b 80 9c 00 00 00 <8b> 40
> 20 83 bb
>   40 01 00 00 20 74 48 85 c0 74 0e 8b 50 14 85 d2
> EIP: [<c01750f4>] iput+0xd/0x6b SS:ESP 0069:d5e2fee4
>   <1>BUG: unable to handle kernel paging request at virtual address 0424cb05
>   printing eip:
> c01750f4
> 03e45000 -> *pde = 00000003:30e43027
> 0629d000 -> *pme = 00000000:00000000
> Oops: 0000 [#2]
> SMP
> Modules linked in:
> CPU:    0
> EIP:    0061:[<c01750f4>]    Not tainted VLI
> EFLAGS: 00210282   (2.6.18.8-domU-linode7 #1)
> EIP is at iput+0xd/0x6b
> eax: 0424cae5   ebx: c6e132c8   ecx: c6e132e0   edx: c6e132e0
> esi: 0000007f   edi: 00000000   ebp: d61b983c   esp: d09bfd1c
> ds: 007b   es: 007b   ss: 0069
> Process httpd (pid: 3677, ti=d09be000 task=d5ce8ab0 task.ti=d09be000)
> Stack: d20b9094 c0173edf d20b9094 0000007f c0174031 00000080 00000000
> 00003d54
>         c137eac0 00000090 00013d55 c0174094 c01439a0 00000003 d5c2c878
> d5c2c874
>         00000018 00000000 c05c6fe0 00000100 000280d2 00000000 0000000a
> 00000040
> Call Trace:
>   [<c0173edf>] prune_one_dentry+0x54/0x75
>   [<c0174031>] prune_dcache+0x131/0x15b
>   [<c0174094>] shrink_dcache_memory+0x39/0x3b
>   [<c01439a0>] shrink_slab+0x111/0x186
>   [<c0144f94>] try_to_free_pages+0x137/0x1f3
>   [<c0140ae7>] __alloc_pages+0x12e/0x2d2
>   [<c0158316>] shmem_swp_alloc+0x8b/0x277
>   [<c015894f>] shmem_getpage+0x10e/0x5e1
>   [<c01598fc>] shmem_nopage+0x97/0xce
>   [<c014bc6c>] __handle_mm_fault+0x28a/0x15db
>   [<c013de28>] __generic_file_aio_read+0x16e/0x243
>   [<c013bc05>] file_read_actor+0x0/0xc7
>   [<c015db64>] do_sync_read+0xc1/0x11c
>   [<c0166e61>] cp_new_stat64+0xf4/0x106
>   [<c01103ea>] do_page_fault+0x10f/0xc70
>   [<c015daa3>] do_sync_read+0x0/0x11c
>   [<c015df67>] vfs_read+0xa2/0x160
>   [<c015ea2e>] sys_read+0x41/0x6a
>   [<c01102db>] do_page_fault+0x0/0xc70
>   [<c01052e3>] error_code+0x2b/0x30
> Code: 06 89 d8 ff d2 5b c3 89 da a1 00 de 58 c0 5b e9 4f 52 fe ff 0f 0b
> ae 00 26 6b 4c c0 eb c5 53 89 c3 85 c0 74 58 8b 80 9c 00 00 00 <8b> 40
> 20 83 bb
>   40 01 00 00 20 74 48 85 c0 74 0e 8b 50 14 85 d2
> EIP: [<c01750f4>] iput+0xd/0x6b SS:ESP 0069:d09bfd1c
>   <1>BUG: unable to handle kernel paging request at virtual address 010d9559
>   printing eip:
> c015a531
> 06139000 -> *pde = 00000003:69252027
> 0768e000 -> *pme = 00000000:00000000
> Oops: 0002 [#3]
> SMP
> Modules linked in:
> CPU:    0
> EIP:    0061:[<c015a531>]    Not tainted VLI
> EFLAGS: 00210082   (2.6.18.8-domU-linode7 #1)
> EIP is at free_block+0x83/0xfe
> eax: c5883000   ebx: d5c2fa80   ecx: c6e13000   edx: 010d9555
> esi: c6e13a00   edi: d5cac080   ebp: d5e30dd8   esp: c6679d24
> ds: 007b   es: 007b   ss: 0069
> Process httpd (pid: 3680, ti=c6678000 task=d4c54030 task.ti=c6678000)
> Stack: c01426ea 0000001b 00000011 d5e30d94 d5cac080 c7a28618 d5cb5400
> c015a6df
>         00000000 d5e30d80 0000001b d5c2fa80 d5e30d80 00000000 c7a28618
> 00000000
>         c015a3f4 c7a286b0 c7a286b0 c6679da0 00000029 c01750ce c7a286b8
> c0175b6f
> Call Trace:
>   [<c01426ea>] pagevec_lookup+0x1c/0x24
>   [<c015a6df>] cache_flusharray+0x55/0xc1
>   [<c015a3f4>] kmem_cache_free+0xc8/0xee
>   [<c01750ce>] destroy_inode+0x2e/0x47
>   [<c0175b6f>] dispose_list+0x6e/0xcf
>   [<c0175db6>] shrink_icache_memory+0x1e6/0x223
>   [<c01439a0>] shrink_slab+0x111/0x186
>   [<c0144f94>] try_to_free_pages+0x137/0x1f3
>   [<c0140ae7>] __alloc_pages+0x12e/0x2d2
>   [<c014c9a5>] __handle_mm_fault+0xfc3/0x15db
>   [<c013de28>] __generic_file_aio_read+0x16e/0x243
>   [<c013bc05>] file_read_actor+0x0/0xc7
>   [<c014e8fb>] vma_adjust+0x11a/0x412
>   [<c0166e61>] cp_new_stat64+0xf4/0x106
>   [<c01103ea>] do_page_fault+0x10f/0xc70
>   [<c015dfc5>] vfs_read+0x100/0x160
>   [<c014f5a1>] sys_brk+0xe5/0xef
>   [<c01102db>] do_page_fault+0x0/0xc70
>   [<c01052e3>] error_code+0x2b/0x30
> Code: 00 40 c1 ea 0c c1 e2 05 03 15 a8 2a 5e c0 8b 02 f6 c4 40 75 7c 8b
> 02 84 c0 79 7e 8b 4a 1c 8b 44 24 20 8b 5c 87 50 8b 11 8b 41 04 <89> 42
> 04 89 10
>   c7 01 00 01 10 00 c7 41 04 00 02 20 00 2b 71 0c
> EIP: [<c015a531>] free_block+0x83/0xfe SS:ESP 0069:c6679d24
> 
> 
> -Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: unable to handle kernel paging request at virtual address

[Christopher S. Aker]

Keir Fraser wrote:
> The virtual addresses being faulted on are all rubbish non-kernel addresses.
> How long do you run a VM for to see this? Our own (not very in-depth)
> testing hasn't shown up anything like this.

Not long -- perhaps a few days to a week.

Googling around, I'm finding similar posts for non-xen kernels, on newer 
kernels, too:

http://tinyurl.com/2nwtju

Any chance this is a bug in Linux itself?

-Chris

Re: unable to handle kernel paging request at virtual address

[Keir Fraser]

On 3/3/08 15:03, "Christopher S. Aker" <caker@theshore.net> wrote:

> Keir Fraser wrote:
>> The virtual addresses being faulted on are all rubbish non-kernel addresses.
>> How long do you run a VM for to see this? Our own (not very in-depth)
>> testing hasn't shown up anything like this.
> 
> Not long -- perhaps a few days to a week.
> 
> Googling around, I'm finding similar posts for non-xen kernels, on newer
> kernels, too:
> 
> http://tinyurl.com/2nwtju
> 
> Any chance this is a bug in Linux itself?

Well, it may just be a fairly generic place to crash if things have become
corrupted. I wonder if it could be related to gcc version, or perhaps if you
see this on one physical host only it might be a faulty DIMM?

 -- Keir

Re: unable to handle kernel paging request at virtual address

[Christopher S. Aker]

Keir Fraser wrote:
>> Any chance this is a bug in Linux itself?
> 
> Well, it may just be a fairly generic place to crash if things have become
> corrupted. I wonder if it could be related to gcc version, or perhaps if you
> see this on one physical host only it might be a faulty DIMM?

This happens across multiple host servers so I wouldn't suspect faulty 
hardware in this case.

gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Is there a recommended gcc version?  What are you guys using?

-Chris

Re: unable to handle kernel paging request at virtual address

[Christopher S. Aker]

Here's another report from a user who crashed, then was trying to umount 
a partition...

# umount /home
sb orphan head is 176344
sb_info orphan list:
BUG: unable to handle kernel paging request at virtual address 017902bd
printing eip:
c0315435
10723000 -> *pde = 00000002:2cca1027
0336b000 -> *pme = 00000000:00000000
Oops: 0000 [#1]
SMP
Modules linked in:
CPU: 0
EIP: 0061:[<c0315435>] Not tainted VLI
EFLAGS: 00010097 (2.6.18.8-domU-linode7 #1)
EIP is at vsnprintf+0x437/0x615
eax: 017902bd ebx: ffffffff ecx: 017902bd edx: fffffffe
esi: c05d118b edi: c05d1580 ebp: c04d325c esp: d5969e04
ds: 007b es: 007b ss: 0069
Process umount (pid: 2314, ti=d5968000 task=c1d54570 task.ti=d5968000)
Stack: 00000fff c1306180 c052e3a0 c0349c51 00002270 00000015 00000400 
c05d1180
00002285 00000000 ffffffff ffffffff d5969ee4 c04d325c 00000400 d594612c
00000000 d5dc8e00 c0315627 d5969ee0 c3611e5c c011c30f d5969ee0 c04847ef
Call Trace:
[<c0349c51>] kcons_write+0x0/0xc9
[<c0315627>] vscnprintf+0x14/0x21
[<c011c30f>] vprintk+0x6e/0x3c1
[<c04847ef>] __wait_on_bit+0x54/0x5e
[<c015fc64>] sync_buffer+0x0/0x34
[<c012ea2d>] wake_bit_function+0x0/0x3c
[<c011c67d>] printk+0x1b/0x1f
[<c01d6fab>] ext3_put_super+0x12b/0x1f6
[<c0163e86>] generic_shutdown_super+0x82/0x121
[<c0163f42>] kill_block_super+0x1d/0x2d
[<c01640f0>] deactivate_super+0x53/0x66
[<c0178421>] sys_umount+0x3e/0x21e
[<c01103ea>] do_page_fault+0x10f/0xc70
[<c014e7cb>] unmap_region+0x101/0x117
[<c0166f1c>] sys_stat64+0xf/0x33
[<c014dc98>] remove_vma+0x31/0x36
[<c014ee2e>] do_munmap+0x177/0x1cd
[<c0178618>] sys_oldumount+0x17/0x1b
[<c0105137>] syscall_call+0x7/0xb
Code: 42 fc ff ff 8b 44 24 4c 83 c0 04 89 44 24 30 8b 54 24 4c 8b 0a 81 
f9 ff 0f
00 00 b8 d5 f6 4d c0 0f 46 c8 8b 54 24 2c 89 c8 eb 06 <80> 38 00 74 07 
40 4a 83 fa ff 75 f4 29 c8 89 c3 8b 6c 24 28 f6
EIP: [<c0315435>] vsnprintf+0x437/0x615 SS:ESP 0069:d5969e04
BUG: warning at kernel/exit.c:854/do_exit()
[<c011e4cd>] do_exit+0x8c6/0x8cb
[<c011c67d>] printk+0x1b/0x1f
[<c0310069>] cfq_dispatch_requests+0x4e4/0x5a0
[<c0105f2e>] die+0x2c6/0x2d7
[<c0110a62>] do_page_fault+0x787/0xc70
[<c0124cc9>] run_timer_softirq+0x3a/0x1d3
[<c034a409>] handle_input+0x91/0xd8
[<c03163f1>] memmove+0x24/0x2a
[<c01102db>] do_page_fault+0x0/0xc70
[<c01052e3>] error_code+0x2b/0x30
[<c0315435>] vsnprintf+0x437/0x615
[<c0349c51>] kcons_write+0x0/0xc9
[<c0315627>] vscnprintf+0x14/0x21
[<c011c30f>] vprintk+0x6e/0x3c1
[<c04847ef>] __wait_on_bit+0x54/0x5e
[<c015fc64>] sync_buffer+0x0/0x34
[<c012ea2d>] wake_bit_function+0x0/0x3c
[<c011c67d>] printk+0x1b/0x1f
[<c01d6fab>] ext3_put_super+0x12b/0x1f6
[<c0163e86>] generic_shutdown_super+0x82/0x121
[<c0163f42>] kill_block_super+0x1d/0x2d
[<c01640f0>] deactivate_super+0x53/0x66
[<c0178421>] sys_umount+0x3e/0x21e
[<c01103ea>] do_page_fault+0x10f/0xc70
[<c014e7cb>] unmap_region+0x101/0x117
[<c0166f1c>] sys_stat64+0xf/0x33
[<c014dc98>] remove_vma+0x31/0x36
[<c014ee2e>] do_munmap+0x177/0x1cd
[<c0178618>] sys_oldumount+0x17/0x1b
[<c0105137>] syscall_call+0x7/0xb

-Chris

Re: unable to handle kernel paging request at virtual address

[Andi Kleen]

Keir Fraser <keir.fraser@eu.citrix.com> writes:
>
> Well, it may just be a fairly generic place to crash if things have become
> corrupted.

It is. dcache tends to use significant parts of memory and when you have
memory corruption in that you tend to crash in one of the dcache 
walkers of which prune_dcache is a example.

The usual approaches is to enable slab debugging etc.

-Andi