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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL


On 01/26/2017 09:11 PM, Julien Grall wrote:

On 26/01/2017 19:01, Boris Ostrovsky wrote:
On 01/26/2017 12:18 PM, Ian Jackson wrote:
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684:
regressions - FAIL"):
On 01/26/2017 08:23 AM, osstest service owner wrote:
flight 104684 linux-linus real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           6 xen-boot          fail REGR. vs.
I don't see why ARM tests fail. But then I also don't see (in the
log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
but there it nothing coming to the console from it.

Unfortunately the osstest bisector is having some trouble with this
because the basis revision combination includes Xen f3a7ca02400d which
is ancient and doesn't build now on armhf, although it built before.
(I think the difference is that the compiler has been updated by

Since there is no output from Xen, I think this must be a problem with
the Xen image, not anything to do with Linux.

The history for this test is here:


In xen-unstable, there is what looks like a different failure:


The machine in 104684 is cubietruck-metzinger which seems fine:


I am probably not interpreting  results correctly but 104684 looks like
failed to me:


And 104681's failure looks exactly like 104684.

I agree here. I think Ian got confused because the cubietruck is used to
build Xen.

Here are the histories on the linux-linus and xen-unstable branches:



I think there may be a host-specific bug in ARM in xen-unstable ?

So the problem with linux-linus is the path in the DeviceTree for the
serial has been changed by commit 5d99cc5 "ARM: dts: exynos: Move
Exynos5250 and Exynos5420 nodes under soc". Before the path was
/serial@12C20000, now it is /soc/serial@12C20000.

From my understanding, osstest is testing 3.18 and onwards. Correct?

If so, all the device tree we care have the same alias name to the
serial node. I would use it to get avoid specific command line option
depending on the kernel.

Replacing on xen command line "dtuart=/serial@12C20000" by
"dtuart=serial0" will allow Xen to be able to use again the console.

I have looked at osstest git [1] and was not able to find where the configuration for the Arndale.

Can someone knowing Osstest look at it? This would unblock linux-linus test on ARM.

Regarding xen-unstable, I spot in the log a lot of "asix 2-3.2.4:1.0
eth0: link down". So this looks like an ethernet issue. IIRC the network
dongle on the Arndale has always been unreliable. So I would not worry
too much here and wait the next flight.


[1] http://xenbits.xen.org/gitweb/?p=osstest.git;a=summary

Julien Grall

Xen-devel mailing list



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