Date: Tue, 26 Jun 2012 10:08:07 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: Garrett Wollman <wollman@bimajority.org> Subject: Re: IPMI attachment fails: vendor bug, or just unusual choice? Message-ID: <201206261008.07210.jhb@freebsd.org> In-Reply-To: <20453.14061.23653.52464@hergotha.csail.mit.edu> References: <20453.14061.23653.52464@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <IPMI System Interface> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206261008.07210.jhb>