From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 01:08:10 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 B6CE316A4CE for ; Tue, 12 Apr 2005 01:08:10 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72C1943D3F for ; Tue, 12 Apr 2005 01:08:10 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21211 invoked from network); 12 Apr 2005 01:08:10 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 12 Apr 2005 01:08:09 -0000 Received: from [131.106.57.68] (p178.n-lapop01.stsn.com [12.129.240.178]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3C17mbn016686; Mon, 11 Apr 2005 21:07:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 11 Apr 2005 20:31:24 -0400 User-Agent: KMail/1.8 References: <200504081529.33026.jhb@FreeBSD.org> <20050409115745.31a0059c.antoine.brodin@laposte.net> In-Reply-To: <20050409115745.31a0059c.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: <200504112031.26979.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED 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, 12 Apr 2005 01:08:10 -0000 On Saturday 09 April 2005 05:57 am, Antoine Brodin wrote: > John Baldwin wrote: > > 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? > > I've just sent a technical support request to ASUS. I'll let you know > when they reply. > Linux doesn't have the same problem: I tested with a knoppix live cd > yesterday. > dmesg: http://bsd.miki.eu.org/~antoine/knoppix36.dmesg , but it doesn't > look very helpful. Actually, it is. What Linux is doing is probing all the link devices before it probes any PCI devices, so all the _DIS calls happen before any interrupts are routed. I believe Nate knows how to get FreeBSD to do something similar via a hack. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org