Re: [xen-unstable test] 25949: regressions - trouble: broken/fail/pass

[David Vrabel <david.vrabel@citrix.com>]

On 24/04/14 12:15, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 25949: regressions - trouble: broken/fail/pass"):
>>>>> On 23.04.14 at 03:08, <Ian.Jackson@eu.citrix.com> wrote:
>>> flight 25949 xen-unstable real [real]
>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/25949/ 
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot fail REGR. vs. 25945
>>
>> The log appears to show that Dom0 booted up fine - were there any
>> infrastructure problems (also taking into consideration the broken
>> host-install above)?
> 
> Actually, the serial log shows a problem.
> 
> Firstly, timing.  Unfortunately there is a discrepancy in the
> timestamps because the new osstest vm didn't have ntp installed (now
> fixed).  I'm going to suffix osstest vm timestamps with [o] and serial
> log timestamps with [l].
> 
> 18:10:41[o] is when osstest timed out waiting for
> the system's boot scripts to complete.  It had been waiting since
> 18:08:59[o], which is when the sshd started accepting connections on
> port 22 (all of this is from 5.ts-host-reboot.log).
> 
> At 18:10:42[o] osstest sends the first debug keys, requesting serial
> input to go to xen (this is from 6.ts-logs-capture.log).  You can see
> this in the serial log at 18:10:19[l] (in serial-grain-weevil.log).
> 
> In the serial log you can see that the host has in fact not finished
> booting by this time.  osstest requests a whole bunch of debug keys
> from Xen until 18:11:07[l], at which point it sends a debug key
> request that is responded to by the dom0 kernel.  About 11 seconds
> later, at 18:11:18[l], the dom0 finally prints its login prompt.
> 
> So I think in fact the dom0 kernel was stuck somehow and being prodded
> woke it up.  Either that or it was running unconscionably slowly.
> 
> A network problem isn't a very good explanation for this failure
> because by this point dom0 has been configured to use a static IP
> address rather than dhcp.

Stating ntp appears to be stuck.  Could this is fallout from Tuesday's
lab firewall snafu?

David