Re: [Xen-devel] spurious interrupts

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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