From owner-cvs-src@FreeBSD.ORG Fri Sep 16 07:02:30 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2950C16A41F; Fri, 16 Sep 2005 07:02:30 +0000 (GMT) (envelope-from imp@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC12243D4C; Fri, 16 Sep 2005 07:02:29 +0000 (GMT) (envelope-from imp@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id j8G72TTf063545; Fri, 16 Sep 2005 07:02:29 GMT (envelope-from imp@repoman.freebsd.org) Received: (from imp@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j8G72TBv063544; Fri, 16 Sep 2005 07:02:29 GMT (envelope-from imp) Message-Id: <200509160702.j8G72TBv063544@repoman.freebsd.org> From: Warner Losh Date: Fri, 16 Sep 2005 07:02:29 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/dev/acpica acpi_pcib_acpi.c src/sys/i386/pci pci_bus.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 07:02:30 -0000 imp 2005-09-16 07:02:29 UTC FreeBSD src repository Modified files: sys/dev/acpica acpi_pcib_acpi.c sys/i386/pci pci_bus.c Log: Commit a workaround to a problem with resource allocation. This helps with some Dell servers that booted w/o a problem[*] on 5.4, but failed with 6.0-BETA. On the PCI bus, when we do lazy resource allocation, we narrow the range requested as we pass through bridges to reflect how the bridges are programmed and what addresses they pass. However, when we're doing an allocation on a bus that's directly connected to a host bridge, no such translation can take place. We already had a fallback range for memory requests, but none for ioports. As such, provide a fallback for I/O ports so we don't allocate location 0, which will have undesired side effects when the resources are actually used. This fixes a problem with booting a Dell server with usb in the kernel. However, it is an unsatisfying solution. I don't like the hard coded value, and I think we should start narrowing the resources returned to not be in the so-called isa alias area (where the ranage & 0x0300 must be 0 iirc). Doing such filtering will have to wait for another day. This may be a good 6 candidate, maybe after its had a chance to be refined. Tested by: glebius@ Revision Changes Path 1.49 +2 -0 src/sys/dev/acpica/acpi_pcib_acpi.c 1.120 +2 -0 src/sys/i386/pci/pci_bus.c