lufeig Posted June 24, 2014 Share Posted June 24, 2014 I would call it at the end of _INI. If still not working, post ioreg (use IORegistryExplorer v2.1). i called it at the end of the _INI, but no success. please find attached my ioreg. thank you very much! Link to comment Share on other sites More sharing options...
Demonbane Posted June 24, 2014 Share Posted June 24, 2014 Yes, this is a fix for restart/sleep problems. Do this part only if necessary. Based on what we found with the HP ProBook. Your machine/DSDT may vary. And I would suggest calling _ON from the beginning of _PTS, and _OFF from the end of _WAK. Of course, this assumes your _WAK/_PTS are executing from beginning to end, which everyone should verify by using ACPIDebug.kext. cool. and in which position should the _OFF() method be injected into the _INI()? at the END would be better i assume. and one more question, is it same to insert the _OFF method into \_SB.PCI0._INI or into \_SB.PCI0.RP0*.PEGP._INI ()? which is better Link to comment Share on other sites More sharing options...
RehabMan Posted June 24, 2014 Share Posted June 24, 2014 i called it at the end of the _INI, but no success. please find attached my ioreg. thank you very much! Couple of problems that I see from ioreg: #1) SSDT2 and SSDT3 both have an _SB.PCI0.IGPU._DSM defined. This is an error and causes one of the two SSDTs to be thrown away. #2) _SB.PCI0.PEG0.PEGP looks to be renamed to _SB.PCI0.PEG0.GFX0, but only in SSDT2 not SSDT3. If a rename is done in one file, it must be done in all -- it is like keeping two sides of an equation balanced. To keep track of #1, I like to remove all _DSM methods from all files before starting to patch. The OEM _DSM methods are not useful for OSX, so no reason to keep them. This patch accomplishes that: into_all method label _DSM remove_entry; For #2, always check other files when you rename an identifier in one place (eg. in your case PEGP -> GFX0). As a sanity check, you should always verify you can disassemble all the files you have in ACPI/patched with 'iasl -da *.aml'. If iasl gives you an error, chances are OS X will have issues loading your concoction as well. Note: ioreg ssdts correspond to the load order, not the file names you chose to use. cool. and in which position should the _OFF() method be injected into the _INI()? at the END would be better i assume. and one more question, is it same to insert the _OFF method into \_SB.PCI0._INI or into \_SB.PCI0.RP0*.PEGP._INI ()? which is better I like to put it at the end... (the idea: do my extra stuff after normal initialization, just in case the _OFF method depends on it). Both _SB.PCI0._INI and _SB.PCI0.PEG0.PEGP._INI (for example) work. But usually _SB.PCI0._INI is in DSDT and _OFF is in an SSDT so an External declaration would be necessary, whereas if you put it directly into _SB.PCI0.PEG0.PEGP._INI you need no External and you don't need to explicitly use the full path. BTW, there is another (rare) consideration. When _OFF accesses EC fields, you must wait until _REG (at EC device) is called with Arg0==3 and Arg1==1 which indicates the EC driver is ready. Otherwise the _OFF method may fail. Since _REG is usually in DSDT, it requires an External and explicit path. In addition, you must insert it in the logic correctly so it executes only when the Arg0/Arg1 conditions are met. Link to comment Share on other sites More sharing options...
lufeig Posted June 24, 2014 Share Posted June 24, 2014 dear rehabman, thanks to your kindness and prompt support, my nvidia card is now disabled, and now i have a better power efficient laptop hackintosh from now on, i'll try to follow your advices to the letter if anyone wants to take my files as examples, please find them attached. they belong to the following laptop setup: HP Envy 17t-J100 1080p, i7 4702mq 2.2GHz, 16Go RAM, Nvidia GT 740 2Go, Intel HD 4600, 120Go SSD Windows 8.1, 120Go SSD OS X 10.9.3, Broadcom BCM94352 HMB, IDT 92HD91BXX Audio file description: DSDT.aml => various patches SSDT.aml => ssdtPRGen.sh generated SSDT-0.aml => BCM94352 HMB WiFi dualband enabler SSDT-14.aml => Brightness fix SSDT-15.aml => Nvidia disabler lufeig patched dsdt ssdt.zip Link to comment Share on other sites More sharing options...
Demonbane Posted June 24, 2014 Share Posted June 24, 2014 Couple of problems that I see from ioreg: #1) SSDT2 and SSDT3 both have an _SB.PCI0.IGPU._DSM defined. This is an error and causes one of the two SSDTs to be thrown away. #2) _SB.PCI0.PEG0.PEGP looks to be renamed to _SB.PCI0.PEG0.GFX0, but only in SSDT2 not SSDT3. If a rename is done in one file, it must be done in all -- it is like keeping two sides of an equation balanced. To keep track of #1, I like to remove all _DSM methods from all files before starting to patch. The OEM _DSM methods are not useful for OSX, so no reason to keep them. This patch accomplishes that: into_all method label _DSM remove_entry; For #2, always check other files when you rename an identifier in one place (eg. in your case PEGP -> GFX0). As a sanity check, you should always verify you can disassemble all the files you have in ACPI/patched with 'iasl -da *.aml'. If iasl gives you an error, chances are OS X will have issues loading your concoction as well. Note: ioreg ssdts correspond to the load order, not the file names you chose to use. I like to put it at the end... (the idea: do my extra stuff after normal initialization, just in case the _OFF method depends on it). Both _SB.PCI0._INI and _SB.PCI0.PEG0.PEGP._INI (for example) work. But usually _SB.PCI0._INI is in DSDT and _OFF is in an SSDT so an External declaration would be necessary, whereas if you put it directly into _SB.PCI0.PEG0.PEGP._INI you need no External and you don't need to explicitly use the full path. BTW, there is another (rare) consideration. When _OFF accesses EC fields, you must wait until _REG (at EC device) is called with Arg0==3 and Arg1==1 which indicates the EC driver is ready. Otherwise the _OFF method may fail. Since _REG is usually in DSDT, it requires an External and explicit path. In addition, you must insert it in the logic correctly so it executes only when the Arg0/Arg1 conditions are met. hi Rehabman, when i integrate my SSDT (all graphic parts) into my DSDT, and call the _OFF method. it works. the graphic card is shutdown successfully. but if i don't do the integration, but only call the _OFF with a external method in separate DSDT/SSDTs, then it wouldn't work... what's that reason probably? could you have a look at my DSDT/SSDTs Modified.zip the _OFF method is in SSDT-1, and i called _OFF in DSDT in _SB.PCI0._INI have i done something wrong? --------------------------------------------- and i found, the DSDT.aml which is compiled from integrated DSDT.dsl(with all SSDTs intergrated), has no errors. but the SSDTs.aml compiled from separated SSDT.dsl(0 error), exists many errors... so it's probably the reason, that the SSDT with to many errors is thrown away? Link to comment Share on other sites More sharing options...
RehabMan Posted June 24, 2014 Share Posted June 24, 2014 hi Rehabman, when i integrate my SSDT (all graphic parts) into my DSDT, and call the _OFF method. it works. the graphic card is shutdown successfully. but if i don't do the integration, but only call the _OFF with a external method in separate DSDT/SSDTs, then it wouldn't work... what's that reason probably? could you have a look at my DSDT/SSDTs Modified.zip the _OFF method is in SSDT-1, and i called _OFF in DSDT in _SB.PCI0._INI have i done something wrong? --------------------------------------------- and i found, the DSDT.aml which is compiled from integrated DSDT.dsl(with all SSDTs intergrated), has no errors. but the SSDTs.aml compiled from separated SSDT.dsl(0 error), exists many errors... so it's probably the reason, that the SSDT with to many errors is thrown away? Read post #156 carefully. Your files have many OEM _DSM methods which may conflict with your own (I didn't check). And SSDT-3.dsl has a GFX0->IGPU rename that was not done on the other files (DSDT/SSDT-2). Also, the call to _OFF from _WAK is unreachable. Execution of a method stops at the end or when Return is encountered: Method (_WAK, 1, Serialized) // _WAK: Wake { ... Return (Package (0x02) { Zero, Zero }) \_SB.PCI0.RP05.PEGP._OFF () } Link to comment Share on other sites More sharing options...
Demonbane Posted June 24, 2014 Share Posted June 24, 2014 Read post #156 carefully. Your files have many OEM _DSM methods which may conflict with your own (I didn't check). And SSDT-3.dsl has a GFX0->IGPU rename that was not done on the other files (DSDT/SSDT-2). Also, the call to _OFF from _WAK is unreachable. Execution of a method stops at the end or when Return is encountered: Method (_WAK, 1, Serialized) // _WAK: Wake { ... Return (Package (0x02) { Zero, Zero }) \_SB.PCI0.RP05.PEGP._OFF () } removing _DSM doesn't work for me. thx for your remind of return, i haven't noticed that but finally i found that it was caused by the order how the SSDTs were loaded. as you see, SSDT-1 is the part of Geforce Graphic card, and SSDT-3 is the part of Intel integrated graphic card. that is the original default order when i extract from ACPI... but when i change the SSDT-1 to SSDT-4, then it works! i think the SSDT-1(Geforce Graphic) must have some reference from SSDT-3(Intel Graphic) and depend on it! and the vendor of my laptop may made a mistake... PS: i found that because when i integrated all the SSDTs into DSDT, the SSDT-3(Intel Graphic) codes must be above the SSDT-1(Geforce Graphic) codes, otherwise it will cause many many errors in DSDT... Link to comment Share on other sites More sharing options...
RehabMan Posted June 24, 2014 Share Posted June 24, 2014 removing _DSM doesn't work for me. thx for your remind of return, i haven't noticed that but finally i found that it was caused by the order how the SSDTs were loaded. as you see, SSDT-1 is the part of Geforce Graphic card, and SSDT-3 is the part of Intel integrated graphic card. that is the original default order when i extract from ACPI... but when i change the SSDT-1 to SSDT-4, then it works! i think the SSDT-1(Geforce Graphic) must have some reference from SSDT-3(Intel Graphic) and depend on it! and the vendor of my laptop may made a mistake... PS: i found that because when i integrated all the SSDTs into DSDT, the SSDT-3(Intel Graphic) codes must be above the SSDT-1(Geforce Graphic) codes, otherwise it will cause many many errors in DSDT... The order affects which SSDT is ignored when there are conflicts. Better to resolve the conflicts so order does not matter. You should not be merging any SSDTs. Link to comment Share on other sites More sharing options...
Demonbane Posted June 24, 2014 Share Posted June 24, 2014 The order affects which SSDT is ignored when there are conflicts. Better to resolve the conflicts so order does not matter. You should not be merging any SSDTs. i also don't want to merge them, it's really annoying , and editing the SSDTs separately is much more briefly and neatly! but i still don't know how to resolve the conflicts... because my SSDTs.dsl seem really okay without any errors. but when they are compiled into .aml, then the errors appear...especially the part of Geforce graphic Link to comment Share on other sites More sharing options...
RehabMan Posted June 24, 2014 Share Posted June 24, 2014 i also don't want to merge them, it's really annoying , and editing the SSDTs separately is much more briefly and neatly! but i still don't know how to resolve the conflicts... because my SSDTs.dsl seem really okay without any errors. but when they are compiled into .aml, then the errors appear...especially the part of Geforce graphic By definition, there are no errors if you created an AML successfully. Any errors that appear when you open the AMLs are a result of incorrect disassembly. Remember when you had to disassemble with iasl -da? That requirement does not change after patching. I think the problem is your files are incorrectly/incompletely patched. I've mentioned two of the issues I found (incomplete rename to GFX0, and presence of OEM _DSM methods). I suggest you resolve those two issues and try again. You can always post ioreg if you want further comments from me. Don't expect that resolving only one of the issues will make a difference. Link to comment Share on other sites More sharing options...
Demonbane Posted June 24, 2014 Share Posted June 24, 2014 i have followed all you said. (rename GFX0 and remove _DSM in DSDT-1) and i also used "./iasl -da *.aml" to dissemble the DSDT/SSDTs but SSDTs still should be ordered so that the graphic can be shutdown successfully. that's my new modified files: Archive.zip (ioreg included) as i said, the .aml file still have many errors after the compiling. PS: the IOREG is extracted as now i reorder the SSDTs. Thx for your continued help! Link to comment Share on other sites More sharing options...
pokenguyen Posted June 24, 2014 Share Posted June 24, 2014 i have followed all you said. (rename GFX0 and remove _DSM in DSDT-1) but SSDTs still should be ordered so that the graphic can be shutdown successfully. that's my new modified files: Archive.zip (ioreg included) as i said, the .aml file still have many errors after the compiling. PS: the IOREG is extracted as now i reorder the SSDTs. Thx for your continued help! Always remember this: By definition, there are no errors if you created an AML successfully. Any errors that appear when you open the AMLs are a result of incorrect disassembly. Remember when you had to disassemble with iasl -da? That requirement does not change after patching. The thing you see with errors is a decompiled version of AML you opened, not the AML itself. AML content is machine language binary code, and you can't edit it. When you open .aml file by MacIASL, MacIASl will auto decompile the AML file, and this DECOMPILING process produces errors. Link to comment Share on other sites More sharing options...
RehabMan Posted June 24, 2014 Share Posted June 24, 2014 i have followed all you said. (rename GFX0 and remove _DSM in DSDT-1) and i also used "./iasl -da *.aml" to dissemble the DSDT/SSDTs but SSDTs still should be ordered so that the graphic can be shutdown successfully. that's my new modified files: Archive.zip (ioreg included) as i said, the .aml file still have many errors after the compiling. PS: the IOREG is extracted as now i reorder the SSDTs. Thx for your continued help! It will be some time before I can look at your files... No time right now. Link to comment Share on other sites More sharing options...
Demonbane Posted June 24, 2014 Share Posted June 24, 2014 Always remember this: The thing you see with errors is a decompiled version of AML you opened, not the AML itself. AML content is machine language binary code, and you can't edit it. When you open .aml file by MacIASL, MacIASl will auto decompile the AML file, and this DECOMPILING process produces errors. yeah i got it, so the errors we see are not the errors actually, it's only caused by decompiling right? but as Rehabman said, the order of SSDTs doesn't matter if the SSDTs are correct. now i got the correct SSDTs.asl (at least seem to be correct), my the order of my SSDTs matters indeed. the geforce graphic part of SSDT should be loaded after the Intel graphic part... It will be some time before I can look at your files... No time right now. no problem. at least it works now problem-free. i just want to figure out what's the problem with my SSDTs... Link to comment Share on other sites More sharing options...
RehabMan Posted June 24, 2014 Share Posted June 24, 2014 @demonbane, SSDT-2.dsl has not had GFX0->IGPU rename. Also notice the same thing about your DSDT as loaded in ioreg. Also the rename you're attempting can be tricky and I may be getting confused (because I think you're also renaming PEGP->GFX0?). Since your focus is on disabling nvidia, I would leave the name PEGP. You might want to cleanup the _DSM methods prior to patching. And you might need to call from _REG instead as your _OFF method accesses EC registers and so you should be certain the EC is ready. Note: I will also do some tests to see if I can find any order dependencies by testing with small examples. I haven't seen any, but then again, I tend to keep everything in the original order. Link to comment Share on other sites More sharing options...
RehabMan Posted June 25, 2014 Share Posted June 25, 2014 Note: I will also do some tests to see if I can find any order dependencies by testing with small examples. I haven't seen any, but then again, I tend to keep everything in the original order. OK, check this out. I did a simple test to see whether an order dependency was possible. One thing I thought might be order dependent is inserting a method into a scope defined in an SSDT loaded later. So, I created two SSDTs... SSDT-10.aml: DefinitionBlock ("SSDT-10.aml", "SSDT", 1, "RM", "T1", 0x00013400) { Scope (_SB) { Device (TEST) { } } } And SSDT-11.aml: DefinitionBlock ("iASL2bgx4o.aml", "SSDT", 1, "RM", "T2", 0x00013400) { External (_SB_.TEST, DeviceObj) Scope (_SB.TEST) { Method (_INI, 0, NotSerialized) // _INI: Initialize { \RMDT.P1 ("_SB.TEST._INI entry") \RMDT.P1 ("_sB.TEST._INI exit") } } Device (RMDT) { Name (_HID, "RMD0000") // _HID: Hardware ID Name (RING, Package (0x0100) {}) Mutex (RTMX, 0x00) Name (HEAD, Zero) Name (TAIL, Zero) Method (PUSH, 1, NotSerialized) { Acquire (RTMX, 0xFFFF) Add (HEAD, One, Local0) If (LGreaterEqual (Local0, SizeOf (RING))) { Store (Zero, Local0) } If (LNotEqual (Local0, TAIL)) { Store (Arg0, Index (RING, HEAD)) Store (Local0, HEAD) /* \RMDT.HEAD */ } Release (RTMX) Notify (RMDT, 0x80) // Status Change } Method (FTCH, 0, NotSerialized) { Acquire (RTMX, 0xFFFF) Store (Zero, Local0) If (LNotEqual (HEAD, TAIL)) { Store (DerefOf (Index (RING, TAIL)), Local0) Increment (TAIL) If (LGreaterEqual (TAIL, SizeOf (RING))) { Store (Zero, TAIL) /* \RMDT.TAIL */ } } Release (RTMX) Return (Local0) } Method (COUN, 0, NotSerialized) { Acquire (RTMX, 0xFFFF) Subtract (HEAD, TAIL, Local0) If (LLess (Local0, Zero)) { Add (Local0, SizeOf (RING), Local0) } Release (RTMX) Return (Local0) } Method (P1, 1, NotSerialized) { PUSH (Arg0) } Method (P2, 2, Serialized) { Name (TEMP, Package (0x02) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) PUSH (TEMP) } Method (P3, 3, Serialized) { Name (TEMP, Package (0x03) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) PUSH (TEMP) } Method (P4, 4, Serialized) { Name (TEMP, Package (0x04) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) PUSH (TEMP) } Method (P5, 5, Serialized) { Name (TEMP, Package (0x05) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) Store (Arg4, Index (TEMP, 0x04)) PUSH (TEMP) } Method (P6, 6, Serialized) { Name (TEMP, Package (0x06) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) Store (Arg4, Index (TEMP, 0x04)) Store (Arg5, Index (TEMP, 0x05)) PUSH (TEMP) } Method (P7, 7, Serialized) { Name (TEMP, Package (0x07) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) Store (Arg4, Index (TEMP, 0x04)) Store (Arg5, Index (TEMP, 0x05)) Store (Arg6, Index (TEMP, 0x06)) PUSH (TEMP) } } } Note that SSDT-11 is really pretty simple... Just an _INI method injected into _SB.TEST with the ACPIDebug patch applied, and a few debug messages to verify the _INI method runs. I then copied SSDT-10.aml and SSDT-11.aml to ACPI/patched and rebooted. As expected, ACPIDebug.kext loaded and _INI was executed causing ACPIDebug to output the expected messages. But when I reversed the two SSDTs by renaming SSDT-10.aml->SSDT-11.aml SSDT-11.aml->SSDT-10.aml, ACPIDebug no longer loaded and the messages were not present from TEST._INI because it didn't load/execute. So... new gotcha/rule. Any insertions into a scope/device must insert into an already existing scope/device defined in SSDTs that were loaded previously. In other words, the original order of SSDTs should be maintained. Nice find ... and thanks for convincing me to verify it. Link to comment Share on other sites More sharing options...
Demonbane Posted June 25, 2014 Share Posted June 25, 2014 OK, check this out. I did a simple test to see whether an order dependency was possible. One thing I thought might be order dependent is inserting a method into a scope defined in an SSDT loaded later. So, I created two SSDTs... SSDT-10.aml: DefinitionBlock ("SSDT-10.aml", "SSDT", 1, "RM", "T1", 0x00013400) { Scope (_SB) { Device (TEST) { } } } And SSDT-11.aml: DefinitionBlock ("iASL2bgx4o.aml", "SSDT", 1, "RM", "T2", 0x00013400) { External (_SB_.TEST, DeviceObj) Scope (_SB.TEST) { Method (_INI, 0, NotSerialized) // _INI: Initialize { \RMDT.P1 ("_SB.TEST._INI entry") \RMDT.P1 ("_sB.TEST._INI exit") } } Device (RMDT) { Name (_HID, "RMD0000") // _HID: Hardware ID Name (RING, Package (0x0100) {}) Mutex (RTMX, 0x00) Name (HEAD, Zero) Name (TAIL, Zero) Method (PUSH, 1, NotSerialized) { Acquire (RTMX, 0xFFFF) Add (HEAD, One, Local0) If (LGreaterEqual (Local0, SizeOf (RING))) { Store (Zero, Local0) } If (LNotEqual (Local0, TAIL)) { Store (Arg0, Index (RING, HEAD)) Store (Local0, HEAD) /* \RMDT.HEAD */ } Release (RTMX) Notify (RMDT, 0x80) // Status Change } Method (FTCH, 0, NotSerialized) { Acquire (RTMX, 0xFFFF) Store (Zero, Local0) If (LNotEqual (HEAD, TAIL)) { Store (DerefOf (Index (RING, TAIL)), Local0) Increment (TAIL) If (LGreaterEqual (TAIL, SizeOf (RING))) { Store (Zero, TAIL) /* \RMDT.TAIL */ } } Release (RTMX) Return (Local0) } Method (COUN, 0, NotSerialized) { Acquire (RTMX, 0xFFFF) Subtract (HEAD, TAIL, Local0) If (LLess (Local0, Zero)) { Add (Local0, SizeOf (RING), Local0) } Release (RTMX) Return (Local0) } Method (P1, 1, NotSerialized) { PUSH (Arg0) } Method (P2, 2, Serialized) { Name (TEMP, Package (0x02) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) PUSH (TEMP) } Method (P3, 3, Serialized) { Name (TEMP, Package (0x03) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) PUSH (TEMP) } Method (P4, 4, Serialized) { Name (TEMP, Package (0x04) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) PUSH (TEMP) } Method (P5, 5, Serialized) { Name (TEMP, Package (0x05) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) Store (Arg4, Index (TEMP, 0x04)) PUSH (TEMP) } Method (P6, 6, Serialized) { Name (TEMP, Package (0x06) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) Store (Arg4, Index (TEMP, 0x04)) Store (Arg5, Index (TEMP, 0x05)) PUSH (TEMP) } Method (P7, 7, Serialized) { Name (TEMP, Package (0x07) {}) Store (Arg0, Index (TEMP, Zero)) Store (Arg1, Index (TEMP, One)) Store (Arg2, Index (TEMP, 0x02)) Store (Arg3, Index (TEMP, 0x03)) Store (Arg4, Index (TEMP, 0x04)) Store (Arg5, Index (TEMP, 0x05)) Store (Arg6, Index (TEMP, 0x06)) PUSH (TEMP) } } } Note that SSDT-11 is really pretty simple... Just an _INI method injected into _SB.TEST with the ACPIDebug patch applied, and a few debug messages to verify the _INI method runs. I then copied SSDT-10.aml and SSDT-11.aml to ACPI/patched and rebooted. As expected, ACPIDebug.kext loaded and _INI was executed causing ACPIDebug to output the expected messages. But when I reversed the two SSDTs by renaming SSDT-10.aml->SSDT-11.aml SSDT-11.aml->SSDT-10.aml, ACPIDebug no longer loaded and the messages were not present from TEST._INI because it didn't load/execute. So... new gotcha/rule. Any insertions into a scope/device must insert into an already existing scope/device defined in SSDTs that were loaded previously. In other words, the original order of SSDTs should be maintained. Nice find ... and thanks for convincing me to verify it. hell yeah! i saw that with ACPIDebug it's really convictive! and i have done all you said but yeah, it's obviously due to the order actually... so my problem might be the fault by the bios vendor? they might make SSDTs tables in a wrong order... Link to comment Share on other sites More sharing options...
RehabMan Posted June 25, 2014 Share Posted June 25, 2014 hell yeah! i saw that with ACPIDebug it's really convictive! and i have done all you said but yeah, it's obviously due to the order actually... so my problem might be the fault by the bios vendor? they might make SSDTs tables in a wrong order... It is possible that OS X implementation of ACPI is order dependent and Windows isn't. Or it is possible you have other issues with your setup. I created the simple example just to demonstrate/verify the order dependency. Link to comment Share on other sites More sharing options...
Ahmed_shiko Posted June 25, 2014 Share Posted June 25, 2014 please iam add patch disable nvidia card error Link to comment Share on other sites More sharing options...
RehabMan Posted June 25, 2014 Share Posted June 25, 2014 The path to _OFF varies between different computers. You must use the correct path. Link to comment Share on other sites More sharing options...
Whit3Spirit Posted June 25, 2014 Author Share Posted June 25, 2014 please iam add patch disable nvidia card error Look the first post, this is explained. Link to comment Share on other sites More sharing options...
RehabMan Posted June 26, 2014 Share Posted June 26, 2014 ... but as Rehabman said, the order of SSDTs doesn't matter if the SSDTs are correct. now i got the correct SSDTs.asl (at least seem to be correct), my the order of my SSDTs matters indeed. the geforce graphic part of SSDT should be loaded after the Intel graphic part... no problem. at least it works now problem-free. i just want to figure out what's the problem with my SSDTs... I was looking at the files you posted in post #164. I assume that ssdt-1.dsl and ssdt-3.dsl are representative of their original order when extracted via Linux? OK... so we can see that ssdt-1.dsl contains some IGPU declarations: Scope (\_SB.PCI0.IGPU) { Method (MXMX, 1, Serialized) { If (LEqual (Arg0, Zero)) { \_SB.PCI0.RP05.PEGP.SGPO (\_SB.PCI0.RP05.PEGP.ESEL, Zero) P8XH (One, 0x77, One) P8XH (Zero, Zero, One) Return (One) } If (LEqual (Arg0, One)) { P8XH (One, 0x77, One) P8XH (Zero, One, One) Return (One) } If (LEqual (Arg0, 0x02)) { P8XH (One, 0x77, One) P8XH (Zero, 0x02, One) Return (LNot (\_SB.PCI0.RP05.PEGP.SGPI (\_SB.PCI0.RP05.PEGP.ESEL))) } Return (Zero) } Method (MXDS, 1, Serialized) { If (LEqual (Arg0, Zero)) { Return (LNot (\_SB.PCI0.RP05.PEGP.SGPI (\_SB.PCI0.RP05.PEGP.DSEL))) } If (LEqual (Arg0, One)) { \_SB.PCI0.RP05.PEGP.SGPO (\_SB.PCI0.RP05.PEGP.DSEL, Zero) } Return (Zero) } Name (TLPK, Package (0x20) { Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C }) } Basically an injection of MXMX MXDS and TLPK objects into Scope (\_SB.PCI0.IGPU). And \_SB.PCI0.IGPU is defined in SSDT-3.aml... an SSDT that is loaded later than SSDT-1.aml. And your fix, so far, is to change the order, renaming SSDT-1.aml to SSDT-4.aml so it loads later, correct? As a test, see what happens if you eliminate this entire section from SSDT-1.aml. eg, patch SSDT-1.aml as such: into scope label \_SB.PCI0.IGPU remove_entry; into device label WMI1 remove_entry; These items are not needed for OS X anyway. Then load them in the original order... does it fix the issue? Link to comment Share on other sites More sharing options...
Demonbane Posted June 26, 2014 Share Posted June 26, 2014 I was looking at the files you posted in post #164. I assume that ssdt-1.dsl and ssdt-3.dsl are representative of their original order when extracted via Linux? OK... so we can see that ssdt-1.dsl contains some IGPU declarations: Scope (\_SB.PCI0.IGPU) { Method (MXMX, 1, Serialized) { If (LEqual (Arg0, Zero)) { \_SB.PCI0.RP05.PEGP.SGPO (\_SB.PCI0.RP05.PEGP.ESEL, Zero) P8XH (One, 0x77, One) P8XH (Zero, Zero, One) Return (One) } If (LEqual (Arg0, One)) { P8XH (One, 0x77, One) P8XH (Zero, One, One) Return (One) } If (LEqual (Arg0, 0x02)) { P8XH (One, 0x77, One) P8XH (Zero, 0x02, One) Return (LNot (\_SB.PCI0.RP05.PEGP.SGPI (\_SB.PCI0.RP05.PEGP.ESEL))) } Return (Zero) } Method (MXDS, 1, Serialized) { If (LEqual (Arg0, Zero)) { Return (LNot (\_SB.PCI0.RP05.PEGP.SGPI (\_SB.PCI0.RP05.PEGP.DSEL))) } If (LEqual (Arg0, One)) { \_SB.PCI0.RP05.PEGP.SGPO (\_SB.PCI0.RP05.PEGP.DSEL, Zero) } Return (Zero) } Name (TLPK, Package (0x20) { Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C, Ones, Ones, 0x2C }) } Basically an injection of MXMX MXDS and TLPK objects into Scope (\_SB.PCI0.IGPU). And \_SB.PCI0.IGPU is defined in SSDT-3.aml... an SSDT that is loaded later than SSDT-1.aml. And your fix, so far, is to change the order, renaming SSDT-1.aml to SSDT-4.aml so it loads later, correct? As a test, see what happens if you eliminate this entire section from SSDT-1.aml. eg, patch SSDT-1.aml as such: into scope label \_SB.PCI0.IGPU remove_entry; into device label WMI1 remove_entry; These items are not needed for OS X anyway. Then load them in the original order... does it fix the issue? yeah! it works now! i have also noticed that, thx for your reminding. and i am a little bit worried about if deleting this section may affect how the system runs. or is it even better to transplant this part into the SSDT-3? Link to comment Share on other sites More sharing options...
RehabMan Posted June 26, 2014 Share Posted June 26, 2014 yeah! it works now! i have also noticed that, thx for your reminding. and i am a little bit worried about if deleting this section may affect how the system runs. or is it even better to transplant this part into the SSDT-3? Like I said, all that stuff is not used by OS X as it is Windows specific. You can re-order the SSDTs or you can remove that section. Either way works around the OS X limitation on SSDT order. OS X ACPI implementation is definitely gimped compared to Windows... Link to comment Share on other sites More sharing options...
legot28 Posted June 26, 2014 Share Posted June 26, 2014 HELLO can someone help me to disable my optimus card in my laptop RC530 samsung i test some method but never work for me i send acpi files from aida and the dsdt that i use with clover thank you acpi dump RC530.zip Link to comment Share on other sites More sharing options...
Recommended Posts