Re: [Xen-devel] IO-APIC interrupts getting stuck

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.12.14 at 13:51, <roger.pau@xxxxxxxxxx> wrote:
> I've also added the following patch to Xen, and it reliably triggers on 
> FreeBSD, while it seems to work fine on Linux:
> 
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1729,6 +1729,8 @@ static void end_level_ioapic_irq_new(struct irq_desc 
> *desc, u8 vector)
>   * The idea is from Manfred Spraul.  --macro
>   */
>      unsigned int v, i = desc->arch.vector;
> +    struct IO_APIC_route_entry rte;
> +    struct irq_pin_list *entry = irq_2_pin + desc->irq;
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> @@ -1751,6 +1753,9 @@ static void end_level_ioapic_irq_new(struct irq_desc 
> *desc, u8 vector)
>              __unmask_IO_APIC_irq(desc->irq);
>          spin_unlock(&ioapic_lock);
>      }
> +
> +    rte = ioapic_read_entry(entry->apic, entry->pin, 0);
> +    ASSERT(rte.irr == 0 || rte.mask != 0);

Could you arrange for you to be able to determine which code
paths were taken in the routine when the ASSERT() triggers? I.e.
minimally make sure vector, i, and v can be determined from the
printed registers and stack contents. Plus maybe also read the
applicable APIC_I[RS]R bits.

And you're also apparently not seeing this on a system where
Linux'es IO-APIC re-route workaround might come into play (see
drivers/pci/quirks.c:quirk_reroute_to_boot_interrupts_intel()),
which then I would have suspected FreeBSD to not have such a
workaround...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel