[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it
On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote: > On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote: > > On Wed, Aug 07, 2019 at 04:45:43PM +0200, Jan Beulich wrote: > > > On 07.08.2019 15:26, Marek Marczykowski-Górecki wrote: > > > > Hi, > > > > > > > > Xen 4.12 crashes when booting on UEFI (with multiboot2) unless I disable > > > > runtime services. The crash happens shortly after starting dom0 kernel. > > > > Unfortunately I don't have serial console there, so the only log I have > > > > is a photo of VGA console (attached). Below I retype part of the > > > > message: > > > > > > > > (XEN) ----[ Xen-4.12.0-3.fc29 x86_64 debug=n Not tainted ]---- > > > > (XEN) CPU: 0 > > > > (XEN) RIP: e008:[<00000000000000f6>] 00000000000000f6 > > > > (XEN) RFLAGS: 0000000000010287 CONTEXT: hypervisor (d0v0) > > > > ... > > > > (XEN) Xen call trace: > > > > (XEN) [<00000000000000f6>] 00000000000000f6 > > > > (XEN) [<ffff82d08026c6ad>] flushtlb.c#pre_flush+0x3d/0x80 > > > > (XEN) [ ] efi_runtime_call+0x493/0xbd0 > > > > (XEN) [ ] efi_runtime_call+0x441/0xbd0 > > > > (XEN) [ ] vcpu_restore_fpu_nonlazy+0xe7/0x180 > > > > (XEN) [ ] do_platform_op+0/0x1880 > > > > (XEN) [ ] do_platform_op+0xb9c/0x1880 > > > > (XEN) [ ] do_platform_op+0xb9c/0x1880 > > > > (XEN) [ ] > > > > sched_credit2.c#csched2_schedule+0xcd0/0x13a0 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] do_platform_op+0/0x1880 > > > > (XEN) [ ] pv_hypercall+0x152/0x220 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] lstar_enter+0xa2/0x120 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] lstar_enter+0xa2/0x120 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] lstar_enter+0xa2/0x120 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] lstar_enter+0xa2/0x120 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] lstar_enter+0xa2/0x120 > > > > (XEN) [ ] lstar_enter+0xae/0x120 > > > > (XEN) [ ] lstar_enter+0x10c/0x120 > > > > (XEN) > > > > (XEN) > > > > (XEN) ***************************************** > > > > (XEN) Panic on CPU 0: > > > > (XEN) FATAL TRAP: vector = 0 (divide error) > > > > (XEN) [error_code=0000] > > > > (XEN) ***************************************** > > > > > > > > Any idea? Lack of serial console doesn't help with collecting logs... > > > > > > May I suggest that you repeat this with a debug hypervisor, such that > > > the call trace becomes more usable/sensible? > > > > Actually, I've already tried, but every other build I try, I get even > > less useful call trace, for example debug unstable build: > > > > Xen call trace: > > [<000000007b751c09>] 000000007b751c09 > > [<8c2b0398e0000daa>] 8c2b0398e0000daa > > ... > > GENERAL PROTECTION FAULT > > [error_code=0000] > > But this makes reasonable sense: The faulting insn is "call *0x18(%rax)" > and %rax is 6954b2b0, which points into a block of type > EfiBootServicesData (and hence likely reused by the time of the crash > for other purposes). Hence the "/mapbs" option of xen.efi might help > here too, but iirc there's no equivalent for it in the MB2 case. Oh, yes, indeed in Qubes we have /mapbs enabled by default with xen.efi. I'd like to add it to MB2 case too. Is command line parsed at this point (efi_exit_boot()) already? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |