[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 25949: regressions - trouble: broken/fail/pass
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@xxxxxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |