Messages in this thread |  | | | Date | Wed, 18 Feb 2004 18:43:36 +0100 (CET) | | From | "Maciej W. Rozycki" <> | | Subject | Re: ACPI SCI IOAPIC bug (Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered) |
| |
On Sat, 13 Feb 2004, Len Brown wrote:
> > > ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] > > trigger[0x3]) > > > Int: type 0, pol 1, trig 3, bus 0, irq 9, 2-9 > > > > ... > > > > > IRQ to pin mappings: > ... > > > IRQ9 -> 0:9-> 0:9 > > > > ... wrong -- the interrupts are set up as if they were > > connected to multiple I/O APIC inputs. > > Maciej, > You're right. This bug is in mp_config_ioapic_for_sci(), which calls > io_apic_set_pci_routing(), which uncondnitionally calls > add_pin_to_irq(). Problem is that this IRQ has already been initialized > back in setup_IO_APIC_irqs().
Note that if changing an I/O APIC input was indeed needed, the replace_pin_at_irq() function could be used.
> Clearly in this case we shouldn't be calling io_apic_set_pci_routing() > at all. But I've got to look more closely at the case where the SCI is > not identity mapped before simply ripping it out.
I still wonder why these arrangements are made so late in a boot -- after all, ACPI IRQ configuration is table-driven and does not require any specific hardware initialization to work. So it could be done at the stage MP-table parsing happens, couldn't it?
Maciej
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |