From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 17 12:31:59 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 B5AE41C2 for ; Sun, 17 Aug 2014 12:31:59 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1F8224F for ; Sun, 17 Aug 2014 12:31:59 +0000 (UTC) Received: from [192.168.42.211] (unknown [172.16.2.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 5435955FB2 for ; Sun, 17 Aug 2014 12:31:58 +0000 (UTC) Message-ID: <53F0A0BD.5060508@metricspace.net> Date: Sun, 17 Aug 2014 08:31:57 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: Re: ACPI error messages on Lenovo W540 References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> <53A8AD54.8040908@metricspace.net> <201406241000.35812.jhb@freebsd.org> <53AA1D05.6000304@metricspace.net> In-Reply-To: <53AA1D05.6000304@metricspace.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 12:31:59 -0000 Finally got time to do some more poking around regarding this. I haven't read the entire ACPI spec, so bear with me... As John Baldwin said, the wrapper nvidia_acpi.c passes in a buffer instead of a package. In the definition for _DSM, you can see calls to NVOP, NVPS, and NBCI. I looked at all three, and they seem to treat Arg3 as a buffer as well (they call CreateField on it, which according to the ACPI spec, should take a buffer argument). So it looks like both the nvidia driver as well as the ALS code are pretty thoroughly convinced that Arg3 (the fourth arg) is a buffer instead of a package, despite what the spec says about what it "should" be. Could this possibly be fixed by adding some kind of quirk to the ACPI execution engine that says "_DSM's fourth argument is a buffer"? On 06/24/2014 20:51, Eric McCorkle wrote: > > It looks like this is the definition: > > Method (_DSM, 4, NotSerialized) // _DSM: > Device-Specific Method > { > If (\CMPB (Arg0, Buffer (0x10) > { > /* 0000 */ 0xF8, 0xD8, 0x86, > 0xA4, 0xDA, 0x0B, 0x1B, 0x47, > /* 0008 */ 0xA7, 0x2B, 0x60, > 0x42, 0xA6, 0xB5, 0xBE, 0xE0 > })) > { > Return (NVOP (Arg0, Arg1, Arg2, Arg3)) > } > > If (\CMPB (Arg0, Buffer (0x10) > { > /* 0000 */ 0x01, 0x2D, 0x13, > 0xA3, 0xDA, 0x8C, 0xBA, 0x49, > /* 0008 */ 0xA5, 0x2E, 0xBC, > 0x9D, 0x46, 0xDF, 0x6B, 0x81 > })) > { > Return (NVPS (Arg0, Arg1, Arg2, Arg3)) > } > > If (\WIN8) > { > If (\CMPB (Arg0, Buffer (0x10) > { > /* 0000 */ 0x75, 0x0B, 0xA5, > 0xD4, 0xC7, 0x65, 0xF7, 0x46, > /* 0008 */ 0xBF, 0xB7, 0x41, > 0x51, 0x4C, 0xEA, 0x02, 0x44 > })) > { > Return (NBCI (Arg0, Arg1, Arg2, Arg3)) > } > } > > Return (Buffer (0x04) > { > 0x01, 0x00, 0x00, 0x80 > }) > } > > Not sure if that's helpful at all... > >> Ah, the nvidia driver calls _DSM and it has the bug. In its >> nvidia_acpi.c file >> it uses a Buffer instead of a Package for the fourth argument to >> _DSM. OTOH, the >> warning doesn't prevent the method from running, so the warning may be >> harmless. >> You can try contacting the nvidia folks to tell them about the warning >> and point >> out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say. > > Will do. Is there a preferred point of contact?