[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.