Re: [xen-unstable test] 62646: tolerable FAIL - PUSHED

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-10-06 at 16:31 +0100, Ian Campbell wrote:
> On Mon, 2015-10-05 at 18:21 +0000, osstest service owner wrote:
> > flight 62646 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/62646/
> > 
> > Failures :-/ but no regressions.
> > 
> > Regressions which are regarded as allowable (not blocking):
> >  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm
> > -install fail like 62583
> >  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest
> > -localmigrate fail like 62583
> 
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i3
> 86-xl-qemut-stubdom-debianhvm-amd64-xsm/ALL.html
> paints a pretty sorry picture.
> 
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-am
> d64-xl-qemut-stubdom-debianhvm-amd64-xsm/ALL.html
> is not a lot better, but does occasionally pass.
> 
> It seems as if both suffer quite badly in the migration test cases.
> 
> Both also suffer from issues with the install phase, but the test-amd64
> -i386 case is much worse.

> 
[...]
> This is hampered somewhat by the lack of logging of the guest serial when
> stubdom is in use. For non-studom this ends up in the qemu log, for stubdom
> I'm not sure which blackhole it goes down.

I've sent a patch for this aspect, which once it is live may give us some
useful information.

While developing that patch I noticed during boot that there is a very long
pause after the bootloader has launched the kernel.

There is a spate of these:
    ACPI:debug: write addr=0xb045, val=0x89.
    ACPI:debug: write addr=0xb044, val=0xff.
but they are only for a fraction of the wait.

Turning off "quiet" and adding "debug" to the guest command line (which
I'll try and sort out to be automatic) I saw:

[    6.268069] XENBUS: Waiting for devices to initialise: 25s...20s...15s...10s...5s...0s...
[   31.268416] XENBUS: Device with no driver: device/vbd/768
[   31.270373] XENBUS: Device with no driver: device/vbd/5632
[   31.272549] XENBUS: Timeout connecting to device: device/vkbd/0 (local state 3, remote state 1)
[   31.275630] XENBUS: Device with no driver: device/vif/0

Which I suppose accounts for the delay.

Stefano, didn't you adjust something to do with vkbd in libxl not too long
ago?

I installed the Jessie kernel (from wheezy-backports) into the guest and
this delay was still present. (NB: my series upgrading osstest to use
Jessie doesn't cover the iso used by the debianhvm tests)

Disabling vnc in the guest config (vnc=0) made no difference.

Using vga="none" didn't appear to boot at all.

Ian.