From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Date: Tue, 28 Apr 2009 09:25:27 -0700 Message-ID: <49F72DF7.8020904@goop.org> References: <49F0A797.1050402@goop.org> <20090423182451.GV24960@edu.joroinen.fi> <49F0B42E.2040904@goop.org> <20090425115404.GZ24960@edu.joroinen.fi> <49F6086D.1020602@goop.org> <20090427193835.GF24960@edu.joroinen.fi> <1240931113.22119.11.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1240931113.22119.11.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org Ian Campbell wrote: > On Mon, 2009-04-27 at 15:38 -0400, Pasi K=C3=A4rkk=C3=A4inen wrote: > =20 >> [root@dom0test linux-2.6-xen]# gdb vmlinux >> (gdb) x/i 0xc0888d74 >> 0xc0888d74 <__constant_c_memset+21>: rep stos %eax,%es:(%edi) >> =20 > > I see basically the same thing, except I'm testing current xen-tip/next= , > > (XEN) d0:v0: unhandled page fault (ec=3D0003) > (XEN) Pagetable walk from 00000000c0e5d000: > (XEN) L4[0x000] =3D 000000011b537027 0000000000000537 > (XEN) L3[0x003] =3D 000000011b5b9027 00000000000005b9 > (XEN) L2[0x007] =3D 000000011be64067 0000000000000e64=20 > (XEN) L1[0x05d] =3D 000000011be5d001 0000000000000e5d > (XEN) domain_crash_sync called from entry.S > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-3.4-unstable x86_64 debug=3Dy Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e019:[<00000000c056bd2f>] > (XEN) RFLAGS: 0000000000000287 EM: 1 CONTEXT: pv guest > (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: 000000000000= 0400 > (XEN) rdx: 00000000c0e5d000 rsi: 0000000000000000 rdi: 00000000c0e5= d000 > (XEN) rbp: 00000000c0555d84 rsp: 00000000c0555d68 r8: 000000000000= 0000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 000000000000= 0000 > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 000000000000= 0000 > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 000000000000= 06f0 > (XEN) cr3: 000000011ffb0000 cr2: 00000000c0e5d000 > (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 > > (gdb) disas 0x00000000c056bd2f > [...] > 0xc056bd2f : rep stos %eax,%es:(%edi) > > The rough stack trace seems to be (unabridged version below): > c056bd2f: alloc_low_page + 47 in section .init.text > c056bda8: one_page_table_init + 88 in section .init.text > c056cddb: kernel_physical_mapping_init + 571 in > section .init.text > c03dae40: init_memory_mapping + 800 in section .text > c055f656: setup_arch + 1014 in section .init.text > c055a7b6: start_kernel + 118 in section .init.text > c055a076: i386_start_kernel + 86 in section .init.text > c055d1cb: xen_start_kernel + 955 in section .init.text > =20 Interesting. Curiously its working for me on my machine, but has a=20 tendency to crash a bit later with a protection fault on an RO page=20 during memory allocation. I wonder if its related... J