On Sun, 10 Oct 2010, Yinghai Lu wrote: > On 10/10/2010 02:32 AM, Thomas Gleixner wrote: > > On Sat, 9 Oct 2010, Yinghai Lu wrote: > >> On 10/08/2010 11:34 PM, Thomas Gleixner wrote: > >>> On Fri, 8 Oct 2010, Yinghai Lu wrote: > >>>> + /* only handle fall out from setup_IO_APIC_irqs() */ > >>> > >>> What's the fallout ? And why are we coming here in the first place > >>> when the irq is < 16 ? > >> > >> setup_IO_APIC_irqs only handle apic_id == 0 or apic_id > 0 but irq < 16 via acpi override. > >> > >> it seems IBM's system have apic_id == 1, and sci irq is using 30. > >> > >> so at that time add that setup_IO_APIC_irq_extra() to workaround it. > >> but it seems we set that two time when irq < 16. > >> > >>> > >>>> + if (!((apic_id > 0) && (irq > 16))) > >>>> + return; > > > > I added this into the queue, but simplified it to > > > > if (apic_id == 0 || irq < NR_IRQS_LEGACY) > > > > Folded in the other fix and pushed out an updated tree. > > still have the irq_2_iommu_alloc warning from pnpacpi Hmm, that's probably a problem for all legacy interrupts which are never torn down once they are set up. And we set them all up during early boot. So either we special case the legacy area or remove the warning alltogether. Another option I discussed with Suresh recently is to remove the allocator in intr_remapping.c and just embedd irq_2_iommu into irq_cfg. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
