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: Wed, 27 Mar 2013 19:16:17 +0100 Message-ID: <51533771.3080808@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> <5153063C.8020307@citrix.com> <51530709.3050206@invisiblethingslab.com> <51531593.5040701@invisiblethingslab.com> <51531E0B.1030806@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7823413412002635549==" Return-path: In-Reply-To: <51531E0B.1030806@citrix.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: Andrew Cooper Cc: Konrad Rzeszutek Wilk , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7823413412002635549== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1739A11BF80154EACD47A11" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1739A11BF80154EACD47A11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27.03.2013 17:27, Andrew Cooper wrote: > On 27/03/2013 15:51, Marek Marczykowski wrote: >> On 27.03.2013 15:49, Marek Marczykowski wrote: >>> On 27.03.2013 15:46, Andrew Cooper wrote: >>>> As for locating the cause of the legacy vectors, it might be a good = idea >>>> to stick a printk at the top of do_IRQ() which indicates an interrup= t >>>> with vector between 0xe0 and 0xef. This might at least indicate whe= ther >>>> legacy vectors are genuinely being delivered, or whether we have som= e >>>> memory corruption causing these effects. >>> Ok, will try something like this. >> Nothing interesting here... >> Only vector 0xf1 for irq 4 and 0xf0 for irq 0 (which match irq dump in= formation). >> >=20 > Even in the case where we hit the original assertion? Yes, even then. > If so, then all I can thing is that the move_pending flag for that > specific GSI has been corrupted in memory somehow. I guest this isn't the case, see below. > I wonder if hexdumping irq_desc[9] after setup, before sleep, on resume= > and in the case of the assertion failure might give some hints. I've tried something like this. Detailed log here: http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-suspend-irq9-dump.log Some interesing parts: after system startup: (XEN) irq_cfg of IRQ 9: (XEN) vector: 138 (XEN) move_cleanup_count: 0x0 (XEN) move_in_progress: 0x0 (XEN) irq_desc of IRQ 9: (XEN) status: 80 (IRQ_GUEST | IRQ_PENDING) Isn't this wrong (status vs move_in_progress)? Then I've run pm-suspend, intentionally failed at the end to prevent actu= al suspend, but run all its hooks. After that: (XEN) irq_cfg of IRQ 9: (XEN) vector: 181 (XEN) move_cleanup_count: 0x0 (XEN) move_in_progress: 0x1 (XEN) irq_desc of IRQ 9: (XEN) status: 80 So now move_in_progress consistent with status. Wait few second, and still move_in_progress was 0x1. Isn't it supposed to= be only temporary state? Then suspended, at resume hit that bug. There was: (XEN) irq_cfg of IRQ 9: (XEN) vector: 60 (XEN) move_cleanup_count: 0x0 (XEN) move_in_progress: 0x0 (XEN) irq_desc of IRQ 9: (XEN) status: 16 move_in_progress=3D=3D0, ok. But move_cleanup_count=3D=3D0, while at leas= t once was move_in_progress=3D=3D1. Isn't that wrong? --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enigF1739A11BF80154EACD47A11 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/ iQEcBAEBAgAGBQJRUzdyAAoJENuP0xzK19csSnkH/0I3ebGRqRojFSOvxN/PLu+O WxHTLNP0fHi5F14RKdkp294N28xHiNuoBNd3807BdnKJDS8jNFcVukKYK+zol8Gi n2TuYyp6wVt4+hN8zzpnkJL94RD5Koc5VSpO7kokVyhR4tiRj3O6Gga7+/f+f6gR gqJICKnp+1L06IWXwSNyPw1D3YqmC9ZnVS45EtPHH4l02nQzX64iDzFPxJhlXOW+ WwqxmvfEqZc3Xk+RsrjnAMfmvsqp//Nrk/iCnDqXeA5bljewgAsm7tA66SYXpn0y 7BL7+fpjMNdGkJGUGTI90ts+n/DNCBbkdkKXfyVaPtGPuEkhaI0RJyaYTktq6Rw= =yAO5 -----END PGP SIGNATURE----- --------------enigF1739A11BF80154EACD47A11-- --===============7823413412002635549== 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 --===============7823413412002635549==--