On Wed, 2017-02-22 at 01:46 -0700, Jan Beulich wrote:
> > > > On 22.02.17 at 01:02, <andrew.coop...@citrix.com> 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)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
