Closed Barteks2x closed 8 years ago
FFFFE0011C8C4800 120000 ACPIBuildDevicePowerNodes: INT1 references bad power object. FFFFE00050CC48D0 120000 ACPIBuildDevicePowerNodes: HAHA DIS DOES NUT WUKK Status = c0000034
It looks DataReference in Package will be treated as "String" by the AML interpreter. And gets evaluated in specific OSPM user functions. Linux should add a similar function as ACPIBuildDevicePowerNodes() to convert strings into references.
Perhaps you need to validate the amli result of the following code (which is from spec, 19.6.99 Package (Declare Package Object)):
Name (INT1, 0x1234)
Processor (CPU0, 0, 0x1010, 6) {}
PowerResource (PWR1, 0, 0) {}
Name (PKG1, Package () {
0x3400, // Integer Constant, resolved at compile time
"Processor" // String Constant, resolved at compile time
\INT1 // Integer Reference, resolved to value at runtime
\CPU0 // Object Reference, returned as a reference object
Package () { // Package Constant. Elements are resolved at both compile time and runtime
0x4321, // Integer Constant, resolved at compile time
\INT1, // Integer Reference, resolved to value at runtime
\PWR1
}
})
Store (PKG1, Debug)
ACPI spec expects:
Package [Contains 0x05 Elements]
(00) Integer 0x0000000000003400
(01) String [0x09] "Processor"
(02) Integer 0x0000000000001234
(03) Reference [Named Object] [CPU0] Processor
(04) Package [Contains 0x03 Elements]
(00) Integer 0x0000000000004321
(01) Integer 0x0000000000001234
(02) Reference [Named Object] [PWR1] Power
We need Windows result here... And we need the result when the above code is the module level, and the result when the above code is in a control method.
If all DataReference in Package should be "String". Then at least, following predefined control methods will be affected. If we support the same behavior as Windows, all such method users should be validated in Linux...
_DEP
_DLM
_PRT
_EDL
_PRx
_PRE
_PRW
_PRR
_RDI
_PCL
_PRL
_PMD
_ALx
_ART
_PSL
_TRT
_TZD
_DOD
...
This is quite a big problem...
Perhaps you need to validate the amli result of the following code (which is from spec, 19.6.99 Package (Declare Package Object)):
That is what I did above in https://github.com/Bumblebee-Project/bbswitch/issues/142#issuecomment-260091103. Note that I had to use a different Processor object and a more populated PowerResource object or else a BSOD (ACPI_BIOS_ERROR) would occur. All references show up as String type.
Also note that the ACPI spec (6.1) has a syntax error, the last })
is missing in the Package example. Can you raise this issue to the UEFI Forum?
_TMP
This is quite a big problem...
I just took a look at an earlier AMLi trace for a real machine and did not see a _TMP
method returning a package with named references, just integers. The ACPI spec does not suggest named refs here either. Can you check?
I just took a look at an earlier AMLi trace for a real machine and did not see a _TMP method returning a package with named references, just integers. The ACPI spec does not suggest named refs here either. Can you check?
I messed this up because of the following line.
Method(_TMP) { Return (\_SB.PCI0.ISA0.EC0.TMP )}
Method(_PSV) { Return (\_SB.PCI0.ISA0.EC0.PSV) }
So let me remove _TMP as long as _PSV.
Also note that the ACPI spec (6.1) has a syntax error, the last }) is missing in the Package example. Can you raise this issue to the UEFI Forum?
Sure.
That is what I did above in #142 (comment). Note that I had to use a different Processor object and a more populated PowerResource object or else a BSOD (ACPI_BIOS_ERROR) would occur. All references show up as String type.
In your test, whatever a reference is to a DataObject or a non-DataObject, String seems to be always the result:
Package(:NumElements=5){
| Integer(:Value=0x3400[13312])
,| String(:Str="Processor")
,| String(:Str="\INT1") <- DataObject
,| String(:Str="\_SB_.CPUS.C000") <- Non DataObject
,| Package(:NumElements=3){
| | Integer(:Value=0x4321[17185])
,| | String(:Str="\INT1") <- DataObject
,| | String(:Str="PWR1") <- Non DataObject
,| }
,}
This can make people starting to doubt the correctness of ACPI spec 6.1 - 19.6.99 Package (Declare Package Object)...
is there any update on this issue ?
As you can see, Zeta is working hard on acpica/acpica#189 If it gets merged soon, I think you could reasonably expect it by kernel 4.13.
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.