[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] IO-APIC interrupts getting stuck
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |