Hi Juergen,
On 13/12/2019 08:31, Jürgen Groß wrote:
On 12.12.19 23:35, osstest service owner wrote:
flight 144736 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 7 xen-boot fail REGR.
vs. 144673
Looking into the serial log this looks like a hardware problem to me.
Looking at [1], the board were able to pick up new job. So I would
assume this just a temporary failure.
AMD Seattle boards (laxton*) are known to fail booting time to time
because of PCI training issue. We have workaround for it (involving
longer power cycle) but this is not 100% reliable.
Ian, do you agree?
test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR.
vs. 144673
That one is strange. A qemu process seems to have have died producing
a core file, but I couldn't find any log containing any other indication
of a crashed program.
I haven't found anything interesting in the log. @Ian could you set up
a repro for this?
For the future, it would be worth considering to collect core files.
And I can't believe the ARM changes in the hypervisor would result in
qemu crashing now...
I have seen weird behavior happening in Dom0 because of changes in Xen
before. :) For instance, get_cycles() was wrongly implemented and
resulted to network loss.
Anyway, QEMU is the same as the previous flight. The only difference
here is in Xen:
d8538f71edc954f8c518de2f9cc9ae89ee05f6a1
x86+Arm32: make find_next_{,zero_}bit() have well defined behavior
Julien, could you please have a look?
I don't have much idea what's happening. A repro would useful to be able
to do more debug.
Cheers,
[1] http://logs.test-lab.xenproject.org/osstest/results/host/laxton0.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel