From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 8 15:50:11 2011 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0B44106564A for ; Thu, 8 Dec 2011 15:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A6BEA8FC13 for ; Thu, 8 Dec 2011 15:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pB8FoBxK000994 for ; Thu, 8 Dec 2011 15:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB8FoBZg000993; Thu, 8 Dec 2011 15:50:11 GMT (envelope-from gnats) Date: Thu, 8 Dec 2011 15:50:11 GMT Message-Id: <201112081550.pB8FoBZg000993@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: John Baldwin Cc: Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:50:11 -0000 The following reply was made to PR amd64/162708; it has been noted by GNATS. From: John Baldwin To: "David J. Weller-Fahy" Cc: Peter Jeremy , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620 Date: Thu, 08 Dec 2011 10:48:37 -0500 On 12/3/11 10:11 PM, David J. Weller-Fahy wrote: > * John Baldwin [2011-11-29 15:30 -0500]: >> Try adding 'debug.acpi.disabled=hostres' at the loader prompt. > > Ah-hah - that worked! The delay was me testing that booting from CD, > then upgrading my 8.2 w/ ZFS v28 system to 9.0-RC2 via freebsd-update, > including "debug.acpi.disabled=hostres" in my `/boot/loader.conf`, and > completing the update (including performing a complete reinstall of all > ports using portmaster). > > Thanks for the help, and is there anything I need to try to see what > needs to be fixed? Do you need information from this machine? > > I'm keeping the second hard-drive clear right now just in case I need to > do some test installs. Well, it's more that your BIOS is providing inaccurate or incomplete information about what address ranges your Host-PCI bridges understand. That's not easily fixable (the tunable just ignores what the BIOS says). At some point what I may do is make the check more lenient so that always we trust requests for specific ranges. Hmm, can you try this patch without the tunable: Index: /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pcib_acpi.c =================================================================== --- /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pcib_acpi.c (revision 228311) +++ /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pcib_acpi.c (working copy) @@ -511,8 +511,16 @@ sc = device_get_softc(dev); res = pcib_host_res_alloc(&sc->ap_host_res, child, type, rid, start, end, count, flags); + /* + * XXX: If this is a request for a specific range, assume it is + * correct and pass it up to the parent. What we probably want to + * do long-term is explicitly trust any firmware-configured + * resources during the initial bus scan on boot and then disable + * this after that. + */ if (res == NULL && start + count - 1 == end) - res = acpi_alloc_sysres(child, type, rid, start, end, count, flags); + res = bus_generic_alloc_resource(dev, child, type, rid, start, end, + count, flags); return (res); #else return (bus_generic_alloc_resource(dev, child, type, rid, start, end, -- John Baldwin