[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen4.2 S3 regression?
>>> On 25.09.12 at 17:45, Ben Guthro <ben@xxxxxxxxxx> wrote: > On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >> >>> On 25.09.12 at 16:22, Ben Guthro <ben@xxxxxxxxxx> wrote: >> > I went back to an old patch that had, since it was in this same function >> > that you made reference to: >> > http://markmail.org/message/qpnmiqzt5bngeejk >> > >> > I noticed that I was not seeing the "Breaking vcpu affinity" printk - so >> > I tried to get that >> > >> > The change proposed in that thread seems to work around this pinning >> > problem. >> > However, I'm not sure that it is the "right thing" to be doing. >> >> As said back then, the original change looks a little suspicious, >> and hence reverting it is certainly to be considered. > > Which is one of the reasons I brought it up again. So could you then do what I suggested back then - make a copy of the two involved CPU masks (*online and *vc->cpu_affinity) plus vc->domain->cpupool, vc->processor, and vc->vcpu_id into on-stack variables (ensuring they don't get eliminated by the compiler, e.g. by adding a read access anywhere after the triggering ASSERT())? Then the source change (i.e. the data layout) available, either together with the xen-syms, or put them into a structure together with some magic ID to identify where in the stack dump the interesting bits are. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |