amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620

[John Baldwin]

The following reply was made to PR amd64/162708; it has been noted by GNATS.

From: John Baldwin <jhb at FreeBSD.org>
To: "David J. Weller-Fahy" <dave-freebsd-gnats at weller-fahy.com>
Cc: Peter Jeremy <peterjeremy at acm.org>, freebsd-gnats-submit at 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<jhb at freebsd.org>  [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