On Wed, 20 May 2015, Major Hayden wrote:
> On 05/20/2015 05:41 AM, Jan Beulich wrote:
> > Considering that no-one else is seeing this - is this perhaps connected
> > to you building Xen with pre-release gcc 5.0.1? This is also because in
> > order for the above to indeed occur, mmio_ro_do_page_fault()'s
> > put_page() would need to drop the last reference of a page, yet
> > page_get_owner_and_reference() doesn't obtain a reference when
> > a page is unallocated (and hence unowned), i.e. normally a page
> > would have a refcount of at least 2 here. Hence this would be
> > possible only due to a race, but the exact same race to be observed
> > on different hardware _and_ under an emulator is extremely unlikely.
You could try with the xen.gz file from
https://copr-be.cloud.fedoraproject.org/results/myoung/xentest/fedora-21-x86_64/xen-4.5.1-0.rc1.fc21/xen-hypervisor-4.5.1-0.rc1.fc21.x86_64.rpm
It is roughly the same version of xen but built against Fedora 21 and gcc
4.9.2. If that works then it probably is gcc 5.
Greetings,
I have run into pretty much the same issue as the original poster.
I am running a recently updated Arch Linux system, with GCC 5.1.0, using UEFI and gummiboot to boot. I currently have a build of Xen 4.4.1, built with GCC 4.9.2 from before my last update, that is functioning correctly on this machine. But the builds of Xen 4.5.0, using GCC 5 and mingw64-binutils for the EFI binary, are all failing when Xen starts the Linux kernel, with the same error mentioned in the subject. Below is the boot log I captured via the serial port.
Wondering if my specific toolchain was the issue, I downloaded the Fedora 22 version of xen-hypervisor and installed its EFI Xen binary over my compiled binary and received an identical error message, with slightly different addresses in the panic dump. The Fedora version was compiled with GCC 5.0.1. Below is the boot log I captured from that binary.
After finding this thread, and specifically, the quoted message above, I downloaded that xen-hypervisor package and installed its EFI Xen binary. That binary boots successfully, as seen by the captured boot log below.
So, while Iâm not familiar enough with Xen to begin to have an idea of what could possibly be wrong with Xen or GCC 5 to be causing this bug, Iâd like to do what I can to track down the issue so I can get a working build of Xen 4.5. :)
Thanks!
â Jason Fritcher
|
