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, 26 Mar 2013 14:50:00 +0100 Message-ID: <5151A788.809@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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2510818669803149996==" Return-path: In-Reply-To: <5151AC8C02000078000C88B9@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: 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) --===============2510818669803149996== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECEC162C65E597C0AFF3A688" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECEC162C65E597C0AFF3A688 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26.03.2013 14:11, Jan Beulich wrote: >>>> On 26.03.13 at 13:17, Marek Marczykowski wrote: >> Finally got serial console :) >> The debug=3Dy problem is (actually at resume): >> (XEN) Assertion 'test_bit(vector, cfg->used_vectors)' failed at io_api= c.c:542 >> (XEN) ----[ Xen-4.1.5-rc1 x86_64 debug=3Dy Tainted: C ]---- >> (XEN) CPU: 0 >> (XEN) RIP: e008:[]=20 >> smp_irq_move_cleanup_interrupt+0x1c3/0x23d >> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor >> (XEN) rax: 0000000000000000 rbx: 00000000000000e9 rcx: ffff82c4802= 9ff18 >> (XEN) rdx: 00000000000000e9 rsi: 000000000000002a rdi: ffff8304210= 60538 >> (XEN) rbp: ffff82c48029ff08 rsp: ffff82c48029feb8 r8: ffff8804182= 0eb60 >> (XEN) r9: 0000000000000000 r10: 0000000000007ff0 r11: 00000000000= 00000 >> (XEN) r12: ffff830421080250 r13: ffff830421060534 r14: ffff82c4802= 9ff18 >> (XEN) r15: ffff82c4802dd9e0 cr0: 000000008005003b cr4: 00000000000= 026f0 >> (XEN) cr3: 0000000300b81000 cr2: ffff880402070198 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >> (XEN) Xen stack trace from rsp=3Dffff82c48029feb8: >> (XEN) 0000000000000000 000000000000e030 ffff82c48029ff18 ffff82c480= 2dd9e0 >> (XEN) ffff8802cac3c7c0 00000000ffff3729 00000000ffff3729 000000013f= ff3728 >> (XEN) ffffffff81b907c0 00000000ffff3729 00007d3b7fd600c7 ffff82c480= 14de60 >> (XEN) 00000000ffff3729 ffffffff81b907c0 000000013fff3728 00000000ff= ff3729 >> (XEN) ffffffff81a01e18 00000000ffff3729 0000000000000000 0000000000= 007ff0 >> (XEN) 0000000000000000 ffff88041820eb60 ffff8803fd1820a8 ffffffff81= b90a88 >> (XEN) 000000000000002a 000000000000002a 00000000ffff372a 0000002000= 000000 >> (XEN) ffffffff8105dd5a 000000000000e033 0000000000000246 ffffffff81= a01db8 >> (XEN) 000000000000e02b 0000000000000000 0000000000000000 0000000000= 000000 >> (XEN) 0000000000000000 0000000000000000 ffff8300ca9a0000 0000000000= 000000 >> (XEN) 0000000000000000 >> (XEN) Xen call trace: >> (XEN) [] smp_irq_move_cleanup_interrupt+0x1c3/0x2= 3d >> (XEN) >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) Assertion 'test_bit(vector, cfg->used_vectors)' failed at io_api= c.c:542 >> (XEN) **************************************** >=20 > To make sense of this, we need to know the register (and maybe > stack) allocation at this point, to know which vector it was that > triggered the assertion. You can either do this analysis for us, or > point us at the xen-syms binary matching the xen.gz you used. "info scope smp_irq_move_cleanup_interrupt" said vector is in %rbx, so 0x= e9. > From the register values, the most likely candidates are vector 0xe9 > and 0x2a. The former having two registers set to this value seems > more likely from than angle, but vectors in the 0xe? range should > never end up in smp_irq_move_cleanup_interrupt(). >=20 > And if it's the 0x2a one, then we'd need to know what IRQ it was > last used for. That can't be reconstructed from the data above, so > would require you being able to reproduce this and adding some > instrumentation to the code. >=20 > Jan >=20 --=20 Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab --------------enigECEC162C65E597C0AFF3A688 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/ iQEcBAEBAgAGBQJRUaeJAAoJENuP0xzK19cs9RkH/RoapJM+V7fCYKBpspRe5qsh iyjo8ACdA8TOfddmb9Q/6RXPANfvnF0or3amw7vkk+qyh25KE4VCJkGRv+NGMpHF CINFlHMm7jjmITcwgwnwplbT5jw5tdSQY6VkFWXYDpAhh9Gf5vCZmC91XS/vYUO2 /ApXihSJTDN01qkNuyDUK5IbXPbIhZ/2RdYu2gqF4jT4QnDaGr/q617HAxIQKFw9 9dKq8iAy308Ka6ide3NW7QbGadNbscE7IVIffrcNNC3HNZZiGDaL94FuN5gZCOHy aYyUviQ6zl8dSHIjCxt3mlgYKts0tYxQQi0pUWAL8koA41arhPWeZVYFnI8UbEE= =RTLw -----END PGP SIGNATURE----- --------------enigECEC162C65E597C0AFF3A688-- --===============2510818669803149996== 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 --===============2510818669803149996==--