Re: [xen-4.4-testing test] 25979: regressions - FAIL

["Jan Beulich" <JBeulich@suse.com>]

>>> On 25.04.14 at 13:46, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-04-25 at 12:34 +0100, Jan Beulich wrote:
>> >>> On 25.04.14 at 13:11, <Ian.Jackson@eu.citrix.com> wrote:
>> > flight 25979 xen-4.4-testing real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/ 
>> > 
>> > Regressions :-(
>> > 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 
> 25794
>> 
>> This has been failing for the last several runs, yet again without
>> me being able to see anything suspicious in the logs. The screen
>> shots of the guest suggest it came mostly up, but may still be
>> doing something before being fully up. Yet again, just like noted
>> for one of the -unstable failures recently, the 4th boot of the
>> guest is suspiciously close to the 7000s timeout...
> 
> The diff between 25794 and now is:
>         139a62e xen/arm: vgic: Check rank in GICD_ICFGR* emulation before locking
>         fc070bc xen: x86 & generic: change to __builtin_prefetch()
>         cbd5a0c x86/mm: fix checks against max_mapped_pfn
>         da8e158 xen/arm: Don't let guess access to Debug and Performance Monitor regist
>         8f416fc xen/arm: Don't expose implementation defined registers (Cp15 c15) to th
>         4642a21 xen/arm: Trap cache and TCM lockdown registers
>         16ef39e xen/arm: Upgrade DCISW into DCCISW
>         9800bfa xen/arm: Don't let the guest access the coprocessors registers
>         ed13367 xen/arm: Inject an undefined instruction when the coproc/sysreg is not 
>         
> Most of which is irrelevant to an x86 test. Unless fc070bc (unlikely) or
> cbd5a0c (I cannot judge) made windows installs slower?
> 
> How long did the fourth boot take in 25794 I wonder?

6247s (ran on lace-bug)

> The other possibility is that this is host specific, and that lake-frog
> is just slow compared with other machines. Since osstest is sticky to
> hosts on failures all the tests since the initial failure in 25958 have
> been on the same host.
> 
> Unfortunately my osstest db-fu isn't really up to datamining the history
> of this test case on various machines. Ian J is away for a few days,
> perhaps he can take a look at this aspect when he gets back?

Yes, I think we should wait for him to take a look before becoming
too worried (and I think we're seeing this test routinely fail on
-unstable too).

Jan