[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.