From owner-cvs-src@FreeBSD.ORG Sun Aug 8 00:01:16 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 794D416A4CE; Sun, 8 Aug 2004 00:01:16 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A17243D1D; Sun, 8 Aug 2004 00:01:16 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7801D8U022239; Sat, 7 Aug 2004 17:01:13 -0700 Message-ID: <41156D48.8030304@root.org> Date: Sat, 07 Aug 2004 17:01:12 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <200408060450.i764ouJu097994@repoman.freebsd.org> <200408061014.22594.jhb@FreeBSD.org> <4114681D.5020902@root.org> <20040806.233528.74404627.imp@bsdimp.com> In-Reply-To: <20040806.233528.74404627.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: jhb@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2004 00:01:16 -0000 M. Warner Losh wrote: > In message: <4114681D.5020902@root.org> > Nate Lawson 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