From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: High CPU temp, suspend problem - xen 4.1.5-pre,
 linux 3.7.x
Date: Wed, 27 Mar 2013 16:27:55 +0000
Message-ID: <51531E0B.1030806@citrix.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <51531593.5040701@invisiblethingslab.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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 interrupt
>>> with vector between 0xe0 and 0xef.  This might at least indicate whether
>>> legacy vectors are genuinely being delivered, or whether we have some
>>> 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 information).
>

Even in the case where we hit the original assertion?

If so, then all I can thing is that the move_pending flag for that
specific GSI has been corrupted in memory somehow.

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.

~Andrew