[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.12.0-rc Hangs Around masked ExtINT on CPU#
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |