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: Thu, 28 Mar 2013 18:09:59 +0100 Message-ID: <51547967.1080300@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> <51547D0B02000078000C9672@nat28.tlf.novell.com> <51547066.8070305@invisiblethingslab.com> <5154834202000078000C96DD@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2358557764575689490==" Return-path: In-Reply-To: <5154834202000078000C96DD@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2358557764575689490== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC2EC86A5EB76045E563F2703" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2EC86A5EB76045E563F2703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28.03.2013 17:52, Jan Beulich wrote: >>>> On 28.03.13 at 17:31, Marek Marczykowski > wrote: >> On 28.03.2013 17:25, Jan Beulich wrote: >>>>>> On 27.03.13 at 15:31, Marek Marczykowski >>> wrote: >>>> On 27.03.2013 09:52, Jan Beulich wrote: >>>>>>>> On 26.03.13 at 19:50, Andrew Cooper = wrote: >>>>>> So vector e9 doesn't appear to be programmed in anywhere. >>>>> >>>>> Quite obviously, as it's the 8259A vector for IRQ 9. The question >>>>> really is why an IRQ appears on that vector in the first place. The= >>>>> 8259A resume code _should_ leave all IRQs masked on a fully >>>>> IO-APIC system (see my question raised yesterday). >>>>> >>>>> And that's also why I suggested, for an experiment, to fiddle with >>>>> the loop exit condition to exclude legacy vectors (which wouldn't >>>>> be a final solution, but would at least tell us whether the directi= on >>>>> is the right one). In the end, besides understanding why an >>>>> interrupt on vector E9 gets raised at all, we may also need to >>>>> tweak the IRQ migration logic to not do anything on legacy IRQs, >>>>> but that would need to happen earlier than in >>>>> smp_irq_move_cleanup_interrupt(). Considering that 4.3 >>>>> apparently doesn't have this problem, we may need to go hunt for >>>>> a change that isn't directly connected to this, yet deals with the >>>>> problem as a side effect (at least I don't recall any particular fi= x >>>>> since 4.2). One aspect here is the double mapping of legacy IRQs >>>>> (once to their IO-APIC vector, and once to their legacy vector, >>>>> i.e. vector_irq[] having two entries pointing to the same IRQ). >>>> >>>> So tried change loop condition to LAST_DYNAMIC_VECTOR and it doesn't= hit=20 >>>> that >>>> BUG/ASSERT. But still it doesn't work - only CPU0 used by scheduler,= also=20 >>>> some >>>> errors from dom0 kernel, and errors about PCI devices used by domU(1= ). >>>> >>>> Messages from resume (different tries): >>>> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector= =2Elog=20 >>>> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector= 2.log=20 >>> >>> Is that a sensible usage scenario at all? I would think that a >>> prerequisite to host S3 is that all guests get suspended.=20 >> >> What do you mean by "suspended"? I haven't found any sane method to do= that >> with xl (only some manual xenstore write to control/shutdown). For now= I do: >> - shutdown all network adapters in VMs >> - pause all VMs >=20 > Aren't there "xl save" and "xl restore"? And for HVM guests, I think > there's also a way to do virtual S3. xl save/restore takes far to much time. I've tried xenstore-write "suspend" to control/shutdown, then xc_domain_r= esume call some time ago, but I had some problems with that (unfortunately don'= t remember details...). This is basically what xl save and restore does, but without actual data = dump. --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enigC2EC86A5EB76045E563F2703 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/ iQEcBAEBAgAGBQJRVHloAAoJENuP0xzK19csuDwH/itvHOViEQ79hqtEU/MfOmhd kbbyxpN4NuglWAzLcfUqfUm2upoh1RpHrLTfQ0c4J3UBtqePbDrWrORDXGlbuLMq hSNilVsqPw/uwDD/mFMhHL3zy5WwiLIaQWhKJhxnsNOocmdWR18UDowFM1tMYwpG d3TzatAvwG+lb9L3UwSdn74qGw3f0iE/BVv4p8mHn1QX0QU8AhaxJgz3ksEI/aLM 9Q/DgTHhFzUPnZMVQW+FsSEz+SQixuzF4hGPrx1iB5XarmnqmcJZN9O7jn7so1aR 8nyFbOv6EbKN0i5zhFACN4Fqk07sTiM4C4Wc4UYHqr8npGUMWsTWVhwxARiCz7c= =qtBs -----END PGP SIGNATURE----- --------------enigC2EC86A5EB76045E563F2703-- --===============2358557764575689490== 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 --===============2358557764575689490==--