Re: 2.6.32.27 dom0 - BUG: unable to handle kernel paging request

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 01/31/2011 01:17 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 31, 2011 at 04:07:18PM -0500, Christopher S. Aker wrote:
>>> Xen: 3.4.4-rc1-pre 64bit (xenbits @ 19986)
>>> Dom0: 2.6.32.27-1 PAE (xen/stable-2.6.32.x)
>>>
>>> We've been running our xen-thrash testsuite on a bunch of hosts
>>> against a very recent build, and we've just hit this on one box:
>>>
>>> BUG: unable to handle kernel paging request at 15555d60
> Oh, I hit that if I do cat /sys/kernel/debug/kernel_page_tables.
>
> On 64-bit:
> sh-4.1# cd /sys/kernel/debug
> sh-4.1# ls
> acpi  boot_params  kernel_page_tables  mce      usb             x86
> bdi   dri          kprobes             tracing  wakeup_sources  xen
> sh-4.1# cat kernel_page_tables
> [  108.263615] BUG: unable to handle kernel paging request at ffff9d5555555000
> [  108.270480] IP: [<ffffffff81036bf0>] ptdump_show+0xc6/0x2f6
> [  108.276122] PGD 0 
> [  108.278205] Oops: 0000 [#1] SMP 
> [  108.281504] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:06:03.0/class
> [  108.289316] CPU 3 
> [  108.291137] Modules linked in: xen_evtchn video sg sd_mod radeon ahci libahci libata fbcon scsi_mod tileblit e1000e font bitblit ttm softcursor drm_kms_helper xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs [last unloaded: dump_dma]
> [  108.314658] 
> [  108.316221] Pid: 3025, comm: cat Not tainted 2.6.38-rc2-00038-g7c92066 #1 DX58SO/        
> [  108.324466] RIP: e030:[<ffffffff81036bf0>]  [<ffffffff81036bf0>] ptdump_show+0xc6/0x2f6
> [  108.332538] RSP: e02b:ffff8800868f5dd8  EFLAGS: 00010286
> [  108.337919] RAX: ffff800000000000 RBX: ffff880085117700 RCX: 0000000000000000
> [  108.345126] RDX: ffff9d555555Killed5ff8 RSI: 000000
> 0000000000 RDI: sh-4.1# 0000000152460067
> [  108.345128] RBP: ffff8800868f5e78 R08: 0000000000000006 R09: 0000000000000000
> [  108.345130] R10: 00007fffec97cc30 R11: 0000000000000246 R12: ffff9d5555555000
> [  108.345132] R13: ffff880085117700 R14: ffffffff81803800 R15: ffff880000000000
> [  108.345137] FS:  00007f6c5a3d7700(0000) GS:ffff88009ce83000(0000) knlGS:0000000000000000
> [  108.345139] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  108.345140] CR2: ffff9d5555555000 CR3: 000000008b2c6000 CR4: 0000000000002660
> [  108.345142] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  108.345144] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  108.345146] Process cat (pid: 3025, threadinfo ffff8800868f4000, task ffff88009dbe8000)
> [  108.345148] Stack:
> [  108.345149]  ffffffff81006ca2 0000000000000246 00007fffec97cc30 ffffffff8110efe7
> [  108.345152]  ffff9d5555555ff8 0000800000000000 ffff88009f0029c0 0000800000000000
> [  108.345155]  0000000000000001 0000000000000000 0000000000000000 ffff800000000000
> [  108.345158] Call Trace:
> [  108.345163]  [<ffffffff81006ca2>] ? check_events+0x12/0x20
> [  108.345168]  [<ffffffff8110efe7>] ? seq_read+0xbf/0x34a
> [  108.345170]  [<ffffffff8110efe7>] ? seq_read+0xbf/0x34a
> [  108.345173]  [<ffffffff8110f0a1>] seq_read+0x179/0x34a
> [  108.345176]  [<ffffffff810f5c32>] vfs_read+0xa6/0x102
> [  108.345178]  [<ffffffff810f5d47>] sys_read+0x45/0x6c
> [  108.345181]  [<ffffffff8100a992>] system_call_fastpath+0x16/0x1b
> [  108.345182] Code: 0f 00 00 00 88 ff ff 48 8d 14 10 4e 8d 24 38 48 8b 45 98 48 89 55 80 48 89 45 88 48 8b 45 88 48 c1 e0 10 48 c1 f8 10 48 89 45 b8 <49> 8b 3c 24 48 85 ff 0f 84 96 01 00 00 ff 14 25 b0 18 81 81 48 
> [  108.345208] RIP  [<ffffffff81036bf0>] ptdump_show+0xc6/0x2f6
> [  108.345211]  RSP <ffff8800868f5dd8>
> [  108.345212] CR2: ffff9d5555555000
> [  108.345214] ---[ end trace 9134d308b82bc832 ]---
>
>
> The 32-bit hits this too, with the 15555d60 address.
>
> Does the xenthrash hit this file too? Do you know what file it touches when
> this happens?

I think you're seeing the same address because many bogus m2p lookups
return 0x55555555.  I don't think there's any more similarity between
what you're seeing and Christopher's report than that.

    J