On Tue, Nov 08, 2016 at 05:35:07PM +0000, Zheng, Lv wrote: > Hi, > > > From: Peter Wu [mailto:peter@xxxxxxxxxxxxx] > > Subject: ACPI module-level code (MLC) not working? > > > > Hi Lv, > > > > According to some tests, setting acpi_gbl_parse_table_as_term_list to > > TRUE does is not effective. The code within the If-block is still not > > executed early enough or something else is wrong. > > > > Previously Rick had an issue with an Acer Aspire V7-582PG where the dGPU > > could not be powered off and I demonstrated an isolated test case in > > http://www.spinics.net/lists/linux-acpi/msg70069.html > > > > In Bartosz's case, the dGPU cannot be powered on (also using nouveau), > > preventing suspend from working. Situation is as follows (tested with > > Linux 3.16, 4.8.4, 4.9-rc2, 4.9-rc4): > > > > His Lenovo IdeaPad Z510 laptop (BIOS date 2014) enables power resources > > and related _PR3 objects under the conditional If(_OSI("Windows 2013")). > > Both with and without acpi_gbl_parse_table_as_term_list set to TRUE, the > > module-level code is not loaded properly. Via a SSDT override, it was > > confirmed that removing the If conditional results in the expected > > behavior. > > > > Various details are given in https://github.com/Bumblebee-Project/bbswitch/issues/142 > > including lots of dmesg logs (see posts at the bottom). > > With above MLC flag set (v4.9-rc4): https://pastebin.com/raw/vCEPGezX > > With SSDT override (v4.9-rc2): https://pastebin.com/raw/3Fsf2VPU > > I checked the post. > It seems the current working way is: disabling _OSI(Windows 2013) which disables power resources. That is how Lenovo probably intended to use it (only add Power Resources when Windows 8 is detected). > I have several questions related to this issue: > 1. The following messages are prompt up when "acpi_gbl_parse_table_as_term_list = TRUE": > [ 2.519113] ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359) > [ 2.519121] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG1.PEGP.DD02._BCL] (Node ffff8802568d3cf8), AE_NOT_FOUND (20160831/psparse-543) > How was this triggered? This comes from acpi_video.c, ssdt4.dsl contains a \_SB.PCI0.GFX0.DD02 device with an _ADR method, but no _BCL one. It is not a regression though, let's ignore this for now. > 2. I noticed the following statement: > 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. > Could you provide the detail of the tables from the platform? > What is the reason of doing such kind of craps in BIOS? I have no idea why Lenovo would do such a silly thing, but that is why we had to patch tables.c with: if (existing_table->checksum != 0xAF) { acpi_os_unmap_memory(table, ACPI_HEADER_SIZE); pr_info("Skipping next table\n"); goto next_table; } This is of course an unacceptable hard-coded value, but it was needed in as a quick hack. For a longterm solution, maybe we can name the table files specially such that additional match conditions can be given. This is a different issue though. What would you like to know about the platform? The acpidump is available at https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4773050/+files/LENOVO-20287.tar.gz ssdt5.dsl is the file of interest, grep for "Windows 2013". Kind regards, Peter > Thanks and best regards > Lv > > > > > If you would like a new bugzilla entry or have some patches to test, you > > know where to find us :) > > -- > > Kind regards, > > Peter Wu > > https://lekensteyn.nl -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
