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

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

[Len Brown]

On Wed, 2004-02-18 at 12:43, Maciej W. Rozycki wrote:

>  Note that if changing an I/O APIC input was indeed needed, the
> replace_pin_at_irq() function could be used.

Why is it that all IRQs get their name from the
IOAPIC pin number, but the timer connected to
pin 2 is called IRQ0 instead of IRQ2?

Are there other exceptions to this rule,
or is all the code for re-naming IRQs & pins
effectively just for the timer?

I wonder if we should't be moving to at least a build option which
deletes support for multiple pins at an IRQ, and deletes
suport for non-identity pin->IRQ mapping.

>  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?

While the ACPI table parsing is very early, the _PRT parsing
can happen only after the ACPI interpreter is up, because
the _PRT's are encoded in AML.

thanks,
-Len

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

[Maciej W. Rozycki]

On Thu, 31 Mar 2004, Len Brown wrote:

> Why is it that all IRQs get their name from the
> IOAPIC pin number, but the timer connected to
> pin 2 is called IRQ0 instead of IRQ2?

 ISA interrupts get their numbers from 8259A IRQ numbers they would be
routed to in the PIC mode.  This lets the code operate in the mixed mode
sanely (which happens for certain hardware), although it's not necessarily
the reason for the numbering used.  Note that the MP Specification does
not mandate an identity map of ISA interrupts, although it seems to be
what vendors do.

 Also note that depending on the configuration, the timer can effectively
be routed to INTIN2 or INTIN0 by Linux -- one of the alternatives being a
direct connection and the other one being done through the 8259A
configured to be transparent for its IRQ 0.

> I wonder if we should't be moving to at least a build option which
> deletes support for multiple pins at an IRQ, and deletes
> suport for non-identity pin->IRQ mapping.

 This can't be done for the timer due to configuration variations.

> While the ACPI table parsing is very early, the _PRT parsing
> can happen only after the ACPI interpreter is up, because
> the _PRT's are encoded in AML.

 Hmm, that's unfortunate.  Couldn't the interpreter be started earlier?

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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

[Len Brown]

On Thu, 2003-12-11 at 10:15, Maciej W. Rozycki wrote:
> On Thu, 11 Dec 2003, Ross Dickson 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().

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.

thanks,
-Len

 

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@ds2.pg.gda.pl, PGP key available        +