From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 28 17:35:14 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9214713 for ; Tue, 28 Jan 2014 17:35:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1DEB14F2 for ; Tue, 28 Jan 2014 17:35:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2FD46B94F; Tue, 28 Jan 2014 12:35:13 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: ACPI issues with PC engines APU beta board Date: Tue, 28 Jan 2014 10:53:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140122163215.GA46029@gta.com> In-Reply-To: <20140122163215.GA46029@gta.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401281053.08242.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Jan 2014 12:35:13 -0500 (EST) Cc: Larry Baird X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:35:14 -0000 On Wednesday, January 22, 2014 11:32:15 am Larry Baird wrote: > I have a protoype board from PC Engines for their upcoming APU board. > The board runs fine under FreeBSD 8.4 release but fails to boot using either > FreeBSD 9.2 release or FreeBSD 10.0 release. Verbose boot seems to indicate > issue is with ACPI. I am working with PC Engines to get FreeBSD up and > running on their board. Hopefully attached information is enough to > determine issue with BIOS. I'll then feed this information back to PC > Engines so they can provide the information to their BIOS provider. > > Attached is a verbose dmesg from 9.2. In case it gets stripped you > can also find dmesg at: ftp://ftp.gta.com/pub/apu/FreeBSD9.2/bootVerbose.txt > > Dmesg from booting 8.4 is at: ftp://ftp.gta.com/pub/apu/FreeBSD8.4/dmesg.boot > > Dump of sysctl.hw.acpi from FreeBSD 8.4 is: > > hw.acpi.supported_sleep_state: S1 S2 S3 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 1 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > > acpidump -dt from from FreeBSD 8.4 is at: > ftp://ftp.gta.com/pub/apu/FreeBSD8.4/lab-pcengines-apu1b.asl The BIOS is busted. The resource ranges that the Host-PCI bridge decodes are marked as regular resources when they should be ResourceProducer ranges instead. They have this correct for I/O port resources, but not memory. You can try this workaround: Index: sys/dev/acpica/acpi.c =================================================================== --- acpi.c (revision 261235) +++ acpi.c (working copy) @@ -1190,6 +1190,7 @@ acpi_set_resource(device_t dev, device_t child, in struct acpi_softc *sc = device_get_softc(dev); struct acpi_device *ad = device_get_ivars(child); struct resource_list *rl = &ad->ad_rl; + ACPI_DEVICE_INFO *devinfo; u_long end; /* Ignore IRQ resources for PCI link devices. */ @@ -1196,6 +1197,21 @@ acpi_set_resource(device_t dev, device_t child, in if (type == SYS_RES_IRQ && ACPI_ID_PROBE(dev, child, pcilink_ids) != NULL) return (0); + /* + * Ignore memory resources for PCI root bridges. Some BIOSes + * incorrectly enumerate the memory ranges they decode as plain + * memory resources instead of as a ResourceProducer range. + */ + if (type == SYS_RES_MEMORY) { + if (ACPI_SUCCESS(AcpiGetObjectInfo(ad->ad_handle, &devinfo))) { + if ((devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) != 0) { + AcpiOsFree(devinfo); + return (0); + } + AcpiOsFree(devinfo); + } + } + /* If the resource is already allocated, fail. */ if (resource_list_busy(rl, type, rid)) return (EBUSY); -- John Baldwin