Jump to content
303 posts in this topic

Recommended Posts

@deeveedee

 

I had a similar laptop with an Arrandale processor many years ago, a samsung r540 I think I remember...

 

Mine had an ATI GPU not compatible with OSX, so I tried it once and since it didn't have graphic acceleration I didn't try it anymore.

 

So I can't help you with that laptop because I have no idea. 😞

@PG7 I'm reviewing your proposed changes now and will test.  What do you think the problem is (was)?

For anyone who is reviewing my solution for this Dell Latitude E6410 and you're trying to figure out how I implemented working sleep (and wake), you may have discovered that I have a bug in my SSDT-PTS-WAK ACPI.  

 

In the code snippet below (in my _WAK method), code execution is conditional on NHDA which is declared as External.  NHDA is not defined anywhere in the Dell Latitude E6410 ACPI (and I never defined it).

                If ((VVID == 0x10DE))
                {
                    If ((NHDA == One))
                    {
                        \_SB.PCI0.AGP.VID.MLTF = One
                    }
                    Else
                    {
                        \_SB.PCI0.AGP.VID.MLTF = Zero
                    }
                }

 

This bug has been in my _WAK implementation since I first implemented it here, so it turns out that I got lucky that the laptop actually wakes. When I get a chance, I'll be revising _WAK to fix this bug.  I have found that with the undefined NHDA, neither condition executes (not even the Else condition), so I'm actually not sure what happens.  It's amazing that the laptop wakes normally.

Edited by deeveedee
On 11/1/2022 at 2:01 AM, deeveedee said:

