cvs commit: src/sys/dev/acpica acpi_pci_link.c
nate at root.org
Sat Aug 7 17:01:16 PDT 2004
M. Warner Losh wrote:
> In message: <4114681D.5020902 at root.org>
> Nate Lawson <nate at root.org> writes:
> : John Baldwin wrote:
> : > On Friday 06 August 2004 12:50 am, Nate Lawson wrote:
> : >
> : >>njl 2004-08-06 04:50:56 UTC
> : >>
> : >> FreeBSD src repository
> : >>
> : >> Modified files:
> : >> sys/dev/acpica acpi_pci_link.c
> : >> Log:
> : >> Refine updates to PCI irq routing. Check _STA and _CRS but only print a
> : >> message if they are incorrect. Also, remove the hack of allowing the
> : >> initial irq setting to not be in _PRS. As before, the old behavior can
> : >>be regained by defining ACPI_OLD_PCI_LINK.
> : >
> : >
> : > Note that I had to back out this removal of the initial IRQ hack because it
> : > broke things for many people. The problem is that the current link code
> : > doesn't do a good job of picking virgin IRQs.
> : >
> : I plan to take this to the logical conclusion. I agree you were on the
> : right track but didn't go far enough. :) I'll send patches in a few days.
> I know that Linux uses (used) a system where it would assign weights
> to the interrupts. It then would route to the least weighted
> interrupt possible, and then add some factor to its weight so that it
> was less likely to be picked for the next interrupt. Don't know how
> well that scales, esp for SMP boxes with ioapic. The initial weights,
> however, heavily biased against the interrupts used by the standard
> set of PC-AT devices: 3 (sio), 4 (sio), 6 (fdc), 7 (ppc), 12 (psm) and
> ata (14, 15). There was also a mask of invalid IRQs.
We do that too although the algorithm can use improvement (see
acpi_pci_link.c). The problem I'm fixing is that we have parallel code
in acpi_pcib_route and acpi_pci_link that each does half the problem
well but don't work properly together. The acpi_pcib_route code does
well at handling the _PRT but fails utterly at doing a good job of
routing an unrouted interrupt (it just picks the first one, which is
often 3). The acpi_pci_link code has lots of heuristics for balancing
interrupts and programming links but fails utterly at communicating that
to the acpi_pcib_route code (it depends on _CRS being correct, which is
too much to ask of BIOS authors). The end result is that things really
only work well when the BIOS initializes the links for us. Luckily,
that is often the case.
> This degrated to a round robin assignment of interrupts that weren't
> heavily weighted against. This is generically fair, but might not be
> optimal for a given system (since it might round robin the two biggest
> interrupt sources together)...
Yes, acpi_pci_link does this. My work is to join the two, allowing them
to communicate properly and eliminate duplicate code (that is not quite
right). The longer term work, which jhb@ started, is to make pci links
proper devices, standardize APIs, clean up acpi_pci_link, etc.
More information about the cvs-all