From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 17:43:17 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 BCCBF16A4CE; Thu, 7 Apr 2005 17:43:17 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EDCB43D31; Thu, 7 Apr 2005 17:43:17 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j37HhFLS008522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Apr 2005 10:43:16 -0700 Message-ID: <42557133.2070802@root.org> Date: Thu, 07 Apr 2005 10:43:15 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200504051110.35735.jhb@FreeBSD.org> <20050405185831.2484695e.antoine.brodin@laposte.net> <200504051349.13620.jhb@FreeBSD.org> In-Reply-To: <200504051349.13620.jhb@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.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: Thu, 07 Apr 2005 17:43:17 -0000 John Baldwin wrote: > 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", When link devices are uninitialized by the BIOS, you usually get an invalid IRQ (i.e. 255 or 0). However, there are some cases where you get a valid PCI irq but invalid for this system (i.e. not in the supported ones advertised by _PRS). For instance, you might get a value of 15 for a link that only supports 3,4,5,6,7,9, etc. I think you should be checking _PRS for validity, not just PCI_INTERRUPT_VALID (i.e. !255). Aren't you doing that already? -- Nate