From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Marczykowski Subject: Re: High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x Date: Tue, 02 Apr 2013 03:13:56 +0200 Message-ID: <515A30D4.90003@invisiblethingslab.com> References: <5140E69F.9090803@invisiblethingslab.com> <20130315130240.GA8582@phenom.dumpdata.com> <514C79F3.5050504@invisiblethingslab.com> <20130322165651.GA4827@phenom.dumpdata.com> <515036BF.10105@invisiblethingslab.com> <20130325141701.GI11546@phenom.dumpdata.com> <515191CC.6060609@invisiblethingslab.com> <5151AC8C02000078000C88B9@nat28.tlf.novell.com> <5151A788.809@invisiblethingslab.com> <5151D4CC02000078000C8A1C@nat28.tlf.novell.com> <5151D0A9.7070100@invisiblethingslab.com> <5151D49C.2000809@citrix.com> <5151DE1C.1020307@invisiblethingslab.com> <5151E0D5.3050707@citrix.com> <5151E72D.30205@invisiblethingslab.com> <5151EE0B.9030605@citrix.com> <5152C16E02000078000C8CB8@nat28.tlf.novell.com> <515302C3.3000607@invisiblethingslab.com> <51547A5302000078000C962C@nat28.tlf.novell.com> <515493F0.6030708@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8117298458227123029==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ben Guthro Cc: Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8117298458227123029== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6370A6B16EF7AFEC38FA955C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6370A6B16EF7AFEC38FA955C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01.04.2013 15:53, Ben Guthro wrote: > On Thu, Mar 28, 2013 at 3:03 PM, Marek Marczykowski > wrote: >> (XEN) Restoring affinity for d2v3 >> (XEN) Assertion '!cpus_empty(cpus) && cpu_isset(cpu, cpus)' failed at >> sched_credit.c:481 >=20 >=20 > I think the "fix-suspend-scheduler-*" patches posted here are applicabl= e here: > http://markmail.org/message/llj3oyhgjzvw3t23 >=20 >=20 > Specifically, I think you need this bit: >=20 > diff --git a/xen/common/cpu.c b/xen/common/cpu.c > index 630881e..e20868c 100644 > --- a/xen/common/cpu.c > +++ b/xen/common/cpu.c > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include >=20 > unsigned int __read_mostly nr_cpu_ids =3D NR_CPUS; > #ifndef nr_cpumask_bits > @@ -212,6 +213,8 @@ void enable_nonboot_cpus(void) > BUG_ON(error =3D=3D -EBUSY); > printk("Error taking CPU%d up: %d\n", cpu, error); > } > + if (system_state =3D=3D SYS_STATE_resume) > + cpumask_set_cpu(cpu, cpupool0->cpu_valid); > } >=20 > cpumask_clear(&frozen_cpus); >=20 Indeed, this makes things better, but still not ideal. Now after resume all CPUs are in Pool-0, which is good. But CPU0 is much = more preferred than others (xl vcpu-list). For example if I start 4 busy loops= in dom0, I got (even after some time): [user@dom0 ~]$ xl vcpu-list Name ID VCPU CPU State Time(s) CPU Af= finity dom0 0 0 0 r-- 98.5 any cp= u dom0 0 1 0 --- 181.3 any cp= u dom0 0 2 2 r-- 262.4 any cp= u dom0 0 3 3 r-- 230.8 any cp= u netvm 1 0 0 -b- 18.4 any cp= u netvm 1 1 0 -b- 9.1 any cp= u netvm 1 2 0 -b- 7.1 any cp= u netvm 1 3 0 -b- 5.4 any cp= u firewallvm 2 0 0 -b- 10.7 any cp= u firewallvm 2 1 0 -b- 3.0 any cp= u firewallvm 2 2 0 -b- 2.5 any cp= u firewallvm 2 3 3 -b- 3.6 any cp= u If I remove some CPU from Pool-0 and re-add it, things back to normal for= this particular CPU (so I got two equally used CPUs) - to fully restore system= I must remove all but CPU0 from Pool-0 and add it again. Also still only CPU0 have all C-states (C0-C3), all others have only C0-C= 1. This probably could be fixed by your "xen: Re-upload processor PM data to= hypervisor after S3 resume" patch (reload of xen-acpi-processor module he= lps here). But I don't think it is a right way. It isn't necessary on other systems (with somehow older hardware). It must be something missing on re= sume path. The question is what... Perhaps someone need to go through enable_nonboot_cpus() (__cpu_up?) and = check if it restore all things disabled in disable_nonboot_cpus() (__cpu_disabl= e?). Unfortunately I don't know x86 details so good to follow that code... --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enig6370A6B16EF7AFEC38FA955C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWjDUAAoJENuP0xzK19cswOIH/iK8ulhVYK+fjWEpErIPRBMj 7A+GdBwgCDX2HevycWKw6Lv8fkv26DmPy5tIlC2hqf64X8s0Z/JePAudhulU3e6k fLECxuHkFh/8S4+QYMupLUA4k9DHWUfv2kmswh25ykoY0cEcxVvpTq+McYC2MwMc 1V3sxkczFikOv0PhwB1DvQ+xer1H6fHbgxty0r+RdQwyeu7ti8FFnUjJpdm9DHs9 A3t1WAXU6enjQRn8gYZhEvHfzuTyv4davGDTuvkxlsGOjY6wNzwGtqkGyKx5Vpyy VwXeSCeheHCOXcz3lga90N59/Ieu1OVhh3KC2UxpFQukTKnMY5pud+ynC8UuG6w= =7WYH -----END PGP SIGNATURE----- --------------enig6370A6B16EF7AFEC38FA955C-- --===============8117298458227123029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8117298458227123029==--