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

Re: [Xen-devel] [xen-4.13-testing test] 144736: regressions - FAIL



On 13.12.19 12:14, Julien Grall wrote:
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.

I guess repeating the power cycle should work, too (especially as the
new job did work as you said)?



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.

OSStest does:

http://logs.test-lab.xenproject.org/osstest/logs/144736/test-armhf-armhf-xl-vhd/cubietruck-metzinger---var-core-1576147280.1979.qemu-system-i38.core.gz



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

Right, that was what I meant. :-)


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


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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