|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: xen/stable 2.6.32.9 32bit dom0 kernel crashes early on b
On Thu, Mar 18, 2010 at 04:32:10PM -0700, Jeremy Fitzhardinge wrote:
> On 03/04/2010 11:53 AM, Pasi Kärkkäinen wrote:
>> Hello,
>>
>> 32bit PAE 2.6.32.9 xen/stable dom0 kernel crashes early on my (old) testbox..
>>
>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-xen-stable-2.6.32.9-32b-crash-log01.txt
>>
>> ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
>> ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
>> ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
>> ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
>> ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
>> (XEN) mm.c:1746:d0 Bad L1 flags 80000100
>> (XEN) mm.c:778:d0 Bad L1 flags 80000100
>> (XEN) mm.c:4637:d0 ptwr_emulate: could not get_page_from_l1e()
>> (XEN) d0:v0: unhandled page fault (ec=0003)
>> (XEN) Pagetable walk from c0259fd0:
>> (XEN) L3[0x003] = 000000003c912001 00000912
>> (XEN) L2[0x001] = 000000003d3b6067 000013b6
>> (XEN) L1[0x059] = 000000003c259061 00000259
>> (XEN) domain_crash_sync called from entry.S (ff1cb962)
>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) ----[ Xen-4.0.0-rc5 x86_32p debug=y Not tainted ]----
>> (XEN) CPU: 0
>> (XEN) EIP: e019:[<c0405dbe>]
>> (XEN) EFLAGS: 00000296 EM: 1 CONTEXT: pv guest
>> (XEN) eax: 00000000 ebx: c0259fd0 ecx: 80000000 edx: 3c913163
>> (XEN) esi: 80000000 edi: 00000000 ebp: c0848e54 esp: c0848e34
>> (XEN) cr0: 8005003b cr4: 000006f0 cr3: 00bc6c80 cr2: c0259fd0
>> (XEN) ds: e021 es: e021 fs: 00d8 gs: 0000 ss: e021 cs: e019
>> (XEN) Guest stack trace from esp=c0848e34:
>> (XEN) 00000003 c0405dbe 0001e019 00010096 3c913163 deadbeef deadbeef
>> f57fa000
>> (XEN) c0848e74 c0405f1c c0259fd0 80000000 3c913163 80000000 c0259fd0
>> f57fa000
>> (XEN) c0848e98 c04281f9 3c913163 80000000 80000000 00913163 00005000
>> f57ff000
>> (XEN) 0000017b c0848ea8 c042747f 00000005 80000000 c0848ec4 c0404f98
>> c07c3370
>> (XEN) c0848ec4 00000000 00000000 00000004 c0848ee0 c089aeec 0000017b
>> 80000000
>> (XEN) f55002cc f55002cc c07c3370 c0848eec c0895f7a 00000001 c0848f10
>> c08ad384
>> (XEN) f5500310 00000001 00000090 f5500280 00000000 00000000 c12aea00
>> c0848f20
>> (XEN) c08ad3fa c0895f4d 00000040 c0848f30 c089650f 168ff000 2d1fe000
>> c0848fac
>> (XEN) c088f56a 00000000 00000000 012aea00 00000000 00000000 00ad5000
>> 00000000
>> (XEN) c0848f60 00000092 00000000 2d1fe000 00000000 40000000 00000000
>> c0945be4
>> (XEN) 00000000 00000000 00000000 00000000 c085ab8c c0848f9c c04063b6
>> 00000000
>> (XEN) 00000000 00000000 00000000 00000000 00000000 c085ab8c c0848fc4
>> c088a5bd
>> (XEN) c07b9c5c c06e8010 c08bfb44 00ad5000 c0848fd4 c088a0a8 00ad5000
>> c08be930
>> (XEN) c0848ffc c088d113 1fc89375 80000401 00010800 00000f34 00000001
>> 00000000
>> (XEN) c13af000 00000000 00000000 3d3b1001 00000000 3d3b2001 00000000
>> 3d3b3001
>> (XEN) 00000000 3c912001 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
>>
>>
>>
>> (gdb) x/i 0xc0405dbe
>> 0xc0405dbe<xen_set_pte+137>: mov %edx,(%ebx)
>>
>> (gdb) list *0xc0405dbe
>> 0xc0405dbe is in xen_set_pte (arch/x86/xen/mmu.c:703).
>> 698 ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() ==
>> PARAVIRT_LAZY_MMU);
>> 699
>> 700 #ifdef CONFIG_X86_PAE
>> 701 ptep->pte_high = pte.pte_high;
>> 702 smp_wmb();
>> 703 ptep->pte_low = pte.pte_low;
>> 704 #else
>> 705 *ptep = pte;
>> 706 #endif
>> 707 }
>>
>
> Xen is 32 bit, right?
>
Yes, this is an old box that is not 64bit capable.
It's running 32bit PAE Xen 4.0.0-rc6 hypervisor.
> Could you disassemble this whole function, so I can see what register
> the other half is in? (I'm guessing its ecx or esi; nothing else makes
> much sense.)
>
> Could you also try to work out at least some of the call stack to see
> what is trying to set a pte? The presence of _PAGE_UNUSED1 suggests its
> the CPA test. If so, you could try disabling that (CONFIG_CPA_DEBUG).
>
Ok, I'll check these when I have access to the box again.
-- Pasi
> Keir, 32-bit Xen isn't reserving bit 9 in the PTE is it? It just uses
> the high user bits?
>
> Thanks,
> J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|