New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Lenovo IdeaPad Z510, GT 740M] Enabling the GPU won't work after resuming from sleep #142

Closed
Barteks2x opened this Issue Nov 2, 2016 · 58 comments

Comments

Projects
None yet
6 participants
@Barteks2x

Barteks2x commented Nov 2, 2016

I already confirmed it on 2 completely different distributions:
Debian jessie (and debian testing some time ago) and gentoo with kernel versions 3.16.0 on debian and 4.4.26 on gentoo.

After suspending, using optirun from bumblebee will freeze the whole system for a few seconds on debian (I didn't test bumblebee on gentoo), manually setting ON on both systems (echo ON > /proc/acpi/bbswitch as root) has no effect and outputs the following in dmesg:
Refused to change power state, currently in D3

The laptop is Lenovo ideapad Z510 with Nvidia GeForce 740M GPU.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 2, 2016

Got a dmesg from the event? Have you tried a newer kernel, like 4.7?

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 3, 2016

Currently I switched to nouveau, but it also seems to have the same issue - after suspend the whole system freezes (it's not just no display, even ssh stops working), unless I boot it with nomodeset (then it just doesn't freeze everything but still no display, and the same message in dmesg).

So this isn't a problem only with bbswitch.

I would like to avoid installing nvidia drivers again on gentoo unless needed, and I have debian stable so updating kernel may be problematic.

I can give full dmesg output from debian (with bumblebee). I will also try with newer kernel if I find a way to install it on debian.

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 4, 2016

I got a solution here: https://devtalk.nvidia.com/default/topic/955952/linux/struggling-with-my-geforce-gt-635m-and-the-nvidia-linux-driver-/

Ths solution is:
Add acpi_osi="!Windows 2013" to kernel command line for it to work with kernel versions >3.14.

@Barteks2x Barteks2x closed this Nov 4, 2016

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 5, 2016

Please upload your acpidump/lspci/dmidecode according to the instruction on https://bugs.launchpad.net/lpbugreporter/+bug/752542

You should normally not have to set acpi_osi. There are known issues with newer Maxwell devices, but you should not be affected by that.

@Lekensteyn Lekensteyn added the Need-Info label Nov 5, 2016

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 5, 2016

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 6, 2016

Based on that table, I can see that _PR3 support in _OSC is disabled when !"Windows 2013". Additionally there are some changes in how the USB 3 port is managed (should not be significant here...). However, the most significant change is that use of power resources are also disabled with !"Windows 2013".

Do you have a dmesg for both boots (with and without the acpi_osi parameter)?

What kernel versions have you tried? There is a known issue with 4.8 and the conditional used in your ACPI table, but that can be worked around with pcie_port_pm=off (note: only applicable/effective in Linux 4.8).

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 6, 2016

I was getting the same issues issues with kernels 3.16.0 on debian, and versions 4.4.26 and 4.8.4 on gentoo.

Without making changes to my setup (switching drivers), I can get dmesg from debian with nvidia drivers apparently I have nouveau+bumblebee there (3.16.0 kernel) and 4.8.4 kernel from gentoo with nouveau (I removed the 4.4.26 one). I will provide link to both once I get them.

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 6, 2016

I was 100% sure I have nvidia drivers on debian. I don't remember switching to nouveau...

Anyway, here are dmesg outputs:

  • Debian (3.16.0, with bumblebee+nouveau), without acpi_osi, start x, run and stop something with optirun, suspend, try to use optirun again and fail: http://pastebin.com/bvx2iN12
  • Debian (3.16.0, with bumblebee+nouveau), with acpi_osi="!Windows 2013", start x, run and stop something with optirun, suspend, run something with optirun again: http://pastebin.com/GNXZeUve
  • Gentoo (4.8.4, without bumblebee using dri3), without acpi_osi, start x, run something with DRI_PRIME=1, stop x, unload nouveau, suspend, resume, load nouveau, start x, try to run something with DRI_PRIME=1 (without unloading nouveau system would freeze, even sshd would stop responding): http://pastebin.com/ZyxRkkRW
  • Gentoo (4.8.4, without bumblebee using dri3), with acpi_osi="!Windows 2013", start x, run something with DRI_PRIME=1, suspend, resume, run something with DRI_PRIME=1: http://pastebin.com/FAd9t7pG

I will also try pcie_port_pm=off, but I don't think it will work as I had the same issues with older kernels.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 6, 2016

Ok, investigating. Also note that since your BIOS date is before 2015, you do not need pcie_port_pm=off as that is already the default for you.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 6, 2016

Ok, the power resources difference could indeed be significant here. In both versions, you have this line in the default situation:

acpi LNXPOWER:01: Turning OFF
acpi LNXPOWER:00: Turning OFF

maybe it will be fixed in 4.10 or 4.11 (depending on whether a solution is ready/tested). Are you willing to test possible patches (provided by the ACPI maintainers of Linux)?

Related links are:
https://bugs.freedesktop.org/show_bug.cgi?id=98398
http://www.spinics.net/lists/linux-acpi/msg70063.html
(thread starts at http://www.spinics.net/lists/linux-acpi/msg70022.html)

For future reference, this is the information from dmidecode.txt from #142 (comment):

system-manufacturer   : LENOVO
system-product-name   : 20287
system-version        : Lenovo IdeaPad Z510
baseboard-manufacturer: LENOVO
baseboard-product-name: VIUU4
baseboard-version     : 31900058STD
bios-vendor           : LENOVO
bios-version          : 8DCN40WW
bios-release-date     : 10/24/2014

Can you test this patch with Linux 4.8 (and no acpi_osi nor pcie_port_pm=off options, with nouveau but no bbswitch):

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index aab9d51..8628669 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2201,11 +2201,11 @@ static bool pci_bridge_d3_possible(struct pci_dev *bridge)
            return true;

        /*
-        * It should be safe to put PCIe ports from 2015 or newer
-        * to D3.
+        * It should be safe to put PCIe ports from 2014 or newer
+        * to D3 as Windows 8 started supporting this.
         */
        if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
-           year >= 2015) {
+           year >= 2014) {
            return true;
        }
        break;

EDIT: actually... given that you have a module-level If-block, you would hit the bug linked above. In that case you probably want to test this patch on top of v4.9 (currently still in -rc) which has this commit:
https://git.kernel.org/linus/de56ba95e8d6d760910711744a548b50b3a4262d

@Lekensteyn Lekensteyn removed the Need-Info label Nov 6, 2016

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 6, 2016

I tested this patch with version 4.9-rc2, no difference (at least no visible difference). But now I see some ACPI related errors in dmesg that I don't remember seeing before (that may be from wifi as firmware for it no longer loads). Here is dmesg output: http://pastebin.com/YiVrqG4T (again, after running suspend with nouveau unloaded)

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 6, 2016

If you are referring to the ACPI EC messages, these are normal and unrelated. The only new warning I see is The lid device is not compliant to SW_LID., but that is also unrelated (it was added in torvalds/linux@dfa46c5).

I hoped to see nouveau: detected PR support, will not use DSM, but due to the above "module-level code" bug it is possible that it does not work.

Can you install the iasl tools (I have tested 20160930-64) and patch your ssd5.dsl with this (_BCM fix was needed to fix a compile error, the commenting out part is the interesting change, the OemID version bump is needed for Linux):

--- ssdt5.dsl   2016-11-06 17:51:06.364158711 +0100
+++ ssdt5-hacked.asl    2016-11-06 18:01:25.563924220 +0100
@@ -18,7 +18,7 @@
  *     Compiler ID      "ACPI"
  *     Compiler Version 0x00040000 (262144)
  */
-DefinitionBlock ("", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000001)
+DefinitionBlock ("", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000002)
 {
     External (_PR_.CPU0, ProcessorObj)
     External (_PR_.CPU0._PPC, IntObj)
@@ -53,7 +53,7 @@
     External (_SB_.PCI0.GFX0.DD01._DGS, MethodObj)    // 0 Arguments
     External (_SB_.PCI0.GFX0.DD02._ADR, MethodObj)    // 0 Arguments
     External (_SB_.PCI0.GFX0.DD02._BCL, IntObj)
-    External (_SB_.PCI0.GFX0.DD02._BCM, IntObj)
+    External (_SB_.PCI0.GFX0.DD02._BCM, MethodObj)
     External (_SB_.PCI0.GFX0.DD02._BQC, IntObj)
     External (_SB_.PCI0.GFX0.DD02._DCS, MethodObj)    // 0 Arguments
     External (_SB_.PCI0.GFX0.DD02._DGS, MethodObj)    // 0 Arguments
@@ -1012,8 +1012,7 @@

             Method (_BCM, 1, NotSerialized)  // _BCM: Brightness Control Method
             {
-                Return (\_SB.PCI0.GFX0.DD02._BCM) /* External reference */
-                Arg0
+                \_SB.PCI0.GFX0.DD02._BCM (Arg0) /* External reference */
             }
         }

@@ -2327,8 +2326,7 @@
         }
     }

