WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] spurious interrupts

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] spurious interrupts
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 12 Apr 2006 18:21:44 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 12 Apr 2006 10:21:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <443D1E9C.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <443D1E9C.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
This happens definitely immediately after writing to the IO-APIC? There is an ack_APIC_irq() not many instructions after that, and it would make much more sense for the IRR flag to be set after that. :-)

 -- Keir

On 12 Apr 2006, at 14:37, Jan Beulich wrote:

While I haven't heard anything whether others were able to reproduce this, I was now able to nail this down to a simple operation: On the system I'm testing with I was able to identify that the handling of the interrupt from the SCSI controller triggers a simultaneous interrupt from one of the USB controllers, of which (by way of looking at the native execution) it is known that it doesn't generate any interrupts. Hence it was possible to BUG() the box the first time such an interrupt appears. This happens when mask_and_ack_level_ioapic_irq() masks the irq from the first SCSI controller (pin 0 of IOAPIC 3). No matter how large delays I insert before calling mask_IO_APIC_irq(), the other interrupt (pin 16 of IOAPIC 0) becomes visible (in the redirection table's irr bit) immediately after the write that
sets the mask bit for the first interrupt.

Obviously I am lost here - I have no way to tell why writing on IOAPIC's redir entry affects an interrupt routed through a completely different IOAPIC. Nevertheless it is clear that the problem is unique to Xen, because native Linux
doesn't try to mask the IRQ.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>