From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 17 22:25:33 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCC7F16A41F for ; Thu, 17 Nov 2005 22:25:32 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3398443D45 for ; Thu, 17 Nov 2005 22:25:32 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 2139412 for ; Thu, 17 Nov 2005 17:25:33 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jAHMPPb8029333 for ; Thu, 17 Nov 2005 17:25:27 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: acpi@freebsd.org Date: Thu, 17 Nov 2005 17:25:27 -0500 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_XNQfD9rFPouyaeS" Message-Id: <200511171725.27877.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 X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: [PATCH] Fix weird PCI bus numbers with pci_linkX X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2005 22:25:33 -0000 --Boundary-00=_XNQfD9rFPouyaeS Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I think I figured out why some people get messages like: pci_linkX: BIOS IRQ 11 for -17777216.6.INTA is invalid I was not reading the bus number from the bridge device correctly (the normal __BUS_ACCESSOR() macros assume that the passed in argument is a child device, but at the time I'm reading the bus there is no child device, so I was passing in the pcib device, the parent of the pcib device probably returned an error, and the bus variable ended up being some random stack garbage). The attached patch (also at URL) should fix it I think. http://www.FreeBSD.org/~jhb/patches/acpi_pci_link.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org --Boundary-00=_XNQfD9rFPouyaeS--