Re: [Xen-devel] [xen-4.7-testing test] 105948: regressions - FAIL

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Wed, 2017-02-22 at 01:46 -0700, Jan Beulich wrote:
> > > > On 22.02.17 at 01:02, <andrew.cooper3@xxxxxxxxxx> wrote:
> > (XEN) ****************************************
> > (XEN) Panic on CPU 14:
> > (XEN) Assertion 'd->cpupool != NULL' failed at
> > ...5948.build-amd64/xen/xen/include/xen/sched-if.h:200
> > (XEN) ****************************************
> > (XEN)
> > (XEN) Manual reset required ('noreboot' specified)
> > 
> > I am guessing the most recent credit2 backports weren't quite so
> > safe?
> 
> Well, there was only one in the batch under test (and that is what
> adds the cpupool_domain_cpumask() causing the ASSERT() above
> to trigger). However, comparing with the staging version of the file
> (which is heavily different), the immediate code involved here isn't
> all that different, so I wonder whether (a) this is a problem on
> staging too or (b) we're missing another backport. Dario?
>
Sorry I'm a bit late. But I wasn't feeling too well today, so I
couldn't work much.

In any case, I managed to reproduce this (with staging-4.7) on my
testbox, and I think I've understood what it is (Credit2's load
balancer is considering the original domain, which is in the process of
being destroyed, and hence already has d->cpupool==NULL).

I should be able to put together a patch quickly tomorrow.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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