Re: [Xen-devel] [xen-unstable test] 13866: regressions - trouble: broken/fail/pass

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.12 at 09:32, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 26.09.12 at 00:57, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
>> flight 13866 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 
>> 13825
>>  test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 
>> 13825
>>  test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 
>> 13825
>>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 
>> 13825
> 
> Looking (as an example) at this failure's log, I can't see what's
> wrong at all - the log suggests that boot completed fine.
> 
> The host, Dom0, and run queue state dumps also don't hint at
> anything being stuck (like wakeups from deep C states not
> happening).
> 
> Nevertheless, the MWAIT idle driver is to be suspected most.
> I'm considering defaulting it to off for now (maybe just for the
> non-ARAT case that I'm not able to test myself), but the issue
> I see with this is that this may then continue to be that way
> forever, if no-one gets to actually look at the problem.

One of the three boxes I have using this new idle driver, when
suppressing ARAT detection, actually exhibits intermittent (but
frequent) hangs, so I apparently now have found a way to
debug what's going on. I'll send a patch in a minute disabling the
feature by default when ARAT isn't there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel