First problems come right up :)

Updater hangs when using my current OC 0.6.9 configuration:

Same problem here with ASUS S14 X411UF, and I can only boot with cpus=1 flags, without SMCProcessor kext and with cputscsync. Here is my EFI. If anyone knows, take a look of my EFI and compare haha (or if I missing some Kext, ACPI file or option on my config file.) The ACPICPU problem dissapear if the SMCProcessor is disabled.

Update:

I tried with cputscsync disabled, SMCProcessor Enabled and cpus=1 flag, and I got IOPlatformPanicAction

Hello,
I have the same problem. Unable to boot on MacOS Monterey.
As much with Big Sur, this program / configuration works wonderfully ... as much as I block with Monterey.
Tested with the arguments -lilubetaall -cpus = 1 (either or both)
The kexts are up to date. I disable non-essential kexts (SMCProcessor ...)
I'm desperately looking for a solution

Hello,

I have the same problem. Unable to boot on MacOS Monterey.

As much with Big Sur, this program / configuration works wonderfully ... as much as I block with Monterey.

Tested with the arguments -lilubetaall -cpus = 1 (either or both)

The kexts are up to date. I disable non-essential kexts (SMCProcessor ...)

I'm desperately looking for a solution

Visit the CPUtscsync thread (spoiler: use TSCAdjustReset kext) for a temporal solution.

Hello,
I have the same problem. Unable to boot on MacOS Monterey.
As much with Big Sur, this program / configuration works wonderfully ... as much as I block with Monterey.
Tested with the arguments -lilubetaall -cpus = 1 (either or both)
The kexts are up to date. I disable non-essential kexts (SMCProcessor ...)
I'm desperately looking for a solution

Visit the CPUtscsync thread (spoiler: use TSCAdjustReset kext) for a temporal solution.

Thanks for your return.
I actually replaced CPUtscSync.kext with TSCAdjustReset.kext
Now I can boot and install macOS Monterey.

However, I have a performance problem, the system is idling. The graphics part seems poorly optimized (however I have 1536MB of graphics memory with the HD630)

Second problem, I have an error message when I restart and cannot access the system.
IOHIDlibUserClient to prevent the system from starting ... with several scrolling messages

So, today we have the first public beta of Monterey. My Zenbook UX310 just reboots when I try to install Monterey (it starts, goes up to a 1/4 of the installation bar or so, and then restarts). Those of you using TSCAdjustReset, did you just replace CpuTscSync with TSCAdjustReset and that's all? Because I tried but it happens the same thing. I'm also using -lilubetaall. Do I need any other boot arg here for Monterey?

EDIT: downloaded the updated kexts with latest commits using dortania's webpage. Lilu doesn't need the -lilubetaall bootarg anymore for Monterey. CpuTscSync says it supports Monterey. However, I still can't complete the installation. I wonder what am I missing. I'm using latest kexts with latest open core 0.7.0 and all is working perfectly under Big Sur.

EDIT 2: I tried replacing CpuTscSync with TSCAdjustReset. It doesn't work. Tried with and without cpus=1 bootarg. Also tried removing virtualsmc but, as expected, it doesn't boot. I think we need new kexts to make this work properly.

So, today we have the first public beta of Monterey. My Zenbook UX310 just reboots when I try to install Monterey (it starts, goes up to a 1/4 of the installation bar or so, and then restarts). Those of you using TSCAdjustReset, did you just replace CpuTscSync with TSCAdjustReset and that's all? Because I tried but it happens the same thing. I'm also using -lilubetaall. Do I need any other boot arg here for Monterey?

EDIT: downloaded the updated kexts with latest commits using dortania's webpage. Lilu doesn't need the -lilubetaall bootarg anymore for Monterey. CpuTscSync says it supports Monterey. However, I still can't complete the installation. I wonder what am I missing. I'm using latest kexts with latest open core 0.7.0 and all is working perfectly under Big Sur.

EDIT 2: I tried replacing CpuTscSync with TSCAdjustReset. It doesn't work. Tried with and without cpus=1 bootarg. Also tried removing virtualsmc but, as expected, it doesn't boot. I think we need new kexts to make this work properly.