-    If (\_OSI ("Windows 2013"))
-    {
+    // If (\_OSI ("Windows 2013")) {
         Scope (\_SB.PCI0.PEG1)
         {
             Name (WKEN, Zero)
@@ -2488,6 +2486,6 @@
                 _STA = One
             }
         }
-    }
+    // }
 }

Then compile with iasl ssdt5-hacked.asl which should produce a ssdt5-hacked.aml file. See https://www.kernel.org/doc/Documentation/acpi/initrd_table_override.txt for the next steps. If you have difficulties with creating the AML file or initrd, let me know, then I can prepare an initrd for you.

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 6, 2016

Um... first need to figure out how to actually make my system use initrd - I don't have initrd at all (it's not there in /boot and I didn't find it in grub.cfg). So it may take me a while. Or I'm just very confused.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 6, 2016

@Barteks2x It should be sufficient to create an initrd with just that file:

mkdir -p kernel/firmware/acpi
cp ssdt5-hacked.aml kernel/firmware/acpi/
find kernel | cpio -H newc --create > acpi-initrd

then copy the initrd to some place (e.g. /boot/acpi-initrd) and modify grub.cfg as follows:

linux /boot/vmlinuz root=...
# new:
initrd /boot/acpi-initrd

I test this with QEMU, it seems to work, see the 00000002 in dmesg:

