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 15:49:45 +0100 Message-ID: <51530709.3050206@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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3433899661030123264==" Return-path: In-Reply-To: <5153063C.8020307@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) --===============3433899661030123264== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1049C6DE3A293AD21CF1C09A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1049C6DE3A293AD21CF1C09A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27.03.2013 15:46, Andrew Cooper wrote: > On 27/03/2013 14:31, Marek Marczykowski wrote: >> On 27.03.2013 09:52, Jan Beulich wrote: >>>>>> On 26.03.13 at 19:50, Andrew Cooper wr= ote: >>>> 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 direction= >>> 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 fix >>> 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 h= it that >> BUG/ASSERT. But still it doesn't work - only CPU0 used by scheduler, a= lso 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.l= og >> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector2.= log >> >> Also one time I've got fatal page fault error, earlier in resume (it i= sn't >> deterministic): >> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-resume-page-fault.log= >> >=20 > This pagefault is a Null structure pointer dereference, likely the > scheduling data. At a first glance, it looks related to the assertion > failures I have been seeing sporadically in testing, but unable to > reproduce reliably. There seems to be something quite dodgy with > interaction of vcpu_wake and scheduling loops. >=20 > The other logs indicate that dom0 appears to have a domain id of 1, > which is sure to cause problems. Perhaps not - domain 1 exists and have some PCI devices assigned (namely = two network adapters). > As for locating the cause of the legacy vectors, it might be a good ide= a > to stick a printk at the top of do_IRQ() which indicates an interrupt > with vector between 0xe0 and 0xef. This might at least indicate whethe= r > legacy vectors are genuinely being delivered, or whether we have some > memory corruption causing these effects. Ok, will try something like this. --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enig1049C6DE3A293AD21CF1C09A 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/ iQEcBAEBAgAGBQJRUwcJAAoJENuP0xzK19csO5IH/Rn9kBUrtxoAYsFLaBQZF+2k PSKDC1U1o0ZqA5gglJb4tHM0LxskM7XMvOvVgO4VGReL7VdNu8uvOFdimCeHUeYW l8RBmt0iC9wJGPT0ozhgtePv2+cJFSx5fPVyMhKUKpfyGXRn3YMn8uXRjY7gSSvv mo8Nrqns0r8M1HgPQxJrJ/UqL3oIQyalZoSVoYpFMNy/nnKfBqSGl1FaejnTpeAi Us7+HAtubRewRVGELo/rlDbkdpIQFlJkmE/OAjK+a72X1qUyof7mYGmpu/JERFzM HJxZ0+0ipCo3fo0OdvgI0BFj+j494PXTKbcD23J9L2rtwoeM0jgsM/gjwdE9GjY= =HKJn -----END PGP SIGNATURE----- --------------enig1049C6DE3A293AD21CF1C09A-- --===============3433899661030123264== 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 --===============3433899661030123264==--