From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 17:50:56 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 ABF6E16A4D5 for ; Tue, 5 Apr 2005 17:50:56 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAB3643D4C for ; Tue, 5 Apr 2005 17:50:55 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29399 invoked from network); 5 Apr 2005 17:50:55 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 5 Apr 2005 17:50:55 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j35Hoi31066872; Tue, 5 Apr 2005 13:50:49 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 5 Apr 2005 13:49:13 -0400 User-Agent: KMail/1.6.2 References: <200504051110.35735.jhb@FreeBSD.org> <20050405185831.2484695e.antoine.brodin@laposte.net> In-Reply-To: <20050405185831.2484695e.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200504051349.13620.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: nate@root.org cc: k-gleb@yandex.ru cc: dan.cojocar@gmail.com cc: Antoine Brodin 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: Tue, 05 Apr 2005 17:50:57 -0000 On Tuesday 05 April 2005 12:58 pm, Antoine Brodin wrote: > John Baldwin wrote: > > On Saturday 02 April 2005 04:41 pm, Antoine Brodin wrote: > > > Nate Lawson wrote: > > > > I'm a little confused. I don't know of anyone that has problems with > > > > the 6-current PCI irq code that works on 5-stable (which is what your > > > > cvs command updates it to). > > > > > > > > Do either of you have a problem with irq routing on 6-current that > > > > works on 5-stable? Please send details if so. > > > > > > Hi, > > > > > > I have this problem too, but since it's on a desktop I didn't really > > > care about acpi. > > > > > > Here are some details: > > > > > > current with pci irq code from 23-Nov-2004 dmesg: > > > http://bsd.miki.eu.org/~antoine/current+oldacpi.dmesg > > > > > > current with current pci irq code dmesg: > > > http://bsd.miki.eu.org/~antoine/current+acpi.dmesg > > > (there are timeouts and interrupt storms) > > > > > > acpi tables and asl: > > > http://bsd.miki.eu.org/~antoine/acpidump > > > > So the differences in actual IRQ assignments look like this: > > > > 13c13 > > < pcib1: slot 4 INTA routed to irq 5 via \\_SB_.PCI0.LNK2 > > --- > > > > > pcib1: slot 4 INTA routed to irq 9 via \\_SB_.PCI0.LNK2 > > > > 15,16c15,16 > > < pcib1: slot 7 INTA is already routed to irq 12 > > < pcib1: slot 10 INTA routed to irq 11 via \\_SB_.PCI0.LNK1 > > --- > > > > > pcib1: slot 7 INTA routed to irq 12 via \\_SB_.PCI0.LNK4 > > > pcib1: slot 10 INTA routed to irq 12 via \\_SB_.PCI0.LNK1 > > > > That is, LNK2 is routed to 9 rather than 5 and LNK1 is routed to 12 > > rather than 11. > > > > I'm not sure why it does this unless somehow the wrong device_t is > > getting associated with a handle. > > > > > grep 'LNK[12]' current+acpi.dmesg > > > > pci_link10: irq 11 on acpi0 > > pci_link11: irq 5 on acpi0 > > pcib1: matched entry for 1.4.INTA (src \\_SB_.PCI0.LNK2:0) > > pcib1: slot 4 INTA routed to irq 9 via \\_SB_.PCI0.LNK2 > > pcib1: matched entry for 1.10.INTA (src \\_SB_.PCI0.LNK1:0) > > pcib1: slot 10 INTA routed to irq 12 via \\_SB_.PCI0.LNK1 > > > > Can you apply this patch and provide a non-verbose dmesg? > > Here it is: > http://bsd.miki.eu.org/~antoine/current+acpi+semiverbose.dmesg Ok, I see the issue now. The problem is that the BIOS sets the IRQ registers in the PCI devices to values that don't match how the links are programmed and we tend to trust the BIOS over the links in those cases. Can you tell me what IRQ sk0 gets if you don't use ACPI? Does it get 5 or 9? If it gets 9, does it work ok? You can try this patch for ACPI. Unfortunately, some BIOSes lie when you ask a link which IRQ it is routed to, so I'm not sure if this patch can be committed as is. Nate, do you know if such BIOSen only return no IRQ at all (0 or 255) when they lie rather than a bogus "valid" IRQ? --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pci_link.c 2005/01/18 20:21:25 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pci_link.c 2005/04/05 17:46:46 @@ -621,14 +622,16 @@ device_printf(dev, "BIOS IRQ %u for %d.%d.INT%c is invalid\n", bios_irq, pcib_get_bus(pcib), slot, pin + 'A'); } else if (!PCI_INTERRUPT_VALID(link->l_bios_irq)) { - link->l_bios_irq = bios_irq; - if (bios_irq < NUM_ISA_INTERRUPTS) - pci_link_bios_isa_irqs |= (1 << bios_irq); if (bios_irq != link->l_initial_irq && PCI_INTERRUPT_VALID(link->l_initial_irq)) device_printf(dev, "BIOS IRQ %u does not match initial IRQ %u\n", bios_irq, link->l_initial_irq); + else { + link->l_bios_irq = bios_irq; + if (bios_irq < NUM_ISA_INTERRUPTS) + pci_link_bios_isa_irqs |= (1 << bios_irq); + } } else if (bios_irq != link->l_bios_irq) device_printf(dev, "BIOS IRQ %u for %d.%d.INT%c does not match previous BIOS IRQ %u\n", -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org