ACPI: SSDT 0x000000007FFDA000 003E43 (v01 LENOVO CB-01    00000002 INTL 20160930)
@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 6, 2016

I added that initrd file, and I saw similar message in dmesg, but it still didn't fix the issue, this is dmesg output: http://pastebin.com/LuTLQnU1

Or should I remove the previous patch first?

It's also possible that the patch got applied incorrectly, as I had slightly different version of iasl so the decompiled code wasn't exactly the same.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 6, 2016

So, for some reason Lenovo has decided to give all tables the same name. The ACPI table override functionality matches possible candidates by signature, OEM ID and OEM Revision ID which are all the same. As a result, the wrong SSDT is overridden.

As a workaround, patch the kernel (drivers/acpi/tables.c) and add this line after the Only override tables matched block:

if (existing_table->checksum != 0xAF) {
    /* Note: the next line is missing in the second dmesg below, causing a WARNING. */
    acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
    pr_info("Skipping next table\n");
    goto next_table;
}

You have previously posted dmesgs at #142 (comment) and linked a new one after a discussion in #bumblebee at Freenode. For comparison:

NOTE: dmesg does not contain nouveau: detected PR support, will not use DSM (and pr_info messages are actually shown based on the acpi printouts), so pcie_port_pm=off has no effect. TODO: figure out why port PM is not supported?

Takeaway for reporter:

  • This kernel patch and SSDT override should help you with kernels 4.8 and newer. On older kernels it probably does not work since the power resources are not used. I would expect that pcie_port_pm=off (a common workaround) will also break PM, so do not do that (mind testing this hypothesis?)

To-do for Linux ACPI developers (I will contact them later):

  • Fix module-level AML codes, it still does not work as of v4.9-rc2
  • Better handle ACPI table overriding when all identifiers are the same.

To-do for self:

  • Submit patch to lower pcie port year (also needed to fix a readeon bug).

@Lekensteyn Lekensteyn changed the title from Enabling the GPU won't work after resuming from sleep to [Lenovo IdeaPad Z510] Enabling the GPU won't work after resuming from sleep Nov 6, 2016

@Barteks2x

This comment has been minimized.

Barteks2x commented Nov 7, 2016

I tested the same SSDT override and tables.c patch with year patch on 4.8.4 kernel.

The result: it seems to work both with and without year patch, dmesg outputs:

This did not work however:

@zetalog

This comment has been minimized.

zetalog commented Nov 9, 2016

The table headers are:

DefinitionBlock ("dsdt.aml", "DSDT", 1, "LENOVO", "CB-01   ", 0x00000001)
DefinitionBlock ("ssdt1.aml", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000001)
DefinitionBlock ("ssdt2.aml", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000001)
DefinitionBlock ("ssdt3.aml", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000001)
DefinitionBlock ("ssdt4.aml", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000001)
DefinitionBlock ("ssdt5.aml", "SSDT", 1, "LENOVO", "CB-01   ", 0x00000001)

The SSDTs will be deemed as different versions of the same table from linux ACPI's point of view.
I'm actually about to change acpi_tb_compare_tables() to use the id comparison instead of the entire table comparison. And the change may affect behavior of loading these tables.

Let me ask further which behavior OSPM should take to these tables:

  1. Install only ssdt1.aml and stop installing ssdt2-5.aml because of ID matches, and load only ssdt1.aml into the namespace?
  2. Install ssdt1.aml, then override ssdt1.aml with ssdt2.aml, then override ssdt2.aml with ssdt3.aml, then override ssdt3.aml with ssdt4.aml, then override ssdt4.aml with ssdt5.aml because of ID matches, and load only ssdt5.aml into the namespace?
  3. Install ssdt1.aml,ssdt2.aml,ssdt3.aml,ssdt4.aml,ssdt5.aml and load all of them into the same namespace?

Can you confirm Windows behavior for this via amli?

@zetalog

This comment has been minimized.

zetalog commented Nov 9, 2016

if (existing_table->checksum != 0xAF) {
    /* Note: the next line is missing in the second dmesg below, causing a WARNING. */
    acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
    pr_info("Skipping next table\n");
    goto next_table;
}

Maybe we need to extend table override mechanism to allow override one of the tables by matching checksum.
Well, Lenovo guys are really crazy! How can these tables be identified then...

@zetalog

This comment has been minimized.

zetalog commented Nov 9, 2016

-    If (\_OSI ("Windows 2013")) {
+    // If (\_OSI ("Windows 2013")) {

I haven't confirmed if _OSI working in module level.
Maybe we need to move it a bit earlier in Linux before enabling MLC.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 9, 2016

Maybe we need to extend table override mechanism to allow override one of the tables by matching checksum.

See also the "TODOs" at #142 (comment) :-)
In a reply to your mail I also suggested a possible method that looks at the filename for overriding based on other attributes. (checksum and size are different between the original and override table, so you cannot use the header for comparison).

Well, Lenovo guys are really crazy!

That is already known by now, they have several deficiencies in the past with relation to hybrid graphics (and other topics like Superfish). For example, memory corruption... #78.

Based on a test with QEMU:

qemu-system-x86_64 -M pc,accel=kvm -kernel arch/x86/boot/bzImage -nographic \
    -serial file:/dev/stdout -append 'console=ttyS0 acpi.aml_debug_output=1' \
    -acpitable file=test.aml | grep Debug -iC5

it seems that _OSI is supported. With this ASL:

DefinitionBlock ("", "SSDT", 1, "TESTJE", "MYTESTJE", 0x00001000) {
    External (\_SB.PCI0.PX13, DeviceObj)

    Debug = "Module level"
    If (\_OSI ("Windows 2013")) {
        Debug = "In block"

        Scope (\_SB.PCI0.PX13) {
            Method (_S0W, 0, NotSerialized) {
                Debug = "_SOW"
                Return(3)
            }
        }
    }
}

I get this output on v4.9-rc4:

[    0.072031] ACPI: Added _OSI(Module Device)
[    0.072923] ACPI: Added _OSI(Processor Device)
[    0.073865] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.074861] ACPI: Added _OSI(Processor Aggregator Device)
[    0.076238] [ACPI Debug]  "In block"
[    0.077030] ACPI: Executed 2 blocks of module-level executable AML code
[    0.080149] ACPI: Interpreter enabled
[    0.080945] ACPI: (supports S0 S5)
[    0.081671] ACPI: Using IOAPIC for interrupt routing
[    0.082723] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.084084] [ACPI Debug]  "_SOW"
[    0.086642] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.088004] acpi PNP0A03:00: _OSC: OS supports [Segments]
[    0.089209] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM

and with acpi_gbl_parse_table_as_term_list set to TRUE:

[    0.072001] ACPI: Added _OSI(Processor Aggregator Device)
[    0.074047] [ACPI Debug]  "Module level" <------------------ NEW
[    0.074927] [ACPI Debug]  "In block"
[    0.075740] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.077996] ACPI: Interpreter enabled
[    0.079003] ACPI: (supports S0 S5)
[    0.080002] ACPI: Using IOAPIC for interrupt routing
[    0.081590] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.084142] [ACPI Debug]  "_SOW"
[    0.089026] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
@zetalog

This comment has been minimized.

zetalog commented Nov 9, 2016

Whatever the block is executed right in table loading:

[    0.074047] [ACPI Debug]  "Module level"
[    0.074927] [ACPI Debug]  "In block"

or deferred after loading table:

[    0.076238] [ACPI Debug]  "In block"

The block should have been executed:

    If (\_OSI ("Windows 2013"))
    {
        Scope (\_SB.PCI0.PEG1)
        {
            Name (WKEN, Zero)
            OperationRegion (PCNV, SystemMemory, \_SB.PCI0.PEG1.PEGP.EBAS, 0x1000)
            Field (PCNV, AnyAcc, NoLock, Preserve)
            {
                Offset (0x488), 
                    ,   25, 
                MLTF,   1
            }

            Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0
            {
                NVP3
            })
            Name (_PR2, Package (0x01)  // _PR2: Power Resources for D2
            {
                NVP2
            })
            Name (_PR3, Package (0x01)  // _PR3: Power Resources for D3hot
            {
                NVP3
            })
            Method (_S0W, 0, NotSerialized)  // _S0W: S0 Device Wake State
            {
                If (And (\_SB.OSCO, 0x04))
                {
                    Return (0x04)
                }
                Else
                {
                    Return (0x03)
                }
            }

            Method (_DSW, 3, NotSerialized)  // _DSW: Device Sleep Wake
            {
                If (Arg1)
                {
                    Store (Zero, WKEN) /* \_SB_.PCI0.PEG1.WKEN */
                }
                Else
                {
                    If (LAnd (Arg0, Arg2))
                    {
                        Store (One, WKEN) /* \_SB_.PCI0.PEG1.WKEN */
                    }
                    Else
                    {
                        Store (Zero, WKEN) /* \_SB_.PCI0.PEG1.WKEN */
                    }
                }
            }

            Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
            {
            }

            Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
            {
            }
        }

        Name (MSD3, Zero)
        PowerResource (NVP3, 0x00, 0x0000)
        {
            Name (_STA, One)  // _STA: Status
            OperationRegion (PEGB, SystemMemory, \_SB.PCI0.PEG1.PEGP.DBPA, 0x0100)
            Field (PEGB, ByteAcc, NoLock, Preserve)
            {
                Offset (0x04), 
                PCMR,   8, 
                Offset (0x84), 
                PMST,   2
            }

            OperationRegion (DGRS, SystemMemory, \_SB.PCI0.PEG1.PEGP.EBAS, 0x50)
            Field (DGRS, DWordAcc, NoLock, Preserve)
            {
                DDID,   16, 
                Offset (0x40), 
                SSSV,   32
            }

            Method (_ON, 0, NotSerialized)  // _ON_: Power On
            {
                If (LEqual (DDID, 0xFFFF))
                {
                    Store (One, _STA) /* \NVP3._STA */
                    \_SB.PCI0.PEG1.PEGP.SGPO (\_SB.PCI0.PEG1.PEGP.HLRS, One)
                    \_SB.PCI0.PEG1.PEGP.SGPO (\_SB.PCI0.PEG1.PEGP.PWEN, Zero)
                    \_SB.PCI0.PEG1.PEGP.SGPO (0x34, Zero)
                    Sleep (0x10)
                    \_SB.PCI0.PEG1.PEGP.SGPO (\_SB.PCI0.PEG1.PEGP.HLRS, Zero)
                    Sleep (0x10)
                    Store (Zero, \_SB.PCI0.PEG1.LNKD)
                    While (LLess (\_SB.PCI0.PEG1.LNKS, 0x07))
                    {
                        Store (0x20, Local0)
                        While (Local0)
                        {
                            If (LLess (\_SB.PCI0.PEG1.LNKS, 0x07))
                            {
                                Stall (0x64)
                                Decrement (Local0)
                            }
                            Else
                            {
                                Break
                            }
                        }
                    }

                    Store (0x07, PCMR) /* \NVP3.PCMR */
                    Store (Zero, PMST) /* \NVP3.PMST */
                    While (LEqual (DDID, 0xFFFF))
                    {
                        Sleep (One)
                    }

                    Store (0x380A17AA, SSSV) /* \NVP3.SSSV */
                    Store (Zero, \_SB.PCI0.PEG1.PEGP.MLTF)
                    Store (Zero, MSD3) /* \MSD3 */
                    If (\ECON)
                    {
                        Store (One, \_SB.PCI0.LPCB.EC0.GATY) /* External reference */
                    }
                }
            }

            Method (_OFF, 0, NotSerialized)  // _OFF: Power Off
            {
                If (LEqual (MSD3, Zero))
                {
                    If (\ECON)
                    {
                        Store (0x03, \_SB.PCI0.LPCB.EC0.GATY) /* External reference */
                    }

                    \_SB.PCI0.PEG1.PEGP.SGPO (\_SB.PCI0.PEG1.PEGP.HLRS, One)
                    Sleep (0x02)
                    \_SB.PCI0.PEG1.PEGP.SGPO (0x34, One)
                    \_SB.PCI0.PEG1.PEGP.SGPO (\_SB.PCI0.PEG1.PEGP.PWEN, One)
                    Store (Zero, _STA) /* \NVP3._STA */
                    Store (0x03, MSD3) /* \MSD3 */
                }
            }
        }

        PowerResource (NVP2, 0x00, 0x0000)
        {
            Name (_STA, One)  // _STA: Status
            Method (_ON, 0, NotSerialized)  // _ON_: Power On
            {
                Store (One, _STA) /* \NVP2._STA */
            }

            Method (_OFF, 0, NotSerialized)  // _OFF: Power Off
            {
                Store (One, _STA) /* \NVP2._STA */
            }
        }
    }

So why is this change needed to fix the issue:

-    If (\_OSI ("Windows 2013")) {
+    // If (\_OSI ("Windows 2013")) {
@zetalog

This comment has been minimized.

zetalog commented Nov 9, 2016

In a reply to your mail I also suggested a possible method that looks at the filename for overriding based on other attributes. (checksum and size are different between the original and override table, so you cannot use the header for comparison).

TBH, I think index of the table is not stable. For dynamic loading tables, index can be vary per OS boot.
While checksum may be stable as they are likely not identical.
We can disable table checksum validation for overridden tables and add an option in iasl to set checksum instead of calculating checksum for the compiled tables.

@zetalog

This comment has been minimized.

zetalog commented Nov 9, 2016

Fix module-level AML codes, it still does not work as of v4.9-rc2

What do you want us to fix?
We are about to enable acpi_gbl_parse_table_as_term_list = TRUE.
However, we'll do that after clarifying a Windows behavior against automatic _REG execution.

If you looked at upstream ASLTS test cases, you would find a 'table' test suites, in which TLD0.tst9 was still broken.
We need to confirm if the test is not valid or the auto _REG needs a better support.

@Lekensteyn

This comment has been minimized.

Member

Lekensteyn commented Nov 9, 2016

We can disable table checksum validation for overridden tables and add an option in iasl to set checksum instead of calculating checksum for the compiled tables.

That is such a hack, I do not think it is a good idea because it will confuse other tools due to bad checksum. I think passing the matching parameters in the filename is a better idea. So instead of kernel/firmware/acpi/ssdt.aml you could have kernel/firmware/acpi/checksum=0xff,ssdt.aml and/or (for matching multiple attributes) kernel/firmware/acpi/checksum=0xff,size=1234,ssdt.aml.

What do you want us to fix?

I thought that MLC was related to this problem, but maybe there is another bug in how power resources are evaluated. See the tests below.

So why is this change needed to fix the issue:

-    If (\_OSI ("Windows 2013")) {
+    // If (\_OSI ("Windows 2013")) {

I do not know why it matters. I just ran some tests and using the QEMU command line and ASL from http://www.spinics.net/lists/linux-acpi/msg70069.html and using acpidbg -b Methods I verified that the methods inside the block are created:

# /tmp/acpidbg -b 'Methods' | grep NVP
                       \NVP3._ON Method       ffff880006325540 02 Args 0 Len 0014 Aml ffffc90000005133
                      \NVP3._OFF Method       ffff880006325578 02 Args 0 Len 0015 Aml ffffc9000000514e
                       \NVP2._ON Method       ffff880006325620 02 Args 0 Len 0014 Aml ffffc9000000517b
                      \NVP2._OFF Method       ffff880006325658 02 Args 0 Len 0015 Aml ffffc90000005196

but the power resource method itself is not visible in most cases:

# grep S90 /sys/bus/pci/devices/*/firmware_node/path
/sys/bus/pci/devices/0000:00:12.0/firmware_node/path:\_SB_.PCI0.S90_
# ls -d /sys/bus/pci/devices/*/firmware_node/power_resources*
ls: cannot access '/sys/bus/pci/devices/*/firmware_node/power_resources*': No such file or directory

only in one case (no If, term_list setting is false) I see the desired result:

/sys/bus/pci/devices/0000:00:12.0/firmware_node/power_resources_D0
/sys/bus/pci/devices/0000:00:12.0/firmware_node/power_resources_D2
/sys/bus/pci/devices/0000:00:12.0/firmware_node/power_resources_D3hot

Tested scenarios with v4.9-rc4:

ASL acpi_gbl_parse_table_as_term_list Result
If(\_OSI("Windows 2013")) TRUE fail
If(1) TRUE fail
no If TRUE fail
If(\_OSI("Windows 2013")) FALSE fail
If(1) FALSE fail
no If FALSE pass

Very strange results, any idea why this would happen? I did not expect that term_list=TRUE would break the normal case where no If exists.

You said you do not have QEMU, what environment (OS/distro/hardware) are you using? QEMU is really useful for reproducing such tests with Linux.

zetalog added a commit to zetalog/acpica that referenced this issue May 2, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus funcional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 3, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 4, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 22, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 22, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 22, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 22, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 22, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue May 22, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue Jun 14, 2017

Parser: Avoid resolving in-package references
This patch changes PackageElement parsing according to the validated
Windows behavior. It seems Windows always converts NameString in Package
into String, so that when an OSPM driver call invokes it later, forward
references can be allowed.

Note, OSPMs like Linux having drivers invoking ACPICA APIs should still
rely on the old ACPICA behaviors where NameString is resolved into
ObjectReference for the external users. While this commit doesn't ensure
such compatibility, thus functional changes in this commit is not directly
enabled but is surrounded by AcpiGbl_ParseTableAsTermList so that after
having done all necessary changes, it can be enabled along with the new MLC
enabling. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue Jun 14, 2017

Namespace: Add support to convert "Zero" into NULL object reference
Some configurable BIOS code sets NameString to Zero to indicate a NULL
object reference, this patch implements this to automatically convert this
for the external users. This patch also converts String -> Reference
repiar into a generic mechanism. Reported by Peter Wu, Fixed by Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Bartosz Skrzypczak <Barteks2x@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

zetalog added a commit to zetalog/acpica that referenced this issue Jun 14, 2017

Utility: Add support to resolve external object references
This patch adds support to resolve internal NameString objects into
external ObjectReference so that when ACPICA is tuned to be compliant to
the other ACPI implementations, external users (OSPM drivers) won't be
affected. Reported by Peter Wu, fixed by Robert Moore, Lv Zheng.

Link: https://bugs.acpica.org/show_bug.cgi?id=1333
Link: Bumblebee-Project/bbswitch#142
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment