please attach the acpidump output.

can you confirm if the problem is gone after revert commit 57707a9a77 ?

(In reply to Zhang Rui from comment #2)
> can you confirm if the problem is gone after revert commit 57707a9a77 ?

Yes, after reverting commit 57707a9a77 on top of Linux 4.11-rc6 the warnings are gone.

Created attachment 255819 [details]
Output of `acpidump` with commit 57707a9a77 reverted

(In reply to Zhang Rui from comment #1)
> please attach the acpidump output.

Done.

grep . /sys/bus/pnp/devices/00\:0*/firmware_node/path

you don't need to attach that. sorry for the noise

Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:06: can't evaluate _CRS: 12316
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:06: Plug and Play ACPI device, IDs WACf004 (active)

            Name (_HID, EisaId ("WACF004"))  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0200,             // Range Minimum
                    0x0200,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {5}
            })

Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:07: can't evaluate _CRS: 12316
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active)

            Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM Serial Port */)  // _HID: Hardware ID
            Name (_UID, 0x02)  // _UID: Unique ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x03F8,             // Range Minimum
                    0x03F8,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {4}
            })

Some of the ASL causes the warning is attached.

BTW,
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:08: can't evaluate _CRS: 12316
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:08: Plug and Play ACPI device, IDs PNP0c31 (active)
I don't find the ASL code for this PNP0C31 device, weird.
So, Paul, I still need you to attach the output of "grep . /sys/bus/pnp/devices/00\:0*/firmware_node/path" to confirm which device PNP 00:08 is.

(In reply to Zhang Rui from comment #7)

[…]

> BTW,
> Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:08: can't evaluate _CRS: 12316
> Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:08: Plug and Play ACPI device, IDs
> PNP0c31 (active)
> I don't find the ASL code for this PNP0C31 device, weird.
> So, Paul, I still need you to attach the output of "grep .
> /sys/bus/pnp/devices/00\:0*/firmware_node/path" to confirm which device PNP
> 00:08 is.

I am sorry about the confusion. I believe that is the TPM chip, which I had disabled in the firmware in this run.

*** Bug 195319 has been marked as a duplicate of this bug. ***

Just for your interest:


On 04/13/17 18:12, Rafael J. Wysocki wrote:

[…]

> OK, I'll do a revert in Linux separately as 4.11 is only several days
> away and that needs to be sorted out ASAP.

For the commit in question (57707a9a77), the code attempts to validate that the actual resource buffer length is the same length as the buffer initialization list.

The ACPICA resource code in this commit is making an assumption that the buffer has been created via the ResourceTemplate mechanism and therefore should be "well formed" in the sense that the buffer length defined in the AML should be exactly the same as the length of the initializer list.

In the case in question, the AML (DSDT/SSDT) does in fact contain resource template buffers that have a length that is longer than the initializer list. Apparently, these template buffers have been crafted manually, thus the discrepancy.

This is causing runtime exception(s), aborting some important control method(s).

Therefore, this commit must in fact be reverted.

Created attachment 255881 [details]
Output of `acpidump` (Linux with commit 57707a9a77 reverted)

(In reply to Paul Menzel from comment #8)
> (In reply to Zhang Rui from comment #7)
> 
> […]
> 
> > BTW,
> > Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:08: can't evaluate _CRS: 12316
> > Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:08: Plug and Play ACPI device,
> IDs
> > PNP0c31 (active)
> > I don't find the ASL code for this PNP0C31 device, weird.
> > So, Paul, I still need you to attach the output of "grep .
> > /sys/bus/pnp/devices/00\:0*/firmware_node/path" to confirm which device PNP
> > 00:08 is.
> 
> I am sorry about the confusion. I believe that is the TPM chip, which I had
> disabled in the firmware in this run.

I enabled TPM support in coreboot, and here is the full output with the missing device in my comment.

```
$ grep . /sys/bus/pnp/devices/00\:0*/firmware_node/path
/sys/bus/pnp/devices/00:00/firmware_node/path:\_SB_.PCI0.PDRC
/sys/bus/pnp/devices/00:01/firmware_node/path:\_SB_.PCI0.LPCB.HPET
/sys/bus/pnp/devices/00:02/firmware_node/path:\_SB_.PCI0.LPCB.LDRC
/sys/bus/pnp/devices/00:03/firmware_node/path:\_SB_.PCI0.LPCB.RTC_
/sys/bus/pnp/devices/00:04/firmware_node/path:\_SB_.PCI0.LPCB.PS2K
/sys/bus/pnp/devices/00:05/firmware_node/path:\_SB_.PCI0.LPCB.PS2M
/sys/bus/pnp/devices/00:06/firmware_node/path:\_SB_.PCI0.LPCB.DTR_
/sys/bus/pnp/devices/00:07/firmware_node/path:\_SB_.PCI0.LPCB.COMA
/sys/bus/pnp/devices/00:08/firmware_node/path:\_SB_.PCI0.LPCB.TPM_
```

Please also find the output of `sudo acpidump` attached.

Hi, Rafael,

This regression is caused by the following commit, and it should be reverted according to comment #11.
will you revert the commit directly, or do you want us to send a Linux revert patch to the list?

commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3
Author:     Bob Moore <robert.moore@intel.com>
AuthorDate: Wed Dec 28 15:29:28 2016 +0800
Commit:     Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CommitDate: Mon Jan 2 23:18:47 2017 +0100

    ACPICA: Resources: Not a valid resource if buffer length too long
    
    ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1
    ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a
    ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e
    
    The declared buffer length must be the same as the length of the
    byte initializer list, otherwise not a valid resource descriptor.
    
    Link: https://github.com/acpica/acpica/commit/9f76de2d
    Link: https://github.com/acpica/acpica/commit/b2e89d72
    Link: https://github.com/acpica/acpica/commit/23b5bbe6
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Zhang, Linus already merged Rafael’s pull merge/request with the revert.

```
commit 1315f01632da417f1f27074bc6631df8eaf223bb
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Apr 13 18:14:55 2017 +0200

    Revert "ACPICA: Resources: Not a valid resource if buffer length too long"
    
    Revert commit 57707a9a7780 (ACPICA: Resources: Not a valid resource if
    buffer length too long) as it is reported to prevent the TPM module
    from loading on Lenovo X60 with Coreboot.
    
    It also causes new confusing warnings to show up in the kernel log.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=195311
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
```

hah, I see.

Bug closed.

Please note, the issue in coreboot is fixed with change #19284 [1].

[1] https://review.coreboot.org/19284/