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