On Sat, Oct 29, 2016 at 12:42:34AM +0000, Zheng, Lv wrote: > Hi, Mika > > > From: Mika Westerberg [mailto:mika.westerberg@xxxxxxxxxxxxxxx] > > Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources > > > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > > > > No, there are not. Here is the recursive directory listing: > > > > > > > > Are you able to try the following patch and send me dmesg (or attach it > > > > to that bug)? It should show if the ACPI core even tries to add those > > > > power resources. > > > > > > So Rick has tested this patch now on top of 4.8.4 (mainline fails to > > > boot due to a kbuild issue which I reported elsewhere), but the output > > > is empty. That seems to indicate that flags.power_resources is unset. > > > > Is it completely empty or is it empty just for RP05? It should print out > > all devices with power resources. > > > > > Given that _PS3 exists and is indeed a package with some elements, it > > > seems that acpi_extract_power_resources is failing. Note that in the > > > SSDT, the power resource NVP3 was referenced before it was defined, > > > could that result in this enumeration failure? Relevant SSDT excerpt: > > > > > > Scope (\_SB.PCI0.RP05) > > > { > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > > { > > > NVP3 > > > }) > > > // ... > > > } > > > > > > PowerResource (NVP3, 0x00, 0x0000) > > Looks wrong order to me. > > However, _PR3 is a package, for AML opcode that contains PkgLength grammar primitive, forward reference may be OK (for example Method). > DefPackage := PackageOp PkgLength NumElements PackageElementList > DefMethod := MethodOp PkgLength NameString MethodFlags TermList > As when it is encountered, AML interpreter may only saves entire packaged object. > > I need to test behaviors around Package with qemu but I don't have environment now. > Can you help to give it a try? > By adding customize an ssdt with the above code putting under root scope, > DefinitionBlock ("ssdt-package.aml", "SSDT", 2, "INTEL ", "PACKAGE ", 0x00003000) > { > Scope (\) > { > Name (_PR3, Package (0x01) { NVP3 }) > } > PowerResource (NVP3, 0x00, 0x0000) {} > } > Running Windows images on qemu with this ssdt appended "-acpitable file=ssdt-package.aml". > To see if blue screen can be resulted. > > Thanks > Lv Testing this code with Windows 10 gives a BSOD, changing the order of the PowerResource and Scope does not make a difference. If I take my previous SSDT and change the ordering of NVP3 definition vs _PR3 use, there is no change. Kind regards, Peter > > > > That and the fact that they come from an SSDT instead of DSDT may cause > > this. However, I'm not expert in ACPICA so adding Bob and Lv if they > > have ideas. > > > > Bob, Lv, the bug in question is: https://bugs.freedesktop.org/show_bug.cgi?id=98398 -- 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
