[openib-general] Help with CONFIG_PCI_MSI in the kernel
Grant Grundler
iod00d at hp.com
Tue Apr 4 18:57:44 PDT 2006
On Tue, Apr 04, 2006 at 06:31:44PM -0600, Jason Gunthorpe wrote:
...
> [clip about fedora]
>
> You are totally right of course WRT to fedora. I was just thinking
> aloud about how to have MSI turned on and work for all supported
> platforms more generally.
Yeah, each arch has to decide if to enable MSI or not.
e.g. PARISC does not. Mathew Wilcox and I will hack this out late
some evening once we realize Mark's patches have enabled us to do so.
> > The concept of "IRQ Lines" doesn't go away
> > with PCI-e. PCI-e just virtualizes the concept into transactions
> > that a parent bridge can convert into MSI transactions.
> > The parent bridge in this case is essentially doing the same
> > thing that an IO xAPIC (or SAPIC) would do.
>
> Mm, can you clarify this? Your description matches my understanding of
> PCIe legacy (8252 and IOAPIC style) interrupts. However with MSI at
> the device the parent bridge isn't involved in vector selection so
> the APCI IOAPIC linkage information is unused.
Right. I forget the right terminlogy for the "port" that handles
PCIe legacy interrupts - I just called it "parent bridge".
It's some "upstream" component from the "legacy" device
but below a "root port" (IIRC).
> I only point this out because it seems to be a common problem that
> some el-chepo motherboards have broken APCI and important things like HD
> controllers don't work because their interrupt linkages are mangled
> somehow. In a UP system alot of the other APCI information is not
> critical (or as error prone..) so using MSI would be a nice
> alternative way to get such a system to work 100%.
hrm...interesting thought. That might be feasible in some cases
but el-cheapo MBs probably have PCI devices with broken MSI
implementations (e.g. bcm5701). Given the track record for IDE
HW is generally not so good, I wouldn't count on MSI working
for most IDE devices that advertise the capability until
I saw it working.
I also wonder if some of the same ACPI info that causes IRQ lines
not to work will also cause MSI not to work. The ia64/i386
linux IO SAPIC support depends on ACPI but I don't know offhand
how much of that is used to program IO SAPIC (vs discover IO SAPICs).
[ re patch ]
...
> Two notes about it:
> 1) It doesn't force the base address to 0xfee00000 [this is the
> documented reset value however]
> 2) If used with Mark Maule's work, then the base address should be
> taken from the first bridge with a HT MSI Mapping cap, going along the
> bridge chain toward the host from the device that the MSI address is
> being generated for.
ok - others will understand this better than me.
thanks again,
grant
More information about the general
mailing list