[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Current staging crashes on boot on an AMD EPYC 7251
>>> On 21.09.18 at 12:48, <rcojocaru@xxxxxxxxxxxxxxx> wrote: > On 9/21/18 1:41 PM, Jan Beulich wrote: >>>>> On 21.09.18 at 12:15, <roger.pau@xxxxxxxxxx> wrote: >>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote: >>>> While doing my best to make sure what I understand to be George's >>>> proposed changes for the altp2m series I've tried to boot Xen staging on >>>> an AMD host, but it crashes in an unrelated place (I've tested this by >>>> stashing my changes and booting a "vanilla" staging): >>> >>> Can you apply the following debug patch and paste the full boot log? >> >> Well, not having provided the full boot log right away is clearly >> unhelpful, as from that alone we should be able to tell what's >> going on here (unless we e.g. screw up the E820 map somewhere). >> However, it is already clear that ... >> >>> --- a/xen/arch/x86/mm.c >>> +++ b/xen/arch/x86/mm.c >>> @@ -465,6 +465,8 @@ unsigned int page_get_ram_type(mfn_t mfn) >>> break; >>> >>> default: >>> +printk("[%#lx, %#lx) type: %u\n", e820.map[i].addr, >>> + e820.map[i].addr + e820.map[i].size, e820.map[i].type); >>> ASSERT_UNREACHABLE(); >> >> ... this assertion needs to go away, as it would trigger for both >> E820_TYPE_PMEM and E820_TYPE_PRAM (using the Linux >> naming), or the unnamed type 6 mentioned in their header. It >> would also trigger for types which may get added down the road. > > I have attached the full log, as requested by Roger. And there we go: (XEN) 00000000dabf2000 - 00000000dacdf000 type 20 Whatever that is. I think for the purposes of the function here all unknown types should be mapped into UNUSABLE. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |