|
[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 |