[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] OOPS new Xen 4.9.0_08 / kernel 4.12.0 Dom0 crash @ domain_crash_sync called from entry.S: fault at ffff82d080342328 entry.o#create_bounce_frame+0x135/0x14d
>>> On 05.07.17 at 02:14, <pgnet.dev@xxxxxxxxx> wrote: > On 7/4/17 12:54 PM, Andrew Cooper wrote: >> On 04/07/17 20:48, PGNet Dev wrote: >>> [ 0.000000] NX (Execute Disable) protection: active >>> [ 0.000000] efi: EFI v2.31 by American Megatrends >>> [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 >>> ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490 >>> (XEN) [2017-07-04 19:08:39] d0v0 Unhandled invalid opcode fault/trap >>> [#6, ec=ffffffff] >>> (XEN) [2017-07-04 19:08:39] domain_crash_sync called from entry.S: >>> fault at ffff82d080342328 entry.o#create_bounce_frame+0x135/0x14d >>> (XEN) [2017-07-04 19:08:39] Domain 0 (vcpu#0) crashed on cpu#0: >>> (XEN) [2017-07-04 19:08:39] ----[ Xen-4.9.0_08-512 x86_64 debug=n >>> Tainted: C ]---- >>> (XEN) [2017-07-04 19:08:39] CPU: 0 >>> (XEN) [2017-07-04 19:08:39] RIP: e033:[<ffffffff822b8e5b>] >> >> Please look up 0xffffffff822b8e5b in your dom0 kernel debug symbols. > > rpm -ql kernel-default-debuginfo | grep -i vmlinux > /usr/lib/debug/boot/vmlinux-4.12.0-2.gb8e7496-default.debug > > addr2line -e /usr/lib/debug/boot/vmlinux-4.12.0-2.gb8e7496-default.debug > ffffffff822b8e5b > > /usr/src/debug/kernel-default-4.12.0/linux-4.12/linux-obj/../mm/early_ioremap.c:137 > > cd /usr/src/linux > cat mm/early_ioremap.c > > ... > /* > * Mappings have to be page-aligned > */ > offset = offset_in_page(phys_addr); > phys_addr &= PAGE_MASK; > size = PAGE_ALIGN(last_addr + 1) - phys_addr; > > /* > * Mappings have to fit in the FIX_BTMAP area. > */ > nrpages = size >> PAGE_SHIFT; > 137 if (WARN_ON(nrpages > NR_FIX_BTMAPS)) > return NULL; So there are two problems here: One is the fact that the kernel really should put an Invalid Opcode exception handler in place before intentionally raising any such exceptions (which WARN() and WARN_ON() do). The other is that Linux commit 636259880a ("efi: Add support for seeding the RNG from a UEFI config table") failed to also update arch/x86/xen/efi.c, so the caller (efi_config_parse_tables()) tries to map a gigantic amount of memory, based on the value it found at NULL (which it then uses as the size to map). Luckily the fix for it is in Linus'es tree already - commit 6c64447ec5 ("x86/xen/efi: Initialize only the EFI struct members used by Xen"). It's marked for stable backport, but it fails to mention the commit it fixes. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |