From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 17 15:17:23 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BB90EC7 for ; Sun, 17 Aug 2014 15:17:23 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 5509C228F for ; Sun, 17 Aug 2014 15:17:23 +0000 (UTC) Received: from [192.168.42.206] (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 9066F43635 for ; Sun, 17 Aug 2014 15:17:15 +0000 (UTC) Message-ID: <53F0C77A.5050103@metricspace.net> Date: Sun, 17 Aug 2014 11:17:14 -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> <53F0A0BD.5060508@metricspace.net> In-Reply-To: <53F0A0BD.5060508@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 15:17:23 -0000 Actually, I managed to get a kernel panic to happen, which provides some more information: NVRM: GPU at 0000:01:00.0 has fallen off the bus. NVRM: RmInitAdapter failed! (0x25:0x28:1169) nvidia0: NVRM: rm_init_adapter() failed! Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff817eeeb5 stack pointer = 0x28:0xfffffe021d481420 frame pointer = 0x28:0xfffffe021d481500 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 3 current process = 73254 (Xorg) trap number = 12 panic: page fault cpuid = 2 Uptime: 12h17m8s It looks like rm_init_adapter is contained in nvidia's .o file that comes with the driver, so I'm out of luck for trying to track it down. I can't tell whether this is caused by the ACPI errors or not... On 08/17/2014 08:31, Eric McCorkle wrote: > 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? > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"