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

Re: [Xen-devel] [qemu-upstream-4.11-testing test] 136184: regressions - FAIL


On 5/17/19 6:23 PM, Anthony PERARD wrote:
On Thu, May 16, 2019 at 10:38:54PM +0100, Julien Grall wrote:
Hi Anthony,

Thank you for CCing me.

On 5/16/19 11:37 AM, Anthony PERARD wrote:
On Wed, May 15, 2019 at 07:48:17PM +0000, osstest service owner wrote:
flight 136184 qemu-upstream-4.11-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
   build-arm64-pvops               <job status>                 broken  in 
   build-arm64                     <job status>                 broken  in 
   build-arm64-xsm                 <job status>                 broken  in 
   build-arm64-xsm            4 host-install(4) broken in 134594 REGR. vs. 
   build-arm64-pvops          4 host-install(4) broken in 134594 REGR. vs. 
   build-arm64                4 host-install(4) broken in 134594 REGR. vs. 
   test-arm64-arm64-libvirt-xsm  7 xen-boot                 fail REGR. vs. 
   test-arm64-arm64-xl           7 xen-boot                 fail REGR. vs. 
   test-arm64-arm64-xl-xsm       7 xen-boot                 fail REGR. vs. 
   test-arm64-arm64-xl-credit2   7 xen-boot                 fail REGR. vs. 

Ian, Julien,

I can't figure out why Xen consistently fails to boot on rochester* in
the qemu-upstream-4.11-testing flights. The xen-4.11-testing seems to

At boot, the boot loader seems to load blobs, but when it's time to Xen
to shine, there are no output from Xen on the serial.

The serial console is initializing fairly late in the process. Any useful
message (such as memory setup or even part of the interrupts) will be hide
out. For getting them, you need earlyprintk. Unfortunately they can't be
configured at runtime today :(.

I think I managed to run the job with earlyprintk on rochester, but
Xen have booted:

Yes this is with earlyprintk. That's going to be fun to reproduce if earlyprintk modifies the behavior.

I think we can interpret as earlyprintk add enough latency to make everything working.

There are two possible issues I can think of:
1) The boot code does not follow the Arm Arm, so it may be possible the board is doing something different compare to the other regarding the memory. IIRC, this is the first hardware we have with core not directly designed by Arm. 2) We are missing some errata in Xen. Linux contains 6 errata for that platform. Looking at them, I don't think they matter for boot time.

1) is currently been looked at (see MM-PART* patches on the ML). 2) should probably be addressed at some point, but I may not be able to send them as Arm employee (we tend to avoid sending patch showing brokenness in partner silicon).


Julien Grall

Xen-devel mailing list



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