>
> Hi Natalie,
>
> On Thu, 19 May 2005 [email protected] wrote:
>
> > I suggest to change the way IRQs are handed out to PCI devices.
> > Currently, each I/O APIC pin gets associated with an IRQ,
> no matter if
> > the pin is used or not. It is expected that each pin can
> potentually
> > be engaged by a device inserted into the corresponding PCI slot.
> > However, this imposes severe limitation on systems that
> have designs
> > that employ many I/O APICs, only utilizing couple lines of
> each, such
> > as P64H2 chipset. It is used in ES7000, and currently,
> there is no way
> > to boot the system with more that 9 I/O APICs. The simple
> change below
> > allows to boot a system with say 64 (or more) I/O APICs, each
> > providing 1 slot, which otherwise impossible because of the
> IRQ gaps
> > created for unused lines on each I/O APIC. It does not resolve the
> > problem with number of devices that exceeds number of
> possible IRQs,
> > but eases up a tension for IRQs on any large system with
> potentually
> > large number of devices. I only implemented this for the ACPI boot,
> > since if the system is this big and
>
> Can you determine number of slots in use?
I think it is possible, but then it will probably be back to something
like "pci=routeirq" philosophy.
> > using newer chipsets it is probably (better be!) an ACPI based
> > system :). The change is completely "mechanical" and does not alter
> > any internal structures or interrupt model/implementation.
> The patch
> > works for both i386 and x86_64 archs. It works with MSIs just fine,
> > and should not intervene with implementations like shared vectors,
> > when they get worked out and incorporated.
>
> Well we ran into similar problems on older MPS systems
> (NUMAQ) but those don't really matter right now anyway. So i
> think fixing this for ACPI is fine.
ACPI is well organized and easily manipulated, that's why I stopped
right there. I tried adjusting the MPS case, it is possible, but then I
thought no one would need it anyway. It would take multiple changes and
won't be pretty, but if you insist I can work it out :)
> But i like your patch =)
:)
> Thanks,
> Zwane
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
