Please attach acpidump from the affected machine.

Created attachment 255665 [details]
Acpidump

This is the acpidump.

First of all, it looks like the caller of _DSM is incorrectly passing in a buffer object instead of the required package object.

We can run some small test cases to get more info.

(In reply to lolo.branstett from comment #2)
> Created attachment 255665 [details]
> Acpidump
> 
> This is the acpidump.

Also attach full DMESG

This issue is harmless in most cases. This occurs when GPU driver pass buffer as 4th Argument to _DSM method instead of package. NVIDIA drivers are known to do this (on both Linux and MS Windows). Even though its violating ACPI specifications, its know to happen more often in practice. I don't think Linux will fix this in ACPIA, given its not a bug technically. 

If you attach full DMESG, we can see if this is having any harmful effect.

Thanks,
Tagore

This issue has already been referenced on acpica.
https://bugs.acpica.org/show_bug.cgi?id=1333

It appears to be work in progress.

Created attachment 255679 [details]
dmesg

This is the full dmesg.

(In reply to tagorereddy from comment #5)
> This issue is harmless in most cases. This occurs when GPU driver pass
> buffer as 4th Argument to _DSM method instead of package. NVIDIA drivers are
> known to do this (on both Linux and MS Windows). Even though its violating
> ACPI specifications, its know to happen more often in practice. I don't
> think Linux will fix this in ACPIA, given its not a bug technically. 
> 
> If you attach full DMESG, we can see if this is having any harmful effect.
> 
> Thanks,
> Tagore

Okay, but I don't use the NVIDIA drivers. I use the nouveau driver (https://wiki.archlinux.org/index.php/Nouveau).

Any update ?

The problem is still here with the kernel 4.17.x

The affected code is likely:

    If ((Arg0 == ToUUID ("a486d8f8-0bda-471b-a72b-6042a6b5bee0")))
    {
        Local0 = Zero
        Local0 = (DerefOf (Arg3 [0x03]) << 0x18)
        Local0 += (DerefOf (Arg3 [0x02]) << 0x10)
        Local0 += (DerefOf (Arg3 [One]) << 0x08)
        Local0 += (DerefOf (Arg3 [Zero]) << Zero)

The reason a Buffer is passed by nouveau instead of a Package is presumably due to an issue with the Windows driver that did the wrong thing, and firmware authors adapting that.

I am quite puzzled though with this behavior:

[   13.439026] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20160930/exoparg2-427)
[   13.439088] ACPI Error: Method parse/execution failed [\_SB.PCI0.GFX0._DSM] (Node ffff8801c84b9780), AE_AML_PACKAGE_LIMIT (20160930/psparse-543)
[   13.439153] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.GFX0._DSM] (Node ffff8801c84ce7a8), AE_AML_PACKAGE_LIMIT (20160930/psparse-543)
[   13.439222] ACPI: \_SB_.PCI0.PEG0.GFX0: failed to evaluate _DSM (0x300b)
[   13.439383] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, 
[   13.439388] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.GFX0 handle

In both cases, the method invocation failed, and I would expect nouveau_optimus_dsm to set 0 as result:

    static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
    {
        ...
        *result = 0;
        obj = acpi_evaluate_dsm_typed(handle, &nouveau_op_dsm_muid, 0x00000100,
                func, &argv4, ACPI_TYPE_BUFFER);
        if (!obj) {
            acpi_handle_info(handle, "failed to evaluate _DSM\n");
            return AE_ERROR;
        }

and I would expect "optimus capabilities: disabled, status " since "

    uint32_t result;
    nouveau_optimus_dsm(dhandle, NOUVEAU_DSM_OPTIMUS_CAPS, 0,
            &result);
    dev_info(&pdev->dev, "optimus capabilities: %s, status %s%s\n",
            (result & OPTIMUS_ENABLED) ? "enabled" : "disabled",
            (result & OPTIMUS_DYNAMIC_PWR_CAP) ? "dynamic power, " : "",
            (result & OPTIMUS_HDA_CODEC_MASK) ? "hda bios codec supported" : "");

However that does not seem to be the case, so either the Linux ACPI module does some kind of fallback, or there is some other kind of memory issue.

Since you reported an issue "since 4.9.6", there was presumably a working version. Can you do a git bisect?

for me 5.4.8 is working

on a HP ZBook 17 G4
17: PCI 100.0: 0300 VGA compatible controller (VGA)             
  [Created at pci.386]
  Unique ID: VCu0.mCEkXGSxUXA
  Parent ID: vSkL.fBtNDRZZiP3
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "nVidia GP104GLM [Quadro P4000 Mobile]"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x1bb7 "GP104GLM [Quadro P4000 Mobile]"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x8272 
  Revision: 0xa1
  Driver: "nvidia"
  Driver Modules: "nvidia"
  Memory Range: 0xe3000000-0xe3ffffff (rw,non-prefetchable)
  Memory Range: 0xa0000000-0xafffffff (ro,non-prefetchable)
  Memory Range: 0xb0000000-0xb1ffffff (ro,non-prefetchable)
  I/O Ports: 0x5000-0x5fff (rw)
  Memory Range: 0xe4080000-0xe40fffff (ro,non-prefetchable,disabled)
  IRQ: 173 (41186 events)
  Module Alias: "pci:v000010DEd00001BB7sv0000103Csd00008272bc03sc00i00"
  Driver Info #0:
    Driver Status: nouveau is not active
    Driver Activation Cmd: "modprobe nouveau"
  Driver Info #1:
    Driver Status: nvidia_drm is active
    Driver Activation Cmd: "modprobe nvidia_drm"
  Driver Info #2:
    Driver Status: nvidia is active
    Driver Activation Cmd: "modprobe nvidia"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #13 (PCI bridge)

Primary display adapter: #17