Re: ACPI SCI IOAPIC bug (Re: Fixes for nforce2 hard lockup, apic,io-apic, udma133 covered)

[Maciej W. Rozycki]

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@xxxxxxxxxxxxx, PGP key available        +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/