From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 19:42:31 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 5370616A4CE for ; Fri, 8 Apr 2005 19:42:31 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F08A243D1F for ; Fri, 8 Apr 2005 19:42:30 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23417 invoked from network); 8 Apr 2005 19:42:30 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Apr 2005 19:42:30 -0000 Received: from roboboy.corp.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j38JgEVu090436; Fri, 8 Apr 2005 15:42:24 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Antoine Brodin Date: Fri, 8 Apr 2005 15:29:29 -0400 User-Agent: KMail/1.8 References: <200504071607.47419.jhb@FreeBSD.org> <20050408141019.6cb045c1.antoine.brodin@laposte.net> In-Reply-To: <20050408141019.6cb045c1.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504081529.33026.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx 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 19:42:31 -0000 On Friday 08 April 2005 08:10 am, Antoine Brodin wrote: > 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 ? I think your other link devices are meant to be used in APIC mode (note their names start with 'A') and thus I think they are aliases for the other link devices. So when I turn off the alias, I turn off the non-APIC mode one as well. Working BIOSen handle this by having the same link device change its behavior (different _PRS return values) depending on the PIC mode. It's not easy to determine if a link is just not used (for example, if no card is plugged into a slot with a dedicated link) or if it's an alias. I think having two ACPI devices alias to the same hardware is a bug in the BIOS though. Perhaps your BIOS vendor can be convinced to fix this. Can you see if Linux has the same problem btw? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org