From owner-freebsd-stable@FreeBSD.ORG Sat Sep 13 15:20:20 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B46F106566B; Sat, 13 Sep 2008 15:20:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C69C48FC17; Sat, 13 Sep 2008 15:20:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8DFKDP2059360; Sat, 13 Sep 2008 11:20:13 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce M Simpson Date: Sat, 13 Sep 2008 11:09:06 -0400 User-Agent: KMail/1.9.7 References: <48C8F684.8090409@incunabulum.net> <200809111043.18265.jhb@freebsd.org> <48CB21C7.9050706@incunabulum.net> In-Reply-To: <48CB21C7.9050706@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809131109.06694.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Sat, 13 Sep 2008 11:20:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8230/Fri Sep 12 20:08:14 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jeremy Chadwick , FreeBSD stable Subject: Re: alpm(4) I/O range is claimed by ACPI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 15:20:20 -0000 On Friday 12 September 2008 10:13:27 pm Bruce M Simpson wrote: > John Baldwin wrote: > > Umm, ACPI will allow children devices to allocate their resources out of > > the "sysresource" pool. IPMI has to do this on some systems where ACPI > > claims the IPMI I/O ports as a system resource. > > But surely if alpm(4) were to attach to such a range in this way, it > would need to be a child of the acpi bus device, yes? No, the code in acpi_alloc_resources() does _not_ check for that. Any child device with a specific allocation that falls in a system resource range will succeed the allocation. > The IPMI driver > probes for a specific ACPI ID in the DSDT. The IPMI driver also attaches on the isa0 device via the SMBIOS tables, and that is the case where the resources clash with ACPI's system resources. IPMI devices listed in the ACPI namespace don't have their resources listed in ACPI's system resources. > PCI ID looks like this: > alpm0@pci0:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9 > rev=0x00 hdr=0x00 > > So I grabbed the M1543 datasheet off the web and looked in CSR space. > Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the > PMU. The function is still visible, it just has no active I/O mappings. > No wonder alpm(4) does not attach. > > I tried looking for this device in the DSDT, I don't see anything which > obviously resembles it. The equivalent Linux driver has a means of > forcing the mapping to be set up if it isn't available: > http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 > > It looks like there used to be a means of doing this in the FreeBSD > driver but it got nuked. And that ASUS didn't much care about power > management support in this machine... If you can re-enable it in such a way that it uses bus_alloc_resource(), then the driver will probably work fine. > Oh well! I know ichsmb works on at least one machine that I have. > > cheers > BMS -- John Baldwin