From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 26 14:08:10 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E62A4106566B for ; Tue, 26 Jun 2012 14:08:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBD5E8FC08 for ; Tue, 26 Jun 2012 14:08:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E10ECB988; Tue, 26 Jun 2012 10:08:09 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 26 Jun 2012 10:08:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20453.14061.23653.52464@hergotha.csail.mit.edu> In-Reply-To: <20453.14061.23653.52464@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206261008.07210.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Jun 2012 10:08:10 -0400 (EDT) Cc: Garrett Wollman Subject: Re: IPMI attachment fails: vendor bug, or just unusual choice? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:08:11 -0000 On Friday, June 22, 2012 11:24:29 pm Garrett Wollman wrote: > On my Quanta QSSC-S99Q, the IPMI driver has trouble using the ACPI > attachment. It reports: > > ipmi0: on acpi0 > ipmi0: unknown resource type > device_attach: ipmi0 attach returned 6 > > It then goes on to find it the old-fashioned way as ipmi1, which > sometimes works and sometiems doesn't. (Not worrying about that part > yet -- I think it's a timing issue.) > > Looking at the code, it looks like this can only happen if there are > neither I/O port nor memory resources defined for this device. > However, there clearly is one in the AML: > > Device (MI0) > { > Name (_HID, EisaId ("IPI0001")) > Method (_STA, 0, NotSerialized) > { > If (LEqual (OSN, Zero)) > { > Return (Zero) > } > > Return (0x0F) > } > > Name (_STR, Unicode ("IPMI_KCS")) > Name (_UID, Zero) > Name (_CRS, ResourceTemplate () > { > IO (Decode16, > 0x0CA2, // Range Minimum > 0x0CA3, // Range Maximum > 0x00, // Alignment > 0x02, // Length > ) > }) > Method (_IFT, 0, NotSerialized) > { > Return (One) > } > > Method (_SRV, 0, NotSerialized) > { > Return (0x0200) > } > } > > Did the vendor screw this up by writing this as a port range? Or is > this perfectly legitimate and just not implemented? Yes, the vendor screwed this up. The "range" is a range of valid starting addresses (not a range from which the entire resource must be sub-allocated), so what they should have done was used 0xCA2 as the range maximum. You can try patching your ASL to change that to use 0xCA3. That said, I believe that a true range should only show up in _PRS, not in _CRS, so we might be able to use your workaround for parsing _CRS. (_CRS should only return assigned resources, so those should always be fixed, not variable ranges.) If you can convince Quanta to fix their BIOS that would be the best result however. -- John Baldwin