From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 12:10:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 088B316A4CE; Fri, 8 Apr 2005 12:10:23 +0000 (GMT) Received: from barton.dreadbsd.org (massena-4-82-67-196-50.fbx.proxad.net [82.67.196.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8336C43D46; Fri, 8 Apr 2005 12:10:21 +0000 (GMT) (envelope-from antoine@massena-4-82-67-196-50.fbx.proxad.net) Received: from barton.dreadbsd.org (localhost [127.0.0.1]) by barton.dreadbsd.org (8.13.3/8.13.1) with ESMTP id j38CAKUV001015; Fri, 8 Apr 2005 14:10:20 +0200 (CEST) (envelope-from antoine@massena-4-82-67-196-50.fbx.proxad.net) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.3/8.13.1/Submit) id j38CAJFF001014; Fri, 8 Apr 2005 14:10:19 +0200 (CEST) (envelope-from antoine) Date: Fri, 8 Apr 2005 14:10:19 +0200 From: Antoine Brodin To: John Baldwin Message-Id: <20050408141019.6cb045c1.antoine.brodin@laposte.net> In-Reply-To: <200504071607.47419.jhb@FreeBSD.org> References: <200504051349.13620.jhb@FreeBSD.org> <42557133.2070802@root.org> <200504071607.47419.jhb@FreeBSD.org> X-Mailer: Sylpheed version 1.9.7 (GTK+ 2.6.4; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: k-gleb@yandex.ru cc: dan.cojocar@gmail.com cc: nate@root.org Subject: Re: Interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2005 12:10:23 -0000 John Baldwin wrote: > Yes, I am. However, what this is doing is going and looking to see if the > BIOS has programmed a valid IRQ into any of the devices routed by this IRQ, > and if so, we (currently) trust what the BIOS says over what the link claims > as far as what the best IRQ to use is. If the BIOS is just confused but the > BIOS IRQ is still valid in _PRS then the fact that we always do an _SRS means > we are still ok. The real problem here is that for this machine, calling > _DIS seems to permanently break the link devices. I think we'll have to add > a quirk to disable calling _DIS. I wonder if Linux already has such a quirk > for this box or if they are more selective about how and when they call _DIS. Hi, I was wondering why ACPI pci link code from RELENG_5 worked (it called _DIS too) and I noticed this in my dmesg: - pci_link[0-14] are attached - then pci0, pcib0 and other devices are attached - then pci_link[15-31] are attached - then other devices are attached I thought that perhaps the problem was that _DIS was called after devices had already been attached and had allocated an irq. So I tried this patch: %%% Index: acpi_pci_link.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.44 diff -u -p -r1.44 acpi_pci_link.c --- acpi_pci_link.c 18 Jan 2005 20:18:46 -0000 1.44 +++ acpi_pci_link.c 8 Apr 2005 11:19:29 -0000 @@ -511,7 +511,8 @@ acpi_pci_link_attach(device_t dev) * run _DIS (i.e., the method doesn't exist), assume the initial * IRQ was routed by the BIOS. */ - if (ACPI_SUCCESS(AcpiEvaluateObject(acpi_get_handle(dev), "_DIS", NULL, + if (device_get_unit(dev) <= 14 && + ACPI_SUCCESS(AcpiEvaluateObject(acpi_get_handle(dev), "_DIS", NULL, NULL))) for (i = 0; i < sc->pl_num_links; i++) sc->pl_links[i].l_irq = PCI_INVALID_IRQ; %%% With this patch, sk0 uses irq9 but everything works fine (no timeouts, no interrupt storms). I don't know if my idea is totally silly or not ... Perhaps the pci links should be all attached before other devices are attached ? Cheers, Antoine