On Fri, Feb 08, 2019 at 05:21:44AM +0000, osstest service owner wrote:
> flight 133030 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/133030/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-xsm <job status> broken
> build-arm64-xsm 4 host-install(4) broken REGR. vs.
> 133005
After some investigation, I think something is wrong with the linux-4.9
branch.
The issue to hand is:
Feb 8 04:12:54.790904
Loading initial ramdisk ...
Feb 8 04:12:55.114864
EFI stub: Booting Linux Kernel...
Feb 8 04:12:55.354885 EFI stub: ERROR: Failed to alloc kernel memory
Feb 8 04:12:55.354946 EFI stub: ERROR: Failed to relocate kernel
Feb 8 04:12:55.354993 Feb 8 04:12:55.355016
Failed to boot both default and fallback entries.
The new 4.9 kernel can't be loaded _natively_ anymore.
But why did it pass its own pushgate in the first place?
That latest push to that branch is in 132748. There isn't any
serial-laxton*.log in its logs. So my conclusion is that that changeset
was built on a shared build host which ran a _previous_ version of Linux
4.9. And then, other test cases in the same flight loaded xen first,
which didn't cause any issue. The Linux changeset under test passed
pushgate.
But after a changeset passes pushgate, it becomes the new baseline. The
new baseline can't be booted _natively_ anymore.
I think someone more familiar with Arm / EFI will need to look into
fixing Linux 4.9 on laxton.
Wei.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
