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. :)