Try : Setting IOCPUNumber to 0 in TSCAdjustReset.kext
And disable some non-essential kext
you should be able to boot

I still have a problem once the installation is done. If I restart Monterey no longer fully boots

Well, it seems that in my case the error is different. I just get "No por micro restart (we don't support SMC on this platform)" and then it starts shutting down processes and restarts. So, my UX310 seems to not be affected by CpuTscSync, at least for the moment. I tried multiple fixes, nothing seems to work. I'll just wait for updated kexts from acidanthera.

No luck with the UX310. Can't update. I even re-did the EFI folder and still stuck at the same spot. You can check my progress here: https://www.tonymacx86.com/threads/cant-update-from-big-sur-to-monterey.314236/

Ok, I have some news.

After several days testing different things and cleaning my EFI, I FINALLY FOUND THE SOLUTION! It was all about the quirks. Even if it all worked great in Big Sur, for some reason I needed to activate a couple more quirks to be able to upgrade to Monterey.

If anyone else has this problem, getting an MSU 1130 error or something like that, this is what I did. I don't know if all of this is required, but hey, it's what I did, it solved the issue, and as Monterey is now installed and perfectly working I can't test if some steps are not required, so here's the list of things I did:

• Deleted the APPLE folder inside my EFI folder.
• Enable "ProtectMemoryRegions" and "SyncRuntimePermissions" in the Booter section of my plist. Leave all the other quirks exactly as I had them.
• Misc -> Security, set SecureBootModel to Disabled.
• Reboot the system, and in the picker I chose Clear NVRAM. System reboots.
• Boot Big Sur. No issues booting. Run the Monterey update again. This time, I had the feeling that it took a little longer than before.
• System reboots, and the update process begin. Everything went smooth, and after some time, Monterey loaded and everything works: wi-fi, bluetooth, graphics acceleration, sound...

So, if you are experiencing this error or something similar, compare the quirks you have and if you are missing the ones I mention, give it a try. Just take this in consideration:

• If you are using a Broadcom Wi-Fi/BT module, you have to disable BrcmBluetoothInjector and enable the new BlueToolFixup.
• CpuTscSync is not working in Monterey (yet), so you have to replace it with TSCAdjustReset.
• Sleep doesn’t work (well, technically it works, but you cannot wake from sleep, and you have to force a power off).
• Boot time is long (a couple of minutes).
• If you want an EFI folder valid for Big Sur and Monterey without the need to manually activate / de-activate kexts, just set the MaxKernel to 20.9.9 in those kexts that should not be injected in Monterey, and the MinKernel to 21.0.0 to those that are exclusive to Monterey and up. That way OpenCore will inject ones or the others depending on if you are booting Big Sur (or older) or Monterey.

Enable "AllowRelocationBlock"

According to OC official manual, this should not be supported in Big Sur…
See for yourself: Configuration.pdf

I will hopefully fix CpuTscSync soon, as I do believe there’s an error with lapic ids (monterey starts them from id 0, while big sur and lower seem to start them from 1 – this is why you need to adjust Info.plist in TSCAdjustReset.)

According to OC official manual, this should not be supported in Big Sur…

I know. However, it worked. Really weird. I disabled it now, using Monterey, and it the system still works. I'll see what happens when public beta 3 comes out. If you fix CpuTscSync, that would be awesome, as TSCAdjustReset is not ideal, I can't suspend the Mac because it will not wake and I have to force a shutdown, and I also have a long boot process, all pointing to TSCAdjustReset as the culprit.

I do believe you don’t need any TSC syncing if you use BIOS version lower than 307 (I use 308 now) as I do remember not having any issues with unsynced tscs when I was using mojave and catalina before I upgraded my bios. I do suggest checking that out if there are earlier versions of bios available for your laptop.

I remember I didn't need it, but that was in my "Clover age", and I remember I did need some patches. AFAIK, the problem is with Kaby Lake.

the problem is with Kaby Lake.

It’s Kaby Lake Refresh actually.

Ok, I have some news.

After several days testing different things and cleaning my EFI, I FINALLY FOUND THE SOLUTION! It was all about the quirks. Even if it all worked great in Big Sur, for some reason I needed to activate a couple more quirks to be able to upgrade to Monterey.

If anyone else has this problem, getting an MSU 1130 error or something like that, this is what I did. I don't know if all of this is required, but hey, it's what I did, it solved the issue, and as Monterey is now installed and perfectly working I can't test if some steps are not required, so here's the list of things I did:

• Deleted the APPLE folder inside my EFI folder.
• Enable "AllowRelocationBlock", "ProtectMemoryRegions" and "SyncRuntimePermissions" in the Booter section of my plist. Leave all the other quirks exactly as I had them.
• Misc -> Security, set SecureBootModel to Disabled.
• Reboot the system, and in the picker I chose Clear NVRAM. System reboots.
• Boot Big Sur. No issues booting. Run the Monterey update again. This time, I had the feeling that it took a little longer than before.
• System reboots, and the update process begin. Everything went smooth, and after some time, Monterey loaded and everything works: wi-fi, bluetooth, graphics acceleration, sound...

So, if you are experiencing this error or something similar, compare the quirks you have and if you are missing the ones I mention, give it a try. Just take this in consideration:

• If you are using a Broadcom Wi-Fi/BT module, you have to disable BrcmBluetoothInjector, BrcmFirmwareData and BrcmPatchRam3 and enable the new BlueToolFixup.
• CpuTscSync is not working in Monterey (yet), so you have to replace it with TSCAdjustReset.
• If you want an EFI folder valid for Big Sur and Monterey without the need to manually activate / de-activate kexts, just set the MaxKernel to 20.9.9 in those kexts that should not be injected in Monterey, and the MinKernel to 21.0.0 to those that are exclusive to Monterey and up. That way OpenCore will inject ones or the others depending on if you are booting Big Sur (or older) or Monterey.

Thanks for these informations.
I just tried with the settings you mentioned above and I can boot on Monterey.
Everything is functional in the sense of two things:

• Sleep (awakening impossible)
• Adjusting the brightness of the backlit keys

Thanks again. I'm waiting for the patch CPUtscSync

Do you have any idea for adjusting the brightness of the keys?

Sorry, my laptop doesn’t have a backlit keyboard so I can’t test that. Can you adjust the brightness using the sliders included in the Finder?

In fact the problem is random. Often at start-up the function is not active. then after a while, the keypad lights up and the setting options appear. I just did a clean install, but the problem is still present. surely a kext problem ..?

Enable "AllowRelocationBlock", "ProtectMemoryRegions" and "SyncRuntimePermissions" in the Booter section of my plist. Leave all the other quirks exactly as I had them.

I tested on another UX310 on Big Sur, and I was able to prove that “AllowRelocationBlock” is not needed. So, the quirks I had to enable were just “ProtectMemoryRegions” and “SyncRuntimePermissions”. It doesn’t boot without them. I’m editing my message with the instructions to remove “AllowRelocationBlock” from there.

Also, for Broadcom wifi/bt modules (I’m using a DW1560), BlueToolFixup is needed ALONG with BrcmPatchRam3 and BrcmFirmwareData. BlueToolFixup just replaces BrcmBluetoothInjector on Monterey and you still need the other two kexts. If you just inject BlueToolFixup alone, you will see the BT icon, but it won’t connect to bt devices.

Please, test updated kext for some bugs after wake on Monterey (Big Sur and lower versions' code is branched and not changed, so it should work)

acidanthera/bugtracker#1676 (comment)

I tested it and it works, even after sleep. :D

Ok so, as I mentioned in CpuTscSync bugtracker thread, darkwake does not work with latest commit, but normal sleep does.

As a temp solution – you can downgrade your bios to a version, where tsc is properly synced by basic firmware of your chipset, hence, CpuTscSync is not required at all. On Asus Zenbook UX430UAR the correct bios version seems to be .305
You can find download links on asus support website. It is important to correctly identify your model, as, hopefully, I do not need to tell you what can happen if you flash the bios from the wrong model.

@Ubsefor
I get kernel panic after wake up from sleep
I tested latest commit of CpuTscSync this commit worked on clover but do not work on OpenCore
On opencore i get this panic after force restart

Hello,

Has anyone found a solution to our problem?

Thanks

Hello,

Has anyone found a solution to our problem?

Thanks

As I’ve already said earlier:

As a temp solution – you can downgrade your bios to a version,

It's a fine solution, really, because you don’t even need CpuTscSync in that case. Though, I suggest testing it first, as you may experience terrible input lags if TSC is not synced correctly.

Is the CpuTscSync kext up to date for managing the standby mode of our Zenbooks with Monterey?

I just did a clean install.
I took my 100% functional Big Sur EFI record and made some changes.

• OpenCore in version 0.7.5
• Enable "ProtectMemoryRegions" and "SyncRuntimePermissions" in the Booter section of my plist.
• Misc -> Security, set SecureBootModel to Disabled.
• The kexts are all up to date (including cputscsync.kext)

What works:

• Backlit Keyboard
• FN key (keyboard, screen, volume)
• Audio
• Wifi (intel card)
• Computer sleep

What does not work:

• Trackpad

Could someone help me with reconditioning the trackpad?

PS: I updated the VoodooI2C & voodooPS2controller kexts without success

Could someone help me with reconditioning the trackpad?

PS: I updated the VoodooI2C & voodooPS2controller kexts without success

There is a way with SSDT patches, refer to the guide.

No one who has successfully installed monterey?

No one who has successfully installed monterey?

It's 100% working for me

Congratulations! Can you share with me your EFI folder, please?.....

No one who has successfully installed monterey?

I’ve been using it since the first public beta, and now with the latest non-beta version. It all works fine. UX310UA here. You can find my guide on TonyMac (including the EFI).

Congratulations! Can you share with me your EFI folder, please?.....

if you need help or run into problems, don't hesitate.

appendix question, how much video memory do you have with your HD620?
1536MB or 2048MB?

appendix question, how much video memory do you have with your HD620?
1536MB or 2048MB?

It's normal to have 1536Mb as the iGPU gets spoofed as UHD617, which can actually be found in real apple devices.

If someone gets 2G VRAM, I would like to hear how :)

I will inquire with the person who told me about this to have more information

I will inquire with the person who told me about this to have more information

So, how’d you did that?)

TL;DR:
It is actually possible, but its completely unnecessary.
To do that we need to add framebuffer-unifiedmem option to iGPU and set key type to Data with value of 00000080
But actually, there’s no point. It is useful only for 4K displays or if you are having graphic lags. 1,5 Gb as it is by default is quite enough.
But if you really want, you can allocate even more vram (its using your RAM anyways, as integrated cards do not have specified vram like discrete do):
00000040 = 1024MB
00000060 = 1536MB
00000080 = 2048MB
000000A0 = 2560MB
000000C0 = 3072MB
000000E0 = 3584MB
FFFFFFFF = 4096MB

Also, the devs do not recommend setting this value manually, look for framebuffer-unifiedmem on the WEG guide: IntelHD.en.md (see Custom Patches section)

TL;DR: It is actually possible, but its completely unnecessary. To do that we need to add framebuffer-unifiedmem option to iGPU and set key type to Data with value of 00000080 But actually, there’s no point. It is useful only for 4K displays or if you are having graphic lags. 1,5 Gb as it is by default is quite enough. But if you really want, you can allocate even more vram (its using your RAM anyways, as integrated cards do not have specified vram like discrete do): 00000040 = 1024MB 00000060 = 1536MB 00000080 = 2048MB 000000A0 = 2560MB 000000C0 = 3072MB 000000E0 = 3584MB FFFFFFFF = 4096MB

Also, the devs do not recommend setting this value manually, look for framebuffer-unifiedmem on the WEG guide: IntelHD.en.md (see Custom Patches section)

Thanks for reply Ubsefor ;-)
I found out why it can't work on our Zenbooks ...
My friend has an HP Specter with an i7-8550U Wiskey Kake (with 4k screen resolution)
You may have to push the tests to get 2048MB of VRAM on Kaby Lake

Thanks for reply Ubsefor ;-) I found out why it can't work on our Zenbooks ... My friend has an HP Specter with an i7-8550U Wiskey Kake (with 4k screen resolution) You may have to push the tests to get 2048MB of VRAM on Kaby Lake

It can work with out laptops, you just need to add framebuffer-unifiedmem value and enable framebuffer patch.

Also, the proof of concept: