lkml.org 
[lkml]   [2004]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateWed, 18 Feb 2004 18:43:36 +0100 (CET)
From"Maciej W. Rozycki" <>
SubjectRe: 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/
\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2010