Re: [Xen-devel] Latest development (master) Xen fails to boot on HP ProLiant DL20 GEN10

[Roman Shaposhnik <roman@xxxxxxxxxx>]

Jan, Roger, thank you so much for the initial ideas. I tried a few of
those and here's where I am.

First of all, it is definitely related to CPU bring up. Adding
cpuidle=0 to xen command line made Xen boot.

Then, a good friend of mine (who you may know from ancient Xen days
;-)) suggested that this could be related to this:
     https://wiki.xenproject.org/wiki/Xen_power_management
so I went to the BIOS settings and quite to my surprise all of them
were grayed out (not tweakable).

The only one that wasn't was 2xAPIC support. So just for kicks -- I
disabled that.

That, in turn, made Xen boot even without cpuidle=0. I'm attaching that log.

So I guess at this point, you could say that I have a functional
system, but I'm curious whether you guys would be interested to look
into 2xAPIC situation.

Please let me know.

Thanks,
Roman.

On Wed, Sep 25, 2019 at 2:01 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 24.09.2019 20:20, Roman Shaposhnik wrote:
> > I'm a bit at a loss of what's happening here, but it seems that
> > the latest Xen from master fails to boot on HP ProLiant DL20
> > GEN10 server (same Xen boots fine on every other piece of
> > hardware in my lab).
>
> First of all - is this known to be a regression, i.e. is older
> Xen known to work on this particular hardware?
>
> > There are absolutely no signs of what's going wrong with it.
> > It just stops at
> >
> > (XEN) HVM: ASIDs enabled.
> > (XEN) HVM: VMX enabled
> > (XEN) HVM: Hardware Assisted Paging (HAP) detected
> > (XEN) HVM: HAP page sizes: 4kb, 2MB, 1GB
> > ...
> > (XEN) Adding cpu 1 to runqueue 0
> > (XEN) mwait-idle: max C-state count of 8 reached
> > (XEN) Adding cpu 2 to runqueue 0
> > (XEN) mwait-idle: max C-state count of 8 reached
> >
> > I guess the only clue is that your typical line of:
> >
> > (XEN) Brought up X CPUs
> >
> > never gets printed -- so perhaps there's something wonky
> > going on with CPU initialization.
> >
> > Any advice on how to diagnose this further will be greatly appreciated.
>
> Second, as always, a complete log will already help, e.g. by allowing
> us to see what CPU model it is that's in the system. Iirc there was a
> similar report for a certain Atom variant, but I assume it's a Skylake
> here. Maximum verbosity (loglvl=all) and extra CPU related output
> ("cpuinfo") should be enabled for this.
>
> Furthermore, while I don't think the (bogus; I'll make a patch in a
> minute) mwait-idle message is related, excluding there to be an effect
> would be a helpful extra data point ("cpuidle=0" for simplicity).
>
> Another potentially useful experiment would be to limit the number of
> CPUs to boot ("nosmp" should boot fine in any case, so "maxcpus="
> would be what you'd want to play with), and to override the default
> of whether to park secondary hyperthreads ("smt=0" and "smt=1").
>
> Jan

Attachment: dmesg.linux
Description: Binary data

Attachment: dmesg.xen
Description: Binary data

Attachment: xl.info
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel