Date: Sat, 07 Aug 2004 17:01:12 -0700 From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: jhb@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c Message-ID: <41156D48.8030304@root.org> In-Reply-To: <20040806.233528.74404627.imp@bsdimp.com> References: <200408060450.i764ouJu097994@repoman.freebsd.org> <200408061014.22594.jhb@FreeBSD.org> <4114681D.5020902@root.org> <20040806.233528.74404627.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <4114681D.5020902@root.org> > Nate Lawson <nate@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. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41156D48.8030304>