Failed boot (verbose output interrupted when printing "AppleACPICPU: Process Id=6 LocalApic Id=5 Disabled" and instead prints "AppleACPICPU: Process Id=6 Loconsole relocated to 0xf91000000"

Is this "Failed boot" appeared after OCLP root patch? If yes, I had same issue yesterday on my core2 quad rig. I changed boot arg, in windows, from amfi=0x80 to amfi_get_out_of_my_way=1 and it booted without problems. Funny is that, after I updated OC, LegacyBoot and LogoutHook and deleted NVRAM folder from EFI, I reverted to amfi=0x80 and I had no problems booting.

Also, at the beginning I had a lot of problems making core2 rigs booting. Until I found the boot quirks working for me. Maybe you should give a try. Take a look at kernel patches too (MaxKernel). 

 

At the second thought, I suspect NVRAM (emulated NVRAM) variables conflict between different OS's boots. Just my two cents!

 

 

Spoiler

1.thumb.png.916c4dad6fb3ecfafa3889ce5319049c.png

 

 

Spoiler

2.thumb.png.2bab21f96c6e3f70610992fb68c9ab85.png

 

 

Spoiler

3.thumb.png.e2d6396316d326e8c3a84df6baf44461.png

 

 

Spoiler

4.thumb.png.bbd4b503feb5df9f3fd2f759daa17d09.png

 

Edited by Stefanalmare
  • Like 1
  • Thanks 1

@Stefanalmare Thank you.  I will review your suggestions and experiment with different boot args.  Note that I do reset NVRAM when switching between OS versions.  I'm not certain, but I think the Monterey boot failure is more likely to happen after I first reset NVRAM.  It seems to me that the boot problem happens less frequently if I'm booting Monterey after emulated NVRAM is already populated by LogoutHook (from a previous boot of Monterey).

 

The best solution for me right now is to run Big Sur, because it boots flawlessly.

Today, I have been using this Dell Latitude E6410 (booting Big Sur) to perform tasks that included Safari, Xcode, Microsoft Word, VNC Viewer and Microsoft Remote Desktop.  I have been running for 3 hours on battery and have 17% remaining.  I'm pleasantly surprised by the battery life of this old laptop.  Notice that my Big Sur EFI does not include any additional power management kexts and is still utilizing native macOS power management.  The only power management patch that I have implemented (same that I have implemented since first creating this solution for Mojave here) is to spoof an Apple compatible LPCB for the MacBookPro6,2 (see my SSDT-LPCB).  Note that I'm not spoofing a newer macOS model.  The fan on this laptop rarely runs and when it does, it runs low.

 

LPCB IORegistry

Spoiler

1546701112_ScreenShot2022-11-02at10_21_08AM.png.c81dfcecfd742f03872f15c2376ce43d.png

 

Edited by deeveedee

Use "Launchd.command uninstall" to remove LogoutHook.  Leaving the post below for historical purposes.

 

===============================================

 

I upgraded to the current Beta version of OC0.8.6 (and the kexts that are scheduled to be released with OC0.8.6).  Big Sur continues to boot without issues and the intermittent Monterey boot issue remains (no change in boot behavior).  One interesting change that I can't explain is that I was unable to run Hackintool 3.8.7 in Monterey (never had any problems with Hackintool on other platforms).  Hackintool ran fine in Big Sur but not Monterey on this HackBookPro6,2.  After upgrading to OC0.8.6 (which included a reinstall of the LogoutHook), Hackintool launches and runs without issues in both Monterey and Big Sur.

 

When I upgraded to OC0.8.6 Beta, I uninstalled LogoutHook before installing the OC0.8.6 version with the following commands:

 

// Unload and remove old LogoutHook
sudo launchctl unload /Library/LaunchDaemons/org.acidanthera.nvramhook.daemon.plist
sudo rm /Library/LaunchDaemons/org.acidanthera.nvramhook.daemon.plist

// Load new LogoutHook
Utilities/LogoutHook/Launchd.command install

 

Edited by deeveedee
  • Like 2
18 hours ago, deeveedee said:

For anyone who is reviewing my solution for this Dell Latitude E6410 and you're trying to figure out how I implemented working sleep (and wake), you may have discovered that I have a bug in my SSDT-PTS-WAK ACPI.  

 

In the code snippet below (in my _WAK method), code execution is conditional on NHDA which is declared as External.  NHDA is not defined anywhere in the Dell Latitude E6410 ACPI (and I never defined it).

                If ((VVID == 0x10DE))
                {
                    If ((NHDA == One))
                    {
                        \_SB.PCI0.AGP.VID.MLTF = One
                    }
                    Else
                    {
                        \_SB.PCI0.AGP.VID.MLTF = Zero
                    }
                }

 

This bug has been in my _WAK implementation since I first implemented it here, so it turns out that I got lucky that the laptop actually wakes. When I get a chance, I'll be revising _WAK to fix this bug.  I have found that with the undefined NHDA, neither condition executes (not even the Else condition), so I'm actually not sure what happens.  It's amazing that the laptop wakes normally.

I found the same lines in DSDT of my E6430. NHDA is defined and calculated dynamically

                    If (ToInteger (OPVL))
                    {
                        OPTF (One, Zero)
                        NHDA = Zero
                        If (ToInteger (OPFL))
                        {
                            OPTF (One, One)
                            NHDA = One
                        }
                    }

But I didn't traced all calculations. I think it is related to power of Nvidia card.

  • Like 1

@Slice I think I took the code from your posted DSDT(or someone else's posted 6230 DSDT) when I was trying to get sleep / wake to work. The Dell Latitude E6410 ACPI doesn't define GFX0.Off and GFX0.On methods.  I copied those methods and other things from posted ACPI of newer Dell laptops and was lucky enough to get sleep/wake to work.  In your DSDT, you'll find that NHDA is hard-coded as One before it is referenced ( Name (\NHDA, One) ).

 

EDIT: I'm in the process of using Rehabman's ACPI Debug to trace my _WAK method to figure out what's going on.

 

                If ((VVID == 0x10DE))
                {
                    If ((NHDA == One))
                    {
                        \_SB.PCI0.AGP.VID.MLTF = One
                    }
                    Else
                    {
                        \_SB.PCI0.AGP.VID.MLTF = Zero
                    }
                }

 

Edited by deeveedee

EDIT: I have confirmed that the VID._ON() method is not required in my _WAK method for the Latitude E6410.  I need to continue testing after finding this bug as explained below.  Currently I'm running with SSDT-PTS-WAK-NEW attached as a replacement for SSDT-PTS-WAK.  This new SSDT eliminates NHDA references and eliminates the call to VID._ON() in my _WAK method.

 

EDIT2: While this was a bug in my ACPI that does appear to be fixed, it does not resolve the Monterey boot issue. I didn't expect it to, but it was wishful thinking.

=============================================== 

I used Rehabman's ACPIDebug to trace my _PTS and _WAK methods and have some surprising results.  As you can see from the debug output below, _PTS calls VID._OFF() which is required to put the laptop to sleep.  Because NHDA is not declared in my ACPI, _WAK execution aborts and VID_ON() is never called in my _WAK method.  I got lucky when I first implemented this.  VID._ON() is not required to wake the laptop.  If I force VID_ON() to be called, the laptop screen stays dark when the laptop wakes (so calling VID._ON() in the _WAK method actually breaks wake on the Latitude E6410).

 

Debug output for attached _PTS and _WAK methods (see attached SSDT-PTS-WAK-DEBUG):

  1. 2022-11-02 21:51:37.638013-0400 0x115f     Default     0x0                  0      0    kernel: (ACPIDebug) ACPIDebug: { "Entering _PTS.  Arg0: ", 0x3, }

  2. 2022-11-02 21:51:37.647547-0400 0x115f     Default     0x0                  0      0    kernel: (ACPIDebug) ACPIDebug: "Calling VID._OFF"

  3. 2022-11-02 21:51:43.000447-0400 0x115f     Default     0x0                  0      0    kernel: (ACPIDebug) ACPIDebug: { "Entering _WAK.  Arg0: ", 0x3, }

  4. 2022-11-02 21:51:43.001384-0400 0x115f     Default     0x0                  0      0    kernel: (ACPIDebug) ACPIDebug: { "VVID: ", 0x10de, }

 

History of my sleep / wake solution for the Dell Latitude E6410

I think that there is confusion about my _PTS and _WAK methods.  In the 9 years from 2010 when the Dell Latitude E6410  was first released until 2019, no one ever got sleep / wake to work on the E6410 when running macOS.  I reviewed the E6410 ACPI and compared to the ACPI for newer Dell laptops (like @Slice's E6430) and found that the E6410 ACPI was missing elements.  Through trial and error, I was able to add code to the E6410 ACPI that allowed the laptop to sleep and wake.  As you can see from this post, I stopped with my sleep / wake implementation before truly understanding what code was required.  Based on this debugging, I can remove the NHDA reference and VID._ON() from my _WAK method and the laptop should still sleep and wake.

SSDT-PTS-WAK-DEBUG.aml.zip

SSDT-PTS-WAK-NEW.aml.zip

Edited by deeveedee
Corrected typo (changed NVDA to NHDA)
  • Like 1

This is awesome.  I'm being prompted to upgrade to Ventura on my HackBookPro6,2.  I won't be upgrading until OCLP officially supports Ventura on the MacBookPro6,2, but it is incredible.

 

Upgrade to Ventura

Spoiler

775810256_ScreenShot2022-11-04at8_05_12PM.png.979aacc0b6182bc8ef316709e5abafd4.png

 

EDIT: If I've given the impression that this old HackBookPro doesn't have any limitations, it's close to perfect, but it does have limitations.  I have found that iMovie downloads and installs from the App Store, but iMovie crashes shortly after startup.  I don't think this should be a surprise.  iMovie runs well on this HackBookPro6,2 with High Sierra.

Edited by deeveedee
  • Like 1

Leaving this post for historical purposes.  CPUFriend.kext does not fix the intermittent Monterey boot issue.  The intermittent Monterey boot issue is solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.

 

=======================================

 

EDIT: Leaving the post below for background.  It appears that if I disable CPU Turbo States in BIOS, Monterey repeatedly boots without the problem reported below.  Does this mean that I need CPUFriend (or equivalent) solution?

 

EDIT2: When I attempt to run CorpNewt's CPUFriendFriend, I get the following error:

#######################################################
#                  CPUFriendFriend                    #
#######################################################

Could not load Mac-F22586C8.plist!
Aborting!

[Errno 2] No such file or directory: '/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/Mac-F22586C8.plist'

 

EDIT3: I created a custom CPU for ssdtPRGen and was able to generate an SSDT for the i7-620m.  There were a few errors during the process which I think might be resolved if I run in High Sierra instead of in Monterey.  The custom CPU string I used for the i7-620m is as follows.  Anyone with expertise here?  If so, can you let me know if this is correct?  Thanks!

 

i7-620m,35,1330,2660,3330,2,4,2,133

 

=================================================

 

Thanks, everyone, for the suggestions for fixing Monterey boot.  I have tried your suggestions and other things that I can think of, but am still not able to resolve the intermittent Monterey boot failure.  Big Sur is booting flawlessly with the same EFI.  Below is a screenshot of a normal Monterey verbose boot log showing the "console relocated..." line which is the last printed line before Monterey boot fails (if it fails).  The next line in the verbose log (AppleIntelCPUPowerManagement: Turbo Ratios...) (which does not print when Monterey boot fails) is where the boot may fail and cause an automatic reboot.  It's been a while since I diagnosed boot issues on legacy hardware, but this feels like a problem similar to TSCSync.  I did try TSCSync.kext, but it didn't work and I may have incorrectly implemented the kext (CPU is 2 core / 4 thread).  I'm not sure why TSCSync (if that is the problem) would happen in Monterey but not Big Sur.

 

I'm still open to suggestions.  Once booted, Monterey works fine.  This problem (when it occurs) is only during Monterey boot.

 

Spoiler

IMG_2209.thumb.PNG.56a1932ce99b0260621f8790c7de8e5b.PNG

 

Edited by deeveedee
  • Like 1

The intermittent Monterey boot issue is solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.  Leaving the post below for historical purposes.

 

====================================

 

CPUFriend.kext did not fix the intermittent Monterey boot issue.  I'm still looking for a solution to the intermittent Monterey boot issue.  If I allow the laptop to reboot, it will eventually boot Monterey.  Big Sur has no boot issues.  The only solution I've found that reliably allows Monterey to boot without issues is to disable CPU Turbo Boost in BIOS.

 

Maybe I used CPUFriend.kext incorrectly?  If anyone knows how to use it, could you confirm my steps below?  I'm not the sharpest tool in the shed, but I'm usually able to figure out how to use something.  I found all instructions about ssdtPRGen and CPUFriend.kext to be among the most cryptic, convoluted instructions I've ever read.  I'm open to the fact that it might just be me.  If you know how to use CPUFriend, please review my steps below and let me know what I did wrong. Thank you.

 

For those who want to use CPUFriend.kext, here's what I did:

  1. Download ssdtPRGen from PIkeRAlpha
  2. Add undefined CPU data to ssdtPRGen's 'User Defined.cfg' (for my i7-620m, I used this CPU configuration string: i7-620m,35,1330,2660,3330,2,4,2,133
  3. run ssdtPRGen.sh to create ssdt.aml with CPU frequency data
  4. Download CPUFriend.kext from Acidanthera's GitHub repo
  5. Use CPUFriend/Tools/ResourceConverter.sh to generate CPUFriendDataProvider.kext from ssdtPRGen's frequency data (ResourceConverter.sh --kext <path to ssdt.aml>)
  6. Install CPUFriend.kext and CPUFriendDataProvider.kext in EFI (in OC/Kexts and in config.plist)
  7. Reboot
  8. Examine IORegistry for CPU Frequency Data
Edited by deeveedee
56 minutes ago, deeveedee said:

CPUFriend.kext did not fix the intermittent Monterey boot issue.  I'm still looking for a solution to the intermittent Monterey boot issue.  If I allow the laptop to reboot, it will eventually boot Monterey.  Big Sur has no boot issues.  The only solution I've found that reliably allows Monterey to boot without issues is to disable CPU Turbo Boost in BIOS.

 

Maybe I used CPUFriend.kext incorrectly?  If anyone knows how to use it, could you confirm my steps below?  I'm not the sharpest tool in the shed, but I'm usually able to figure out how to use something.  I found all instructions about ssdtPRGen and CPUFriend.kext to be among the most cryptic, convoluted instructions I've ever read.  I'm open to the fact that it might just be me.  If you know how to use CPUFriend, please review my steps below and let me know what I did wrong. Thank you.

 

For those who want to use CPUFriend.kext, here's what I did:

  1. Download ssdtPRGen from PIkeRAlpha
  2. Add undefined CPU data to ssdtPRGen's 'User Defined.cfg' (for my i7-620m, I used this CPU configuration string: i7-620m,35,1330,2660,3330,2,4,2,133
  3. run ssdtPRGen.sh to create ssdt.aml with CPU frequency data
  4. Download CPUFriend.kext from Acidanthera's GitHub repo
  5. Use CPUFriend/Tools/ResourceConverter.sh to generate CPUFriendDataProvider.kext from ssdtPRGen's frequency data (ResourceConverter.sh --kext <path to ssdt.aml>)
  6. Install CPUFriend.kext and CPUFriendDataProvider.kext in EFI (in OC/Kexts and in config.plist)
  7. Reboot
  8. Examine IORegistry for CPU Frequency Data

Hi! I see you use 1330 for Low Frequency Mode. Did you found this with  AppleIntelInfo.kext? Also, the correct Processor Number is i7-620M, not i7-620m.

Try this: i7-620M,35,1330,2660,3330,2,4 and ./ssdtPRGen.sh -p 'i7-620M' -f 2660 -turbo 3330

Try with CPUFriend.kext and if it doesn't work, use just SSDT-PM.

  • Like 1
  • Thanks 1

@Stefanalmare Correct me if I'm wrong, but since I'm creating a custom CPU entry in ssdtPRGen's 'User Defined.cfg,' the name of the CPU doesn't matter as long as I use the same name in the ''User Defined.cfg' file and in my ssdtPRGen.sh command line.  I could call the CPU 'Luigi' and it would still work.  I don't think the name matters, but I will try it.  I'll also try adding -f and -turbo arguments.  I didn't look in AppleIntelInfo.kext - I just guessed at the LFM.  I'll look in the AppleIntelInfo.kext in High Sierra to see if I can find it.

 

Thanks for your help!

26 minutes ago, deeveedee said:

I could call the CPU 'Luigi' and it would still work

Wrong! I'm not 100% sure, but the name in the ''User Defined.cfg' must match machine processor Number.

@Stefanalmare Ok.  If you didn't say it with an exclamation mark, I might not have heard you ;) That seems strange, since the brand string reported byssdtPRGen makes no mention of i7-620M, but I'll trust you.

 

Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz

 

Here's what AppleIntelInfo.kext reports when loaded in High Sierra:

 

CPU Ratio Info:

------------------------------------------

Base Clock Frequency (BLCK)............. : 133 MHz

Maximum Efficiency Ratio/Frequency.......:  9 (1197 MHz)

Maximum non-Turbo Ratio/Frequency........: 20 (2660 MHz)

Maximum Turbo Ratio/Frequency............: 25 (3325 MHz)

P-State ratio * 133 = Frequency in MHz

Edited by deeveedee
16 minutes ago, deeveedee said:

If you didn't say it with an exclamation mark, I might not have heard you ;)

I'm not a native English speaker and never lived in English culture. So maybe some times I can offend with my words, But is not my intention.

 

16 minutes ago, deeveedee said:

Here's what AppleIntelInfo.kext reports when loaded in High Sierra:

So you have now all you need: Low freq: 1197, base freq 2660 and turbo 3325. Build SSDT-PM and cpufriend in HS and use it in all (including Monterey).

 

https://www.intel.com/content/www/us/en/products/sku/43560/intel-core-i7620m-processor-4m-cache-2-66-ghz/specifications.html

 

 

Spoiler

1.thumb.png.d9c1e90c34e8c986ee1f6e941506aca4.png

 

Edited by Stefanalmare
  • Like 1

EDIT: @Stefanalmare Thank you again for your help.  I'm leaving the post below for historical purposes, but the new CPUFriendDataProvider.kext (generated from the new i7-620M ssdtPRGen ssdt) did not fix the Monterey boot issue.

 

I do believe that we're much closer to a solution given that we know that disabling CPU Turbo Boost in BIOS allows Monterey to boot without issues.

 

I generated and used the new ssdtPRGen SSDT and CPUFriendDataProvider.kext as follows:

 

  1. Build AppleIntelInfo.kext with Xcode 9 in High Sierra
  2. Modify AppleIntelInfo.kext/Contents/Info.plist to disable all options (loading AppleIntelInfo.kext freezes this old hack if the options are left enabled)
  3. Modify AppleIntelInfo.kext permissions and disable SIP so that kext can be loaded
  4. Run sudo kextload AppleIntelInfo.kext
  5. Run cat /tmp/AppleIntelInfo.dat to see CPU Frequency Data generated by AppleIntelInfo.kext
  6. Install ssdtPRGen in High Sierra
  7. Add i7-620M data to 'User Defined.cfg': i7-620M,35,1197,2660,3325,2,4,0,133 (with Low Frequency and Turbo Frequency reported by AppleIntelInfo.kext)
  8. Run ssdtPRGen.sh -p 'i7-620M' -f 2660 -turbo 3325 to generate ssdt.aml with CPU frequency data
  9. Download CPUFriend.kext [Release]
  10. Run CPUFriend/Tools/ResourceConverter.sh --kext ssdt.aml (where ssdt.aml is the SSDT generated by ssdtPRGen) to produce CPUFriendDataProvider.kext
  11. Install CPUFriend.kext and CPUFriendDataProvider.kext in EFI (in OC/Kexts and in config.plist).  Set minKernel to 21.0.0 so the kexts load only in Monterey and newer macOS
  12. Boot Monterey with new EFI

 

===========================================

 

@Stefanalmare No offense taken.  I'm very appreciative of the help!  Grazie per l'aiuto! (exclamation intended :) )

 

I have generated two SSDTs with ssdtPRGen: one with CPU name i7-620M and one with CPU name Luigi.  The two ssdts are attached.  The only difference between them is a debug statement indicating the target processor.  Also attached is the ssdt-data generated by CPUFriend/Tools/ResourceConverter.sh (which extracts the frequency data from the SSDT generated by ssdtPRGen).  The CPUFriend ssdt-data does not extract the CPU name and there is no difference between the ssdt-data generated using 'i7-620M' and 'Luigi' (but I'm still going to use the ssdt-data generated with 'i7-620M' 😀

 

Note that I entered this string in ssdtPRGen's 'User Defined.cfg' file: i7-620M,35,1197,2660,3325,2,4,0,133

 

I changed the LFM to 1197 and the turbo frequency to 3325 (both reported by AppleIntelInfo.kext).  I changed the CPU type to 0, since the Arrandale CPU is an unknown type for ssdtPRGen.  I used the following command to generate the CPU frequency data:

 

ssdtPRGen -p 'i7-620M' -f 2660 -turbo 3325

 

ssdt-i7-620M.aml ssdt-Luigi.aml ssdt_data.dsl

Edited by deeveedee
  • Like 2

Since CPUFriend did not fix the Monterey boot issue, I wanted to make sure that CPUFriend.kext and CPUFriendDataProvider.kext are loading correctly. I confirmed in IORegistry:

 

Spoiler

1697723648_ScreenShot2022-11-05at8_51_01PM.thumb.png.10ab0be688149c7fc64bc65646ceeaaf.png

 

and I confirmed with AppleIntelInfo.kext

 

CPU Ratio Info:
------------------------------------------
Base Clock Frequency (BLCK)............. : 133 MHz
Maximum Efficiency Ratio/Frequency.......:  9 (1197 MHz)
Maximum non-Turbo Ratio/Frequency........: 20 (2660 MHz)
Maximum Turbo Ratio/Frequency............: 25 (3325 MHz)
P-State ratio * 133 = Frequency in MHz
------------------------------------------

 

Edited by deeveedee
  • Like 2

CPUFriend.kext injects CPU frequencies.  The Nvidia dGPU on the I7-620M also has a turbo mode.  Is it possible that the Monterey boot problem is caused by the dGPU turbo mode and not the CPU turbo mode?  If so, is it possible to inject dGPU frequencies?

Do you use ASPP-Override.kext? Have you tried booting Clover?

 

After seeing your ioreg, I'm pretty sure CPUfriend is not a solution for you. It is working just if X86PlatformPlugin is on. So, the PowerManagement is different for Arrandale. See attach.

 

Spoiler

1.thumb.png.b82a5149cf71b3689c6141de09efc946.png

 

I have attached also genuine MacBookPro6,2 ioreg. Take a look.

For genuine PowerManagement I'll try ASPP-Override.kext with AppleIntelCPUPowerManagement.kext and AppleIntelCPUPowerManagementClient.kext.

If you'll have under CPU, ACPI_SMC_PlatformPlugin, AGPMEnabler, AGPMController and under NVDA, AGPM, gpu-control, you're done. It is max you can achieve for PowerManagement.

MacBookPro6,2.ioreg

Edited by Stefanalmare
  • Like 1
  • Thanks 1

@Stefanalmare Thank you again for your continued assistance.  My config.plist currently includes the following two Kernel > Add entries (with minKernel = 22.0.0) (copied from the EFI generated by OCLP).  If I change minKernel to 21.0.0 (Monterey), attempting to boot Monterey results in a kernel panic.  In order to boot Monterey, I can't load these AppleIntelCPUPowerManagement kexts.

 

config.plist Kernel >Add AppleIntelCPUPowerManagement

Spoiler

2124183159_ScreenShot2022-11-06at7_42_50AM.png.cf17b92bb71b520d7955af8f0a4193f3.png

 

When booting Monterey, my IORegistryExplorer shows the following for my CPU and Graphics PM (without any CPU Power Management kexts and without CPUFriend.kext).  I am injecting ASPP-Override.kext with minKernel = 21.4.0 (copied from the OCLP-generated EFI).

Spoiler

1216817906_ScreenShot2022-11-06at7_40_09AM.png.7ca0a4fdcc95a7d1650847c9a35d94c4.png

 

When I was originally creating the solution for the Dell Latitude E6410, I did reference the ACPI and IOReg from a real MacBookPro6,2.  You should notice some elements of my ACPI patching for this hack that were taken from a real MacBookPro6,2 (e.g., SLPB).

 

I am currently running with the attached ssdt (generated by ssdtPRGen as you had suggested earlier) and I think my laptop runs better with the CPU PM ssdt.  The ssdt-PM doesn't fix the Monterey boot problem, so it still remains that the only way I have found to fix the Monterey boot problem is to disable CPU TurboBoost in BIOS.  This Monterey boot problem seems similar to what I remember when trying to debug TscSync.  This comment in Acidanthera's CpuTscSync ReadMe is interesting: WARNING: CPUs without MSR_IA32_TSC_ADJUST (03Bh) are currently unsupported on macOS 12 and newer.

 

Thanks again for your help!

ssdt-MyCpuPm.aml

2 hours ago, deeveedee said:

@Stefanalmare Thank you again for your continued assistance.  My config.plist currently includes the following two Kernel > Add entries (with minKernel = 22.0.0) (copied from the EFI generated by OCLP).  If I change minKernel to 21.0.0 (Monterey), attempting to boot Monterey results in a kernel panic.  In order to boot Monterey, I can't load these AppleIntelCPUPowerManagement kexts.

 

config.plist Kernel >Add AppleIntelCPUPowerManagement

  Reveal hidden contents

2124183159_ScreenShot2022-11-06at7_42_50AM.png.cf17b92bb71b520d7955af8f0a4193f3.png

 

When booting Monterey, my IORegistryExplorer shows the following for my CPU and Graphics PM (without any CPU Power Management kexts and without CPUFriend.kext).  I am injecting ASPP-Override.kext with minKernel = 21.4.0 (copied from the OCLP-generated EFI).

  Hide contents

1216817906_ScreenShot2022-11-06at7_40_09AM.png.7ca0a4fdcc95a7d1650847c9a35d94c4.png

 

When I was originally creating the solution for the Dell Latitude E6410, I did reference the ACPI and IOReg from a real MacBookPro6,2.  You should notice some elements of my ACPI patching for this hack that were taken from a real MacBookPro6,2 (e.g., SLPB).

 

I am currently running with the attached ssdt (generated by ssdtPRGen as you had suggested earlier) and I think my laptop runs better with the CPU PM ssdt.  The ssdt-PM doesn't fix the Monterey boot problem, so it still remains that the only way I have found to fix the Monterey boot problem is to disable CPU TurboBoost in BIOS.  This Monterey boot problem seems similar to what I remember when trying to debug TscSync.  This comment in Acidanthera's CpuTscSync ReadMe is interesting: WARNING: CPUs without MSR_IA32_TSC_ADJUST (03Bh) are currently unsupported on macOS 12 and newer.

 

Thanks again for your help!

ssdt-MyCpuPm.aml 1.28 kB · 0 downloads

Do you have gpu-control under GPU? Install Ventura and you'll have a final answer.

×
×
  • Create New...