Re: [Xen-devel] Xen 4.12.0-rc Hangs Around masked ExtINT on CPU#

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, May 27, 2019 at 03:35:21PM -0700, John L. Poole wrote:
> 
> On 5/27/2019 9:18 AM, Roger Pau Monné wrote:
> > On Mon, Apr 29, 2019 at 05:27:34PM +0200, Roger Pau Monné wrote:
> > > IMO it would be better if you can build directly from the upstream git
> > > repository [0], that way you could use git-bisect(1) in order to figure
> > > out which commit broke your system. For example:
> > > 
> > > # git clone git://xenbits.xen.org/xen.git
> > > # cd xen
> > > # git checkout RELEASE-4.7.0
> > > # make xen -j8
> > > 
> > > That should give you a set of Xen binaries in the xen/ directory, IIRC
> > > you are booting from EFI so you likely need xen/xen.efi.
> > > 
> > > If that works, then you can test RELEASE-4.8.0 and if that fails to
> > > boot you should have a range of commits that you can bisect in order
> > > to find the culprit.
> > FWIW, I've been unable to find a box with the same CPU model (C2750)
> > that you are using. I've found a couple of old Atom boxes using
> > different CPUs but they all seem to boot fine using latest
> > xen-unstable. I've looked on eBay for that CPU but everything
> > containing it is server-grade and >200$ which I'm sadly not going to
> > pay.
> > 
> > Unless you are able to bisect the tree and give us the bad commit
> > that's causing your issues I'm afraid at least myself I won't be able
> > to progress this any further, sorry.
> > 
> > Roger.
> I attempted to work backwards and ran into a nightmare with Gentoo.   I kept
> getting compiler errors which I suspect was a result of having a newer
> version
> of GCC and other things.  It's not an easy thing to travel
> back in time in Gentoo because everything keeps getting upgraded.  I just
> cannot make the time now to unravel this as I have some demands on my time
> and will be engaged for the next four to six weeks.

IMO your best bet is to build Xen using Debian stretch, that's used by
the Xen test system, and is likely to be able to build the different
Xen versions, stable-* branches tested by osstest should build on
stretch.

What I've done in the past if that also triggers compiler errors is to
build a chroot with an older version of Debian and then build Xen
inside of it. You can do this in a box different from the one you are
testing, ie: you could create a Debian VM and build Xen from there.

Note that in order to bisect this issue you only need to build the Xen
kernel (make xen, no need to run ./configure), there's no need to
build the tools, hence you need almost no dependencies installed on
the builder.

I've done a build of the stable-4.7 branch myself and uploaded the
hypervisor binaries to:

http://xenbits.xen.org/people/royger/stable-4.7/

Could you give those a try (I wasn't sure whether you need xen.gz or
xen.efi so I've uploaded both) and see if you still have issues
booting?

Testing those binaries should be as simple as placing them in /boot/
and fixing your bootloader configuration to boot from those. Please
send the serial log when booting from the provided binaries.

> How much would it cost for you to obtain the machine you need? I may
> consider paying for it. I bought this Atom server just to economically run
> Xen so the machine has marginal value to me if I cannot run Xen on it.

Even if we go that route, there's no guarantee that I would be able to
fix the issue, and there's also the possibility that the hardware you
have is somehow broken, and that the new one won't exhibit this issue.

Roger.

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