Hi,
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]
http://logs.test-lab.xenproject.org/osstest/logs/136184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops <job status> broken in
134594
build-arm64 <job status> broken in
134594
build-arm64-xsm <job status> broken in
134594
build-arm64-xsm 4 host-install(4) broken in 134594 REGR. vs.
125575
build-arm64-pvops 4 host-install(4) broken in 134594 REGR. vs.
125575
build-arm64 4 host-install(4) broken in 134594 REGR. vs.
125575
test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs.
125575
test-arm64-arm64-xl 7 xen-boot fail REGR. vs.
125575
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs.
125575
test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs.
125575
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
pass.
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:
http://logs.test-lab.xenproject.org/osstest/logs/136451/
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).
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel