Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

xen.org writes ("[xen-unstable test] 11574: tolerable FAIL"):
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-win           7 windows-install             fail pass in 
> 11561

This is a host-specific, but deterministic, failure.  My bisector has
been working on it (the basis pass was in November so there has been a
lot of ground to cover and I had to make some new arrangements to be
able to run an ad-hoc bisection of this problem) and the results so
far are fingering changesets between 24367:537ceb11d51e (bad) and
24362:d35bedf334f2 (good).

Extract from hg log -v is below.

I have looked at the logs of one of these failures and there is
nothing of note.  The screenshot shows the Windows screensaver, so I
guess neither the guest itself nor qemu have crashed.  The likely
situation is either that the guest has somehow locked up and ceased to
make progress, or that the networking is nonfunctional.

I'm expecting the bisector to finger a specific changeset and will let
you know when it does, but this will take some more hours and maybe
only finish overnight or tomorrow.

Ian.

changeset:   24367:537ceb11d51e
user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
date:        Tue Dec 06 20:31:49 2011 +0000
files:       xen/arch/x86/hvm/hvm.c
description:
Improve handling of nested page faults

Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Acked-by: Tim Deegan <tim@xxxxxxx>
Committed-by: Tim Deegan <tim@xxxxxxx>


changeset:   24366:534b2a15e669
user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_sharing.c xen/arch/x86/mm/p2m.c 
xen/include/public/mem_event.h
description:
x86/mm: Allow dummy responses on the mem_event ring.

Ring semantics require that for every request, a response be put. This
allows consumer to place a dummy response if need be.

Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Signed-off-by: Tim Deegan <tim@xxxxxxx>
Committed-by: Tim Deegan <tim@xxxxxxx>


changeset:   24365:c65d1a9769b4
user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_event.c xen/arch/x86/mm/mem_sharing.c 
xen/arch/x86/mm/p2m.c xen/include/asm-x86/mem_event.h
description:
x86/mm: Consume multiple mem event responses off the ring

Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Signed-off-by: Adin Scannell <adin@xxxxxxxxxxx>
Acked-by: Tim Deegan <tim@xxxxxxx>
Committed-by: Tim Deegan <tim@xxxxxxx>


changeset:   24364:0964341efd65
user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_event.c
description:
x86/mm: Allow memevent responses to be signaled via the event channel

Don't require a separate domctl to notify the memevent interface that an event
has occured.  This domctl can be taxing, particularly when you are scaling
events and paging to many domains across a single system.  Instead, we use the
existing event channel to signal when we place something in the ring (as per
normal ring operation).

Signed-off-by: Adin Scannell <adin@xxxxxxxxxxx>
Signed-off-by: Keir Fraser <keir@xxxxxxx>
Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Acked-by: Tim Deegan <tim@xxxxxxx>
Committed-by: Tim Deegan <tim@xxxxxxx>


changeset:   24363:1620291f0c4a
user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/ia64/vmx/vmx_init.c xen/arch/x86/hvm/hvm.c 
xen/arch/x86/mm/mem_event.c xen/common/event_channel.c xen/include/xen/event.h 
xen/include/xen/sched.h
description:
Create a generic callback mechanism for  Xen-bound event channels

For event channels for which Xen is the consumer, there currently is
a single action. With this patch, we allow event channel creators to
specify a generic callback (or no callback). Because the expectation
is that there will be few callbacks, they are stored in a small table.

Signed-off-by: Adin Scannell <adin@xxxxxxxxxxx>
Signed-off-by: Keir Fraser <keir@xxxxxxx>
Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Committed-by: Tim Deegan <tim@xxxxxxx>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel