cvs commit: src/sys/dev/acpica acpi_pci_link.c

M. Warner Losh imp at bsdimp.com
Fri Aug 6 22:37:18 PDT 2004


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.

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)...

Warner


More information about the cvs-all mailing list