Bug 195311 - Bisected - New warning `can't evaluate _CRS: 12316`
Summary: Bisected - New warning `can't evaluate _CRS: 12316`
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Robert Moore
URL:
Keywords:
: 195319 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-04-10 14:13 UTC by Paul Menzel
Modified: 2017-04-18 10:00 UTC (History)
7 users (show)

See Also:
Kernel Version: 4.11-rc5
Tree: Mainline
Regression: Yes


Attachments
Output of `journalctl -k -a` (68.02 KB, text/plain)
2017-04-10 14:13 UTC, Paul Menzel
Details
Output of `acpidump` with commit 57707a9a77 reverted (63.58 KB, text/plain)
2017-04-11 06:36 UTC, Paul Menzel
Details
Output of `acpidump` (Linux with commit 57707a9a77 reverted) (65.38 KB, text/plain)
2017-04-13 19:54 UTC, Paul Menzel
Details

Description Paul Menzel 2017-04-10 14:13:46 UTC
Created attachment 255807 [details]
Output of `journalctl -k -a`

When testing the release candidates of Linux 4.11, at least rc5 and rc6, the new warning `can't evaluate _CRS: 12316` is shown.

```
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:04: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
Apr 10 08:32:58 lenovo-x60 kernel: pnp 00:05: Plug and Play ACPI device, IDs PNP0f13 (active)
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)
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)
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)
```

Besides the new messages, I didn’t notice any regressions due to this yet.

Could this be related to commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer length too long) [1]?

I would welcome a hint to the user, what to do, though. Like “This is most likely a firmware issue. Contact the vendor.” or something similar.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57707a9a778
Comment 1 Zhang Rui 2017-04-10 23:03:41 UTC
please attach the acpidump output.
Comment 2 Zhang Rui 2017-04-10 23:04:28 UTC
can you confirm if the problem is gone after revert commit 57707a9a77 ?
Comment 3 Paul Menzel 2017-04-11 06:24:35 UTC
(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.
Comment 4 Paul Menzel 2017-04-11 06:36:37 UTC
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.
Comment 5 Zhang Rui 2017-04-11 06:43:09 UTC
grep . /sys/bus/pnp/devices/00\:0*/firmware_node/path
Comment 6 Zhang Rui 2017-04-11 06:43:37 UTC
you don't need to attach that. sorry for the noise
Comment 7 Zhang Rui 2017-04-11 06:49:17 UTC
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.
Comment 8 Paul Menzel 2017-04-11 07:44:28 UTC
(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.
Comment 9 Zhang Rui 2017-04-13 12:51:27 UTC
*** Bug 195319 has been marked as a duplicate of this bug. ***
Comment 10 Paul Menzel 2017-04-13 16:23:07 UTC
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.
Comment 11 Robert Moore 2017-04-13 16:31:12 UTC
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.
Comment 12 Paul Menzel 2017-04-13 19:54:22 UTC
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.
Comment 13 Zhang Rui 2017-04-18 00:25:23 UTC
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>
Comment 14 Paul Menzel 2017-04-18 07:26:17 UTC
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>
```
Comment 15 Zhang Rui 2017-04-18 07:28:35 UTC
hah, I see.

Bug closed.
Comment 16 Paul Menzel 2017-04-18 10:00:13 UTC
Please note, the issue in coreboot is fixed with change #19284 [1].

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

Note You need to log in before you can comment on or make changes to this bug.