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

[Jürgen Groß <jgross@xxxxxxxx>]

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