Bug 109511 - ACPI error messages caused by undefined object - Dell XPS 13 9350
Summary: ACPI error messages caused by undefined object - Dell XPS 13 9350
Status: CLOSED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Erik Kaneda
URL:
Keywords:
: 198877 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-17 02:47 UTC by Lv Zheng
Modified: 2018-06-26 01:10 UTC (History)
11 users (show)

See Also:
Kernel Version: 4.4-rc3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Acpidump of the machine (138.81 KB, application/octet-stream)
2015-12-17 02:47 UTC, Lv Zheng
Details
Output of dmesg (11.29 KB, application/octet-stream)
2015-12-17 02:49 UTC, Lv Zheng
Details
[PATCH] ACPICA: Log Exceptions and Errors as warning while loading extra tables (5.01 KB, patch)
2018-01-11 19:30 UTC, Hans de Goede
Details | Diff
[PATCH 1/2] ACPICA: acpi_ds_resolve_package_element: Use proper status when logging exception (1.34 KB, patch)
2018-01-12 11:41 UTC, Hans de Goede
Details | Diff
[PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings (3.73 KB, patch)
2018-01-12 11:47 UTC, Hans de Goede
Details | Diff
attachment-26706-0.html (509 bytes, text/html)
2018-06-25 06:06 UTC, superm1
Details

Description Lv Zheng 2015-12-17 02:47:18 UTC
Created attachment 197521 [details]
Acpidump of the machine

From: Andy Lutomirski <luto@amacapital.net>

I'm getting this error on boot on my XPS 13 9350 with the latest
(1.1.7) firmware.

[  +0.004585] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup
failure, AE_NOT_FOUND (20150930/psargs-359)

[  +0.000009]
              Initialized Local Variables for method [FNCL]:
[  +0.000001]   Local0: ffff880074e18318 <Obj>           Integer
0000000000000001
[  +0.000004]   Local1: ffff880074e185e8 <Obj>           Integer
0000000000000000
[  +0.000003]   Local2: ffff880074e18480 <Obj>           Integer
0000000000000000
[  +0.000003]   Local3: ffff880074e18438 <Obj>           Integer
0000000000000000
[  +0.000002]   Local4: ffff880074e18510 <Obj>           Integer
0000000000000000
[  +0.000003]   Local5: ffff880074e18630 <Obj>           Integer
0000000000000000
[  +0.000003]   Local6: ffff880074e183f0 <Obj>           Integer
0000000000000000

[  +0.000004] No Arguments are initialized for method [FNCL]

[  +0.000002] ACPI Error: Method parse/execution failed [\_TZ.FNCL]
(Node ffff88027811f4d8), AE_NOT_FOUND (20150930/psparse-542)
[  +0.000006] ACPI Error: Method parse/execution failed
[\_TZ.FN00._ON] (Node ffff8802780eeed8), AE_NOT_FOUND
(20150930/psparse-542)

I'm I'm understanding the message correctly, this means that ECAV
can't be found, but ECAV appears to be declared.
Comment 1 Lv Zheng 2015-12-17 02:49:00 UTC
Created attachment 197531 [details]
Output of dmesg
Comment 2 zetxx 2015-12-17 12:12:09 UTC
same story here, same messages with 16gb version
Comment 3 Robert Moore 2015-12-17 15:57:34 UTC
I see references to ECAV, but don't see ECAV declared in any of the tables in the acpidump:

$ grep ECAV *.dsl
ssdt3.dsl:    External (_SB_.PCI0.LPCB.H_EC.ECAV, UnknownObj)
ssdt3.dsl:                        If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                        If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                        If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                        If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt3.dsl:                If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
ssdt4.dsl:    External (_SB_.PCI0.LPCB.H_EC.ECAV, IntObj)
ssdt4.dsl:            If ((\_SB.PCI0.LPCB.H_EC.ECAV && ETMD))
ssdt4.dsl:                If (\_SB.PCI0.LPCB.H_EC.ECAV)
ssdt4.dsl:                If (\_SB.PCI0.LPCB.H_EC.ECAV)

However, there are some dynamic table loads:

$ grep Load *.dsl
ssdt7.dsl:                    Load (CST0, HC0) /* \_PR_.CPU0.HC0_ */
ssdt7.dsl:                Load (IST0, HI0) /* \_PR_.CPU0.HI0_ */
ssdt7.dsl:                        Load (HWP0, HW0) /* \_PR_.CPU0.HW0_ */
ssdt7.dsl:                            Load (HWPL, HW2) /* \_PR_.CPU0.HW2_ */
ssdt7.dsl:                Load (CST1, HC1) /* \_PR_.CPU1.HC1_ */
ssdt7.dsl:                Load (IST1, HI1) /* \_PR_.CPU1.HI1_ */
ssdt7.dsl:                    Load (HWP1, HW1) /* \_PR_.CPU1.HW1_ */
Comment 4 Andy Lutomirski 2015-12-17 16:21:38 UTC
Let me know if I can help debug anything.
Comment 5 Lv Zheng 2015-12-21 03:02:20 UTC
(In reply to Andy Lutomirski from comment #4)
> Let me know if I can help debug anything.

According to Bob, this looks like an issue of DSDT.
There's simply no ECAV defined in the tables.
So this is a BIOS bug.
Let me re-categorize it.

Thanks
-lv
Comment 6 Aaron Lu 2015-12-21 05:04:57 UTC
Will we fix it?
Comment 7 Zhang Rui 2015-12-28 13:23:13 UTC
SB_.PCI0.LPCB.H_EC.ECAV should not be defined in any dynamic SSDT tables.
So this is a BIOS bug to me. Closed.
Comment 8 Marcin Kurek 2017-03-03 15:58:47 UTC
Almost identical problem seems to be present in Precision 5510 model here using recent BIOS 1.2.19.

========
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN00._ON] (Node ffff920daa882d70), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN00._ON] (Node ffff920daa882d70), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN01._ON] (Node ffff920daa8829d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN01._ON] (Node ffff920daa8829d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN02._ON] (Node ffff920daa882c58), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN02._ON] (Node ffff920daa882c58), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN03._ON] (Node ffff920daa8824b0), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN03._ON] (Node ffff920daa8824b0), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN04._ON] (Node ffff920daa882500), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff920daa8884d8), AE_NOT_FOUND (20160930/psparse-543)
ACPI Error: Method parse/execution failed [\_TZ.FN04._ON] (Node ffff920daa882500), AE_NOT_FOUND (20160930/psparse-543)
========
It seems SB_.PCI0.LPCB.H_EC is nowhere to be found in DSDT file (so ECAV)
Comment 9 Hans de Goede 2018-01-11 19:28:53 UTC
People are still filing bugs for these and similar errors, see for example bug 198176, which is getting lots of comments and esp. bug 198167 comment 33 which clearly shows that asking vendors to fix their ACPI tables is simply not a workable solution.

People experience these kinda errors as a real problem / a real nuisance. I find closing this bug, with a resolution of "DOCUMENTED" not acceptable, esp. since there are other solutions such as lowering the log level of these messages so that they will not be shown on the console (they will still be in "dmesg" and in the logs). Therefor I'm re-opening this bug.
Comment 10 Hans de Goede 2018-01-11 19:30:04 UTC
Created attachment 273537 [details]
[PATCH] ACPICA: Log Exceptions and Errors as warning while loading extra tables

Here is a patch I've also just submitted upstream to lower the loglevel of errors while loading the extra ACPI tables from error to warning.
Comment 11 Hans de Goede 2018-01-12 11:41:58 UTC
Created attachment 273561 [details]
[PATCH 1/2] ACPICA: acpi_ds_resolve_package_element: Use proper status when logging exception

Here is a cleaner / better set of patches fixing this as well as bug 198167.
Comment 12 Hans de Goede 2018-01-12 11:47:17 UTC
Created attachment 273563 [details]
[PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings
Comment 13 Marcin Kurek 2018-01-12 12:50:01 UTC
Hmm, to be honest lowering a log level is hardly a fix and only an workaround. In this case this can be more a less correct, but in another one maybe this hides a more serious problem for the user which will be unaware of it because he can not see any message on the screen on boot.

The real solution would be force vendors to use correct code and fix this mess as this is definitly sloppy to see this kind of stuff in so expensive product. And as I mentioned in e-mail correspondence with Dell if this is not a problem why most of missing methods and tables are presend in newer XPS model ? I taken DSDT tables from my boss XPS 9560 and there is still a few missing things, but most of them are fixed and correctly present.
Comment 14 Marcin Kurek 2018-01-12 12:54:51 UTC
I am not an ACPI expert, but I tried my best to analyse and report this to Dell. For example this is a part of report about missing ECAV method after they inform me this is pure kernel related problem:

========
Hell[o]

Im still almost sure this is not kernel related as the missing
symbol/method is nowhere to be found in any of the dsdt/ssdt tables.
How it can be resolved if it's not defined ?

Assuming the naming is not random the ECDT/ECAV/etc usage pattern is
described in ACPI 6.0 specs
(www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf) in "5.2.15
Embedded Controller Boot Resources Table (ECDT)" If you have no time
to read take a quick look at upper part of page 158.

Now lets take a look at one of our errors:

------
ACPI: Thermal Zone [THM] (25 C)
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure,
AE_NOT_FOUND (20170531/psargs-382)
ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND
(20170531/psparse-550)
------

The TZ00 is defined in my case in SSDT5 and it looks OK, but take a
look at _TMP method:

--------
    ...
    Scope (\_TZ)
    {
        ...
        ThermalZone (TZ00)
        {
            Name (PTMP, 0x0BB8)
            ....
            Method (_TMP, 0, Serialized)  // _TMP: Temperature
            {
                ....
                If (\_SB.PCI0.LPCB.H_EC.ECAV)
                {
                    Local0 = \_SB.PCI0.LPCB.H_EC.ECRD (RefOf
(\_SB.PCI0.LPCB.H_EC.PLMX))
                    Local0 = (0x0AAC + (Local0 * 0x0A))
                    PTMP = Local0
                    Return (Local0)
                }

                Return (0x0BC2)
            }
        }
     }
--------

At the end of this method the "If (\_SB.PCI0.LPCB.H_EC.ECAV)" fails as
it tires to use ECAV() method which is not defined anywhere (searched
all tables and it's used in many places in some of the SSDT tables,
but it's not defined anywhere) The usage pattern is identical to
described in ACPI specification I mentioned earlier (to avoid usage of
EC if it's not available) as it seems to check if it's available by
ECAV method (I assume EC Available ?) before use ECRD() method (EC
Read ?) But this part fails always as it can not execute non existing
method. This problem can be observed not only here. The list for my
machine looks like (maybe I miss one or two):

- Scope (\_TZ) in _TMP() (described above), FNCL(), methods
- Scope(\_SB) in TSDD(), OSDD(), methods. Bellow example for _TMP:

--------
                        ....
                        If ((\_SB.PCI0.LPCB.H_EC.ECAV == One))
                        {
                            TMPV [0x05] = ((\_SB.PCI0.LPCB.H_EC.ECRD
(RefOf (\_SB.PCI0.LPCB.H_EC.TSR1)) * 0x0A) +.
                                0x0AAC)
                            TMPV [0x06] = ((\_SB.PCI0.LPCB.H_EC.ECRD
(RefOf (\_SB.PCI0.LPCB.H_EC.TSR2)) * 0x0A) +.
                            ....
------

The usage also looks like methodology used in ACPI specification.
Check is EC available by ECAV() (return Zero if not) before accessing
it by ECRD()

The funny thing is it references to \_SB.PCI0.LPCB.H_EC.ECRD but H_EC
is also not available or I can not see it anywhere and also ECAV is
never used in DSDT and only in SSDT tables which looks like some-kind
ctrl+c/ctrl+v error. Definitely something funny going here. Looking at
ACPI spec page 384 it seems the EC0 (PNP0C09) from example is for this
machine a device named  ECDV from dsdt, but it's quite hard to analyze
as I can base only on deassembled dsdt/ssdt tables.

Now lets take for example another problem not related to EC but very
similar of the problematic parts affected by this. When the AC adapter
is disconnected/connected we can observe error as follow:
--------
ACPI Error: [\_SB_.PCI0.LPCB.H_EC.CHRG] Namespace lookup failure,
AE_NOT_FOUND (20170531/psargs-382)
ACPI Error: Method parse/execution failed \PNOT, AE_NOT_FOUND
(20170531/psparse-550)
ACPI Error: Method parse/execution failed \_SB.AC._PSR, AE_NOT_FOUND
(20170531/psparse-550)
ACPI Exception: AE_NOT_FOUND, Error reading AC Adapter state (20170531/ac-128)
--------

The affected part is:
------
        If ((DPTF == One))
        {
            Notify (\_SB.IETM, 0x86) // Device-Specific
            If ((CHGE == One))
            {
                Notify (\_SB.PCI0.LPCB.H_EC.CHRG, 0x80) // Status Change
            }
        }
------

It tires to send notify to \_SB_.PCI0.LPCB.H_EC.CHRG, but there is
nothing named CHRG in all ssdt/dsdt and this is only one place where
this name appears. I guess it's hard to resolve something not present
? If not defined maybe it should be created, by one of the _REG ? Hard
to say as I base only on ACPI spec file and deassembled tables. If the
problem is related to kernel can I ask for clarification ? I will
move the pressure to kernel and acpica bugzilla as I really want to see
it resolved.
========
Comment 15 Chen Yu 2018-03-16 04:36:04 UTC
*** Bug 198877 has been marked as a duplicate of this bug. ***
Comment 16 Zhang Rui 2018-04-02 01:11:15 UTC
Well.
For this particular issue, it is clearly an ASL bug that should be fixed in BIOS.
And we should not lower the log level of such errors, because it indeed indicates a software issue in some other cases.

Let's see if we can get the Dell contact and resolve this issue in BIOS.
Comment 17 Marcin Kurek 2018-04-03 21:27:49 UTC
It would be more than good to see this problems resolved as it still makes me mad to see tons of warnings when booting my machine (Precision 5510 which same problems) 

I lost almost half of year trying to contact&convince anyone from Dell to look at this issues and they finally stop responding to my e-mails. A funny thing is as my boss bought new XPS (9360) I looked in to ACPI tables and most of this problems are fixed/not present there (missing methods and symbols mentioned here are present)

Maybe it become handy. The case number Dell give me for this problem was: 947834433.
Comment 18 Zhang Rui 2018-05-04 01:33:56 UTC
Mario, do you know how we can get these ASL errors fixed in BIOS?
Comment 19 Mario Limonciello 2018-05-07 21:26:59 UTC
@Zhang Rui,

I'll poke around internally and see.  I do recall hearing some discussion around something similar like this on the Precision 5510 that was decided not to be fixed in that generation so that might unfortunately be the result.
Comment 20 Zhang Rui 2018-06-25 06:06:28 UTC
@Mario Limonciello 
any update? is it possible to get this fixed in new BIOS release?


@Marcin Kurek
In any case, this is not a kernel problem.
So I'd like to close this bug report no matter if it can be fixed in BIOS or not.
what do you think?
Comment 21 superm1 2018-06-25 06:06:45 UTC
Created attachment 276825 [details]
attachment-26706-0.html

?
Hello,

I will be traveling through June 27. Expect delayed response.
Comment 22 Mario Limonciello 2018-06-25 14:12:48 UTC
@Zhang Rui:

Sorry no updates to share on this one yet.

I do agree this bug should be closed as this is confirmed a BIOS issue though.

Thanks,
Comment 23 Marcin Kurek 2018-06-25 16:04:12 UTC
> @Marcin Kurek
> what do you think?

I would prefer this bug to be fixed by vendor, but to be honest I have a little hope for any reaction from them as already fight with Dell and still I have no idea why they doesn't want to fix they bug in premium laptop. I would expect this from small company, but it's hard to belive for me there is no one to work on this in vendor so big and well known as Dell.

Summarizing. I think closing this bug would make it disappear for good, but If you think it's right way I see no sense to pollute bugzilla for no good reason.

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