Re: [Xen-devel] [xen-unstable-smoke test] 133030: trouble: blocked/broken/pass

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel