[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 06:34:09PM +0200, Jan Beulich wrote: > On 07.08.2019 18:04, Marek Marczykowski-Górecki wrote: > > On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan Beulich wrote: > > > On 07.08.2019 17:51, Marek Marczykowski-Górecki wrote: > > > > On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote: > > > > > On 07.08.2019 17:17, Marek Marczykowski-Górecki wrote: > > > > > > 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? > > > > > > I'm struggling a little how to reply, considering that I've already > > > said "iirc there's no equivalent for it in the MB2 case". So I guess > > > I'm simply not understanding your question, or more specifically > > > where you want to get with it. > > > > /mapbs option is very specific to xen.efi. I'd like to add a means to > > set map_bs variable in MB2 case too. I'm asking whether I can use > > standard command line parser, or do I need something special extracting > > it from MB2 structures directly. > > Well, efi_multiboot2() gets called from head.S, even before the > (non-EFI only) cmdline_parse_early. I don't suppose there's a way > to avoid mixing this new option into the "normal" command line, > and hence there's also no way around peeking into the command > line early. Of course there's the option to see whether what > efi_arch_process_memory_map() could be deferred until later. But > likely that would be a far more intrusive change than what you're > considering to carry out. Ok, regardless of adding proper option for that, I've hardcoded map_bs=1 and it still crashes, just slightly differently: Xen call trace: [<0000000000000080>] 0000000000000080 [<8c2b0398e0000daa>] 8c2b0398e0000daa Pagetable walk from ffffffff858483a1: L4[0x1ff] = 0000000000000000 ffffffffffffffff **************************************** Panic on CPU 0: FATAL PAGE FAULT [error_code=0002] Faulting linear address: ffffffff858483a1 **************************************** Full message attached. -- 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:
unstable-crash-map-bs.jpg 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 |