ACPI error messages on Lenovo W540

[Eric McCorkle]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"