Re: [Xen-users] Xen 4.3.1 / Linux 3.12 panic

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-11-05 at 14:19 +0100, Wouter de Geus wrote:

> I've been trying to get a new machine up and running with the latest
> Xen for a while on a Slackware64 (current) machine.
> After installing Xen from source and building a new kernel with all
> xen options enabled I haven't been able to get the machine to behave.
> The machine is a brand new dual opteron 6212 on a Supermicro H8DGi
> board with 64G ECC memory.
> 
> Running a stock slackware kernel without xen works like a charm,
> haven't seen anything weird.
> However, as soon as I boot Xen with my custom kernel the machine
> panics within the hour.
> When doing something intensive like building a kernel it'll often
> crash in a few minutes.
> I've tried both Xen 4.3.0 and 4.3.1, no difference there.
> The kernels I've tried were 3.11.4 and 3.11.6 and the brand new 3.12.
> 
> The kernel panics are a bit different every time, but the most common
> seems to be 'Bad page state in process X' or 'unable to handle kernel
> paging request at X' and of course 'general protection fault'.
> Here's the most recent one:

(trimmed the long common prefix so it's not wrapped and therefore
readable)

> [ 6868.034665] general protection fault: 0000 [#1] SMP 
> [ 6868.034686] Modules linked in:
> [ 6868.034697] CPU: 0 PID: 262 Comm: jbd2/md0-8 Not tainted 3.12.0-Desman #1
> [ 6868.034707] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0    
>     09/10/2012
> [ 6868.034717] task: ffff8800d7162b20 ti: ffff8800d68b2000 task.ti: 
> ffff8800d68b2000
> [ 6868.034726] RIP: e030:[<ffffffff8114119b>]  [<ffffffff8114119b>] 
> __rmqueue+0x6b/0x3a0
> [ 6868.034745] RSP: e02b:ffff8800d68b38b0  EFLAGS: 00010012
> [ 6868.034752] RAX: ffff8801281d9e08 RBX: 0000000000000000 RCX: 
> 0000000000000003
> [ 6868.034797] RDX: 0000000000000001 RSI: ffff8801281d9f22 RDI: 
> 9f30ffff8801281d
> [ 6868.034805] RBP: ffff8801281d9f02 R08: 0000000000000010 R09: 
> 9f20ffff8801281d
> [ 6868.034814] R10: ffff8801281d9f10 R11: 0000000000000058 R12: 
> ffff8801281d9d80
> [ 6868.034822] R13: 0000000000000001 R14: ffff8801281d9e00 R15: 
> ffffea00046534e0
> [ 6868.034837] FS:  00007ff41d295740(0000) GS:ffff880122a00000(0000) 
> knlGS:0000000000000000
> [ 6868.034847] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 6868.034854] CR2: 00007f4d5f308fb5 CR3: 000000011d045000 CR4: 
> 0000000000040660
> [ 6868.034864] Stack:
> [ 6868.034869]  0000000000000000 ffff88011e4046c0 0000000000000001 
> 0000000000001000
> [ 6868.034883]  0000000000000000 ffff8801281d9d80 0000000000000001 
> 0000000000000000
> [ 6868.034897]  000000000000001f 0000000000000009 ffffea00046534e0 
> ffffffff81142f89
> [ 6868.034911] Call Trace:
> [ 6868.034922]  [<ffffffff81142f89>] ? get_page_from_freelist+0x329/0x900
> [ 6868.034935]  [<ffffffff811436b4>] ? __alloc_pages_nodemask+0x154/0xa90
> [ 6868.034948]  [<ffffffff811539bd>] ? zone_statistics+0x9d/0xa0
> [ 6868.034961]  [<ffffffff8117ddd3>] ? __kmalloc+0xe3/0x120
> [ 6868.034975]  [<ffffffff81263d9a>] ? ext4_ext_find_extent+0x26a/0x300
> [ 6868.034987]  [<ffffffff811749a5>] ? alloc_pages_current+0xb5/0x180
> [ 6868.034999]  [<ffffffff8117c3d5>] ? new_slab+0x255/0x2e0
> [ 6868.035011]  [<ffffffff81d42807>] ? __slab_alloc+0x2a1/0x436
> [ 6868.035025]  [<ffffffff811b8e18>] ? alloc_buffer_head+0x18/0x60
> [ 6868.035037]  [<ffffffff8117db3b>] ? kmem_cache_alloc+0xab/0xd0
> [ 6868.035049]  [<ffffffff811b8e18>] ? alloc_buffer_head+0x18/0x60
> [ 6868.035061]  [<ffffffff811b8227>] ? generic_block_bmap+0x37/0x50
> [ 6868.035075]  [<ffffffff81290676>] ? 
> jbd2_journal_write_metadata_buffer+0x56/0x3c0
> [ 6868.035088]  [<ffffffff8128aa41>] ? 
> jbd2_journal_commit_transaction+0x721/0x16d0
> [ 6868.035103]  [<ffffffff81007cbc>] ? xen_clocksource_read+0x1c/0x20
> [ 6868.035116]  [<ffffffff81d4eed1>] ? _raw_spin_lock_irqsave+0x11/0x50
> [ 6868.035128]  [<ffffffff8128e5df>] ? kjournald2+0xaf/0x240
> [ 6868.035140]  [<ffffffff810cd2d0>] ? wake_up_atomic_t+0x30/0x30
> [ 6868.035152]  [<ffffffff8128e530>] ? commit_timeout+0x10/0x10
> [ 6868.035163]  [<ffffffff810cc57f>] ? kthread+0xaf/0xc0
> [ 6868.035174]  [<ffffffff81007cbc>] ? xen_clocksource_read+0x1c/0x20
> [ 6868.035186]  [<ffffffff810cc4d0>] ? kthread_create_on_node+0x120/0x120
> [ 6868.035197]  [<ffffffff81d4facc>] ? ret_from_fork+0x7c/0xb0
> [ 6868.035208]  [<ffffffff810cc4d0>] ? kthread_create_on_node+0x120/0x120
> [ 6868.035215] Code: 89 c2 89 d9 4c 89 c7 48 c1 e7 04 48 8d 34 38 48 3b 36 0f 
> 84 b8 00 00 00 49 c1 e0 04 4b 8b 34 02 48 8b 7e 08 4c 8b 0e 48 8d 6e e0 <49> 
> 89 79 08 4c 89 0f 48 bf 00 01 10 00 00 00 ad de 48 89 3e 48 
> [ 6868.035326] RIP  [<ffffffff8114119b>] __rmqueue+0x6b/0x3a0
> [ 6868.035336]  RSP <ffff8800d68b38b0>
> [ 6868.049110] ---[ end trace 65f94d10957f59d0 ]---

> If it weren't for the stock kernel (without Xen) running stable

Have you run your own kernel (3.12.0-Desman, the one which crashes with
Xen) without Xen underneath?

> I'd guess bad memory, but so far a memory test gave 0 errors (not that
> that's a real indication).
> Feels like a bug / config problem somehow.

Yes, I agree. I'm afraid I've not seen anything like this, CCing the Xen
pvops maintainers for input.


Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users