Bug 109511

Created attachment 197531 [details]
Output of dmesg

same story here, same messages with 16gb version

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_ */

Let me know if I can help debug anything.

(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

Will we fix it?

SB_.PCI0.LPCB.H_EC.ECAV should not be defined in any dynamic SSDT tables.
So this is a BIOS bug to me. Closed.

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)

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.

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.

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.

Created attachment 273563 [details]
[PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings

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.

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.
========

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

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.

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.

Mario, do you know how we can get these ASL errors fixed in BIOS?

@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.

@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?

Created attachment 276825 [details]
attachment-26706-0.html

?
Hello,

I will be traveling through June 27. Expect delayed response.

@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,

> @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.