macOS 12 Monterey on Unsupported Macs Thread

macpro_mid2014 · May 24, 2022

makra said:
After updating to 12.4 macFuse doesn't work on my non-metal MBP8.1 any more. I use this extension in combination with Cryptomator. The preference pane proposes to install (what I had tried), but after the installation process, nothing has changed.

View attachment 2008647

Cryptomator reports:
```
Error Code 6PHE:R4U2:R4U2
org.cryptomator.cryptofs.VaultConfigLoadException: Failed to parse config:
at org.cryptomator.cryptofs@2.4.1/org.cryptomator.cryptofs.VaultConfig.decode(VaultConfig.java:115)
at org.cryptomator.desktop@1.6.10/org.cryptomator.common.vaults.VaultConfigCache.readConfigFromStorage(VaultConfigCache.java:62)
at org.cryptomator.desktop@1.6.10/org.cryptomator.common.vaults.VaultConfigCache.reloadConfig(VaultConfigCache.java:30)
at org.cryptomator.desktop@1.6.10/org.cryptomator.common.vaults.VaultListManager.create(VaultListManager.java:102)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
at java.base/java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(Unknown Source)
at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(Unknown Source)
at java.base/java.util.stream.ReferencePipeline.toArray(Unknown Source)
at java.base/java.util.stream.ReferencePipeline.toArray(Unknown Source)
at java.base/java.util.stream.ReferencePipeline.toList(Unknown Source)
at org.cryptomator.desktop@1.6.10/org.cryptomator.common.vaults.VaultListManager.addAll(VaultListManager.java:83)
at org.cryptomator.desktop@1.6.10/org.cryptomator.common.vaults.VaultListManager.<init>(VaultListManager.java:52)
at org.cryptomator.desktop@1.6.10/org.cryptomator.launcher.DaggerCryptomatorComponent$SwitchingProvider.get(DaggerCryptomatorComponent.java:7615)
at dagger@2.41/dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.cryptomator.desktop@1.6.10/org.cryptomator.launcher.DaggerCryptomatorComponent$FxApplicationComponentImpl$SwitchingProvider.get(DaggerCryptomatorComponent.java:7078)
at dagger@2.41/dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.cryptomator.desktop@1.6.10/org.cryptomator.launcher.DaggerCryptomatorComponent$FxApplicationComponentImpl$SwitchingProvider.get(DaggerCryptomatorComponent.java:7065)
at dagger@2.41/dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at org.cryptomator.desktop@1.6.10/org.cryptomator.launcher.DaggerCryptomatorComponent$FxApplicationComponentImpl.application(DaggerCryptomatorComponent.java:7037)
at org.cryptomator.desktop@1.6.10/org.cryptomator.launcher.Cryptomator$MainApp.start(Cryptomator.java:138)
at javafx.graphics@18.0.1/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:847)
at javafx.graphics@18.0.1/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
at javafx.graphics@18.0.1/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at javafx.graphics@18.0.1/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at javafx.graphics@18.0.1/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)

```

Any idea?

I had been using MacFuse since 2016 for VeraCrypt but dumped it a couple of months ago in favour of encrypted APFS.

I remember having to manually download the installer and install the update because of this same issue. I hope this helps in your case.

laertemeira · May 24, 2022

Ausdauersportler said:
First, the post @joevt made has already been mentioned by himself on the Mac Pro thread. Secondly all Mac were all using APFS compression all the time.

Obviously Apple changed some implementation details or simply used another compiler release or new compiler flags using the AVX instructions because now supported Macs will only have 2014+ Intel CPUs.

There is a very small, really very small chance that Apple is going to change this back in later Monterey releases (as it happens with the MonteRand). But on the long run we will face this issue with no real chance to avoid it.

I had same warning message couple days ago. I'm wondering if it has some link with my machine freezing
sometimes...

makra · May 24, 2022

macpro_mid2014 said:
I had been using MacFuse since 2016 for VeraCrypt but dumped it a couple of months ago in favour of encrypted APFS.

I remember having to manually download the installer and install the update because of this same issue. I hope this helps in your case.

I had done that already: Deleted everything, used the installer...

Maybe I should stick to Big Sur with non-metal machines...

chrickers · May 24, 2022

houser said:
I have had great success with the standard OCLP recommendations for install of Win 10 with Bootcamp: https://dortania.github.io/OpenCore-Legacy-Patcher/WINDOWS.html#disk-formatting
FWIW.

It was a pain in the ass to get Windows finally working on my Macbook Pro 11,1 (late 2013)

As recommended I created a separate partition for OCLP and removed

Rich (BB code):

/System

and

Rich (BB code):

/EFI/OC

from the Original EFI-Partition. However when booting, both partitions now look like OCLP (one of them is Bootcamp of course and boots directly into Windows 10). For the other one, the actual OCLP, I activated Boot Picker mode. But no matter how often I try to set Macintosh HD as default, I still picks Windows first. And everytime I boot into macOS Monterey it displays an error message that the system "has restarted after a problem".

I already tried switching partitions and both system were still bootable from OCLP, but the error message in macOS persisted. Any suggestions how I could fix that? My partition table looks like that:

Code:

 #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk1⁩         919.8 GB   disk0s2
   3:       Microsoft Basic Data ⁨OC⁩                      199.2 MB   disk0s3
   4:       Microsoft Basic Data ⁨Bootcamp⁩                80.0 GB    disk0s4

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +919.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD⁩            15.2 GB    disk1s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.2 GB    disk1s1s1
   3:                APFS Volume ⁨Preboot⁩                 298.7 MB   disk1s2
   4:                APFS Volume ⁨Recovery⁩                1.1 GB     disk1s3
   5:                APFS Volume ⁨VM⁩                      3.2 GB     disk1s4
   6:                APFS Volume ⁨Macintosh HD - Daten⁩    181.9 GB   disk1s5

Code:

dmztff · May 24, 2022

roysterdoyster said:
See my post #5,650 of April, 8, where I reported the problem. Monterey 12.3.1 was 100% stable on my machine. All 12.3 Betas and 12.4 Beta versions crashed the system, as well as 12.4 Release. 12.5b1 is behaving much better, still crashing randomly time and time again.

12.5b1 is behaving better, but still crashing randomly? Is it the same kind of crash (still a kernel panic with "invalid opcode"), or something different?

hvds · May 24, 2022

Ausdauersportler said:
APFS compression is an integral part of the file system (used by the macOS itself all the time) and it seems one cannot even disable it. If this analysis turns out to be complete and correct all legacy Macs older than 2011 (pre Sandy Bridge CPU the) will fall into this pit sooner or later. My similar 2010 iMac11,3 is still ignoring this problem??

Didn‘t see it on MBP5,2 (Penryn 9600 CPU).
What would be a good way to trigger automatic compression in APFS? Fill up the file system? (Surf2bikes, dmztff - how full are yor disks)

TOM1211 · May 24, 2022

So I saw system firmware update version for my Mac 11,3 managed it fine repatched from big sur interestingly rebooting to Monterey I didn’t need post install root patch so this stays active even after the Big Sur reboot Also I thought interesting was SilentKnight was still reporting SIP was active on Monterey but obviously wasn’t opencore patch from Monterey ran with SilentKnight saying SIP was active and SIP is now active obviously after doing opencore again (maybe I took the long way to update but anyway it works ) anyway no real issues

zzzippp · May 24, 2022

hvds said:
What would be a good way to trigger automatic compression in APFS? Fill up the file system? (Surf2bikes, dmztff - how full are yor disks)

I lack enough knowledge to know better, but wonder if it's happening while decompressing APFS data?

Code:

0xffffffffd71e3b40 : 0xffffff80187752b2 mach_kernel : _decmpfs_read_compressed + 0x5e2
0xffffffffd71e3cc0 : 0xffffff801b74d7d0 com.apple.filesystems.apfs : _apfs_vnop_read + 0x1a8

Also, would it help to compare AppleFSCompressionTypeZlib.kext from Monterey 12.3.1 versus 12.4 to look at the instructions(s) used previously instead of VMOVDQA64?

EDIT: I just noticed that the com.apple.AppleFSCompression.AppleFSCompressionTypeZlib kext is listed as version 1.0 so my guess is the change to the AVX-dependent VMOVDQA instruction happened elsewhere.

Also of note, decmpfs, the Compressed data extended attribute, is also known as AFSC (Apple File System Compression) or HFS/HFS+ compression, was introduced in Mac OS 10.6 Snow Leopard. AFSC/HFS+ compression has historically been used to compress system files, not user files. So if this macOS Monterey 12.4 kernel panic is really occurring while reading a compressed system file, it's not something brand new in APFS, but rather likely an optimization or change in implementation as @Ausdauersportler said.

Ausdauersportler · May 24, 2022

hvds said:
Didn‘t see it on MBP5,2 (Penryn 9600 CPU).
What would be a good way to trigger automatic compression in APFS? Fill up the file system? (Surf2bikes, dmztff - how full are yor disks)

Neither using Voice Control nor using the afsctool from the link below could cause a KP on my iMac11,3 (Xeon X4370). https://blog.xfbs.net/posts/enabling-apfs-compression

If one wants to analyze different versions of AppleFSCompressionTypeZlib.kext here you go.

Macschrauber · May 24, 2022

is the Nvidia Kepler driver back in 12.4 ?

Screen Sharing Picture 24. May 2022 at 22.10.34 CEST.png

OCLP 0.4.5N, clean install of 12.4 on Mac Pro 5.1

I know I should avoid 12.4 cause of AVX. But this is interesting, tho.

edit: I checked another 12.4 System from a machine with no Kepler GPU.
There was no Kepler Kext.

Seems 0.4.5 patches the installation process and adds the Kepler Kext silently.

Ausdauersportler · May 24, 2022

Macschrauber said:
is the Nvidia Kepler driver back in 12.4 ?

View attachment 2009128

OCLP 0.4.5N, clean install of 12.4 on Mac Pro 5.1

I know I should avoid 12.4 cause of AVX. But this is interesting, tho.

edit: I checked another 12.4 System from a machine with no Kepler GPU.
There was no Kepler Kext.

Seems 0.4.5 patches the installation process and adds the Kepler Kext silently.

Yes, OCLP 0.4.5 got an auto patching feature - check the change logs

Earl Urley · May 24, 2022

Yes, and it's pretty dandy. I was helping to upgrade a friend's iMac Late 2013 27-inch, and this model was one of the last Macs to get nVidia GPUs. Got them to Monterey with OCLP 0.4.5, but after install I noticed weird shadows in menu bars and the machine seeming to operate sluggishly, like it was in Safe mode. Ran OCLP again and it automatically said Kepler patch was available for the machine, so I applied it, and one reboot later everything was running smoothly with no artifacts.

OCLP is pretty smart to also note that it knows when patches are applied so that the next time you run it, it tells you the date the patches were applied and that further patching is unneccessary.

I noted that when I gave up on Monterey 12.4 on that machine and went back to Big Sur, OCLP said no patches were necessary. So yes, Apple yoinked out nVidia drivers for Monterey.

Macschrauber · May 24, 2022

Ausdauersportler said:
Yes, OCLP 0.4.5 got an auto patching feature - check the change logs

Yes I remember there were some comments about it but no details.

Why does Post Install Patch list to add Kepler, also ?

Is the System still sealed after auto patch (guess not) ?

And finally: Legacy Wifi was not auto patched.

zzzippp · May 24, 2022

Ausdauersportler said:
If one wants to analyze different versions of AppleFSCompressionTypeZlib.kext here you go.

Thank you for that! I grabbed the demo version of the Hopper macOS/Linux disassembler app, and had a look at the AppleFSCompressionTypeZlib kernel extensions you supplied from macOS Monterey 12.3.1, 12.4, and 12.5b1.

The demo of Hopper doesn't allow text export so I couldn't do a full diff compare of its disassembled code, but as far as I can tell, it is nearly identical in the AppleFSCompressionTypeZlib kext from macOS Monterey 12.4 and 12.5b1. I see lots of instances of the VMOVDQA instruction that requires a CPU with AVX (Advanced Vector Extension) support. So unless there's a dramatic change, the kernel panic issue will likely still be present in macOS 12.5.

Here's a section of disassembled code that is identical between the AppleFSCompressionTypeZlib kext found in macOS Monterey 12.4 and 12.5b1:

C++:

/*
--------------------------------------------------------------------------------

        File: /Users/xxxxx/Downloads/ZLib/12.4/12.4-AppleFSCompressionTypeZlib
        UUID: 1489EB74-7D7C-34F6-91C0-E6CDD3A25459
        File created with Hopper 5.5.3-demo
        Analysis version 61
        MachO file
        CPU: intel/x86_64
        64 bits addresses (Little Endian)

--------------------------------------------------------------------------------
*/

                     sub_2050:
0000000000002050         push       rbp                                         ; CODE XREF=sub_5498+37
0000000000002051         mov        rbp, rsp
0000000000002054         push       r15
0000000000002056         push       r14
0000000000002058         push       r13
000000000000205a         push       r12
000000000000205c         push       rbx
000000000000205d         and        rsp, 0xffffffffffffffe0
0000000000002061         sub        rsp, 0x480
0000000000002068         mov        r14, r8
000000000000206b         mov        ebx, ecx
000000000000206d         mov        r12, rdx
0000000000002070         mov        r13d, esi
0000000000002073         mov        qword [rsp+0x4a8+var_3D0], rdi
000000000000207b         lea        r15, qword [rsp+0x4a8+var_248]
0000000000002083         mov        esi, 0x200                                  ; argument "n" for method ___bzero
0000000000002088         mov        rdi, r15                                    ; argument "s" for method ___bzero
000000000000208b         call       ___bzero                                    ; ___bzero
0000000000002090         vmovdqa    r15, ymm0
0000000000002095         vmovdqa    r15+0x20, ymm1
000000000000209b         vmovdqa    r15+0x40, ymm2
00000000000020a1         vmovdqa    r15+0x60, ymm3
00000000000020a7         vmovdqa    r15+0x80, ymm4
00000000000020b0         vmovdqa    r15+0xa0, ymm5
00000000000020b9         vmovdqa    r15+0xc0, ymm6
00000000000020c2         vmovdqa    r15+0xe0, ymm7
00000000000020cb         vmovdqa    r15+0x100, ymm8
00000000000020d4         vmovdqa    r15+0x120, ymm9
00000000000020dd         vmovdqa    r15+0x140, ymm10
00000000000020e6         vmovdqa    r15+0x160, ymm11
00000000000020ef         vmovdqa    r15+0x180, ymm12
00000000000020f8         vmovdqa    r15+0x1a0, ymm13
0000000000002101         vmovdqa    r15+0x1c0, ymm14
000000000000210a         vmovdqa    r15+0x1e0, ymm15
0000000000002113         cmp        ebx, 0x4
0000000000002116         jb         loc_214b

0000000000002118         cmp        byte [r12], 0x5a
000000000000211d         jne        loc_214b

000000000000211f         cmp        byte [r12+1], 0x42
0000000000002125         jne        loc_214b

0000000000002127         cmp        byte [r12+2], 0x4d
000000000000212d         jne        loc_214b

000000000000212f         movzx      edx, byte [r12+3]
0000000000002135         test       dl, 0xf0
0000000000002138         jne        loc_214b

000000000000213a         mov        eax, edx
000000000000213c         and        eax, 0x3
000000000000213f         lea        ecx, dword [rax-2]
0000000000002142         cmp        ecx, 0x2
0000000000002145         jae        loc_21e3

However, the disassembled code in the AppleFSCompressionTypeZlib kext from macOS 12.3.1 is completely different in that it does not have any instances of AVX instructions. The MOVDQA instruction is used, but that requires SSE2, so it's more backwards-compatible in terms of CPU support.

joevt said:
The illegal instruction is this:
0000000000002090 C4C17D7F07 vmovdqa r15, ymm0

The info at https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64 says that the instruction requires CPUID Feature Flag "AVX".

The list at https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX
says AVX began with 2011 CPUs.

Are you using File Vault or some other special file system feature?

Maybe we need some AVX emulation? @Syncretic?

Seeing as the new version of the AppleFSCompressionTypeZlib kext introduced in macOS 12.4 seems to rely heavily on VEX (Vector EXtension) encoding instructions, it looks like emulation probably isn't going to be the answer because emulating a whole instruction set will result in a real performance hit. If this kext is handling the reading of compressed system files as I suspect, AVX emulation could lead to all kinds of noticeable general slowness in day-to-day usage.

Perhaps a better approach might be to "patch" macOS >12.4 with the AppleFSCompressionTypeZlib kext from 12.3.1? I'm out of my depths already, but the concern there would be over any dependencies elsewhere in the 12.4+ system on the updated AppleFSCompressionTypeZlib kext.

Ausdauersportler said:
First, the post @joevt made has already been mentioned by himself on the Mac Pro thread. Secondly all Mac were using APFS compression all the time.

Obviously Apple changed some implementation details or simply used another compiler release or new compiler flags using the AVX instructions because now supported Macs will only have 2014+ Intel CPUs.

There is a very small, really very small chance that Apple is going to change this back in later Monterey releases (as it happens with the MonteRand). But on the long run we will face this issue with no real chance to avoid it.

The continued presence of AVX instructions in the 12.5 beta's AppleFSCompressionTypeZlib kext seems to bear this out.

joevt · May 24, 2022

zzzippp said:
The demo of Hopper doesn't allow text export so I couldn't do a full diff compare of its disassembled code, but as far as I can tell, it is nearly identical in the AppleFSCompressionTypeZlib kext from macOS Monterey 12.4 and 12.5b1. I see lots of instances of the VMOVDQA instruction that requires a CPU with AVX (Advanced Vector Extension) support. So unless there's a dramatic change, the kernel panic issue will likely still be present in macOS 12.5.

Hopper's Search function for string in assembly works in the demo version? So you can just do a search for the vmovdqa instruction.
You can disassemble the binary using the otool command.
If you remove all the hex numbers and the ## comments (using sed or perl or bbedit's regular expression search and replace), then the only diff part is the function that has the vmovdqa instructions.

Code:

otool -function_offsets -tvV /Volumes/Storage/Downloads/ZLib/12.3.1/12.3.1-AppleFSCompressionTypeZlib > /Volumes/Storage/Downloads/ZLib/12.3.1/12.3.1-AppleFSCompressionTypeZlib.txt
otool -function_offsets -tvV /Volumes/Storage/Downloads/ZLib/12.4/12.4-AppleFSCompressionTypeZlib > /Volumes/Storage/Downloads/ZLib/12.4/12.4-AppleFSCompressionTypeZlib.txt
otool -function_offsets -tvV /Volumes/Storage/Downloads/ZLib/12.5\ Beta\ 1/12.5-B1-AppleFSCompressionTypeZlib > /Volumes/Storage/Downloads/ZLib/12.5\ Beta\ 1/12.5-B1-AppleFSCompressionTypeZlib.txt
bbdiff /Volumes/Storage/Downloads/ZLib/12.3.1/12.3.1-AppleFSCompressionTypeZlib.txt /Volumes/Storage/Downloads/ZLib/12.4/12.4-AppleFSCompressionTypeZlib.txt

joevt · May 24, 2022

zzzippp said:
because emulating a whole instruction set will result in a real performance hit

SDE does more things than we need. https://forums.macrumors.com/thread...enable-amd-metal-driver.2206682/post-30774137
We just need something like MouSSE.kext to trap the illegal instruction and do something other than kernel panic.
I haven't run into this kernel panic so far (MacPro3,1 Monterey 12.4). So I don't think there are many occurrences that need to be emulated.

@Syncretic has been looking at AVX emulation since prior to this. Now there's a reason to get it done but he's a busy guy.
https://forums.macrumors.com/threads/looking-for-avx-avx2-software-failures.2283830/post-30798490
https://forums.macrumors.com/thread...tart-of-an-ongoing-saga.2320479/post-31122340

There is a possible fix from OCLP in that last thread.

jgleigh · May 24, 2022

Macschrauber said:
Yes I remember there were some comments about it but no details.

Why does Post Install Patch list to add Kepler, also ?

Is the System still sealed after auto patch (guess not) ?

And finally: Legacy Wifi was not auto patched.

I believe Auto Patching only works on clean installs (from USB). Please correct me if that is wrong. The Post Install Menu still allows you to manually add (or update) patches.

jgleigh · May 24, 2022

Any chance we can get a setting for SetApfsTrimTimeout in OCLP? Would be nice to avoid manually editing the config file each time for Samsung NVMe users. Bugs are still closed on GitHub.

rehkram · May 24, 2022

Uh oh . . . did I miss a recent Catalina security release that had a firmware update bundled with it?

My rMBP 10,1 is on firmware 426.0.0.0.0, SilentKnight's just recently started advising that it should be on 429.0.0.0.0

I keep Catalina on an external SSD just for this purpose, since it's the last supported macOS version for this m/c. Before I go looking for the update, does anyone know the details?

Ausdauersportler · May 24, 2022

zzzippp said:
Thank you for that! I grabbed the demo version of the Hopper macOS/Linux disassembler app, and had a look at the AppleFSCompressionTypeZlib kernel extensions you supplied from macOS Monterey 12.3.1, 12.4, and 12.5b1.

The continued presence of AVX instructions in the 12.5 beta's AppleFSCompressionTypeZlib kext bears this out.

The (continued) presence can just happen by changing a simple single compiler flag without even touching the code. So I assume there is still a small chance.

Check this post out for a first patch (@joevt already mentioned this indirectly).

All the users who can replicate/force the problem on their (MacPro5,1) systems are welcome to test it and report back! The OCLP developers could not force a single crash on their (older) systems.

hvds · May 24, 2022

zzzippp said:
Thank you for that! I grabbed the demo version of the Hopper macOS/Linux disassembler app, and had a look at the AppleFSCompressionTypeZlib kernel extensions you supplied from macOS Monterey 12.3.1, 12.4, and 12.5b1.

The demo of Hopper doesn't allow text export so I couldn't do a full diff compare of its disassembled code, but as far as I can tell, it is nearly identical in the AppleFSCompressionTypeZlib kext from macOS Monterey 12.4 and 12.5b1. I see lots of instances of the VMOVDQA instruction that requires a CPU with AVX (Advanced Vector Extension) support. So unless there's a dramatic change, the kernel panic issue will likely still be present in macOS 12.5.

Here's a section of disassembled code that is identical between the AppleFSCompressionTypeZlib kext found in macOS Monterey 12.4 and 12.5b1:

C++:

/* -------------------------------------------------------------------------------- File: /Users/xxxxx/Downloads/ZLib/12.4/12.4-AppleFSCompressionTypeZlib UUID: 1489EB74-7D7C-34F6-91C0-E6CDD3A25459 File created with Hopper 5.5.3-demo Analysis version 61 MachO file CPU: intel/x86_64 64 bits addresses (Little Endian) -------------------------------------------------------------------------------- */ sub_2050: 0000000000002050 push rbp ; CODE XREF=sub_5498+37 0000000000002051 mov rbp, rsp 0000000000002054 push r15 0000000000002056 push r14 0000000000002058 push r13 000000000000205a push r12 000000000000205c push rbx 000000000000205d and rsp, 0xffffffffffffffe0 0000000000002061 sub rsp, 0x480 0000000000002068 mov r14, r8 000000000000206b mov ebx, ecx 000000000000206d mov r12, rdx 0000000000002070 mov r13d, esi 0000000000002073 mov qword [rsp+0x4a8+var_3D0], rdi 000000000000207b lea r15, qword [rsp+0x4a8+var_248] 0000000000002083 mov esi, 0x200 ; argument "n" for method ___bzero 0000000000002088 mov rdi, r15 ; argument "s" for method ___bzero 000000000000208b call ___bzero ; ___bzero 0000000000002090 vmovdqa r15, ymm0 0000000000002095 vmovdqa r15+0x20, ymm1 000000000000209b vmovdqa r15+0x40, ymm2 00000000000020a1 vmovdqa r15+0x60, ymm3 00000000000020a7 vmovdqa r15+0x80, ymm4 00000000000020b0 vmovdqa r15+0xa0, ymm5 00000000000020b9 vmovdqa r15+0xc0, ymm6 00000000000020c2 vmovdqa r15+0xe0, ymm7 00000000000020cb vmovdqa r15+0x100, ymm8 00000000000020d4 vmovdqa r15+0x120, ymm9 00000000000020dd vmovdqa r15+0x140, ymm10 00000000000020e6 vmovdqa r15+0x160, ymm11 00000000000020ef vmovdqa r15+0x180, ymm12 00000000000020f8 vmovdqa r15+0x1a0, ymm13 0000000000002101 vmovdqa r15+0x1c0, ymm14 000000000000210a vmovdqa r15+0x1e0, ymm15 0000000000002113 cmp ebx, 0x4 0000000000002116 jb loc_214b 0000000000002118 cmp byte [r12], 0x5a 000000000000211d jne loc_214b 000000000000211f cmp byte [r12+1], 0x42 0000000000002125 jne loc_214b 0000000000002127 cmp byte [r12+2], 0x4d 000000000000212d jne loc_214b 000000000000212f movzx edx, byte [r12+3] 0000000000002135 test dl, 0xf0 0000000000002138 jne loc_214b 000000000000213a mov eax, edx 000000000000213c and eax, 0x3 000000000000213f lea ecx, dword [rax-2] 0000000000002142 cmp ecx, 0x2 0000000000002145 jae loc_21e3

However, the disassembled code in the AppleFSCompressionTypeZlib kext from macOS 12.3.1 is completely different in that it does not have any instances of AVX instructions. The MOVDQA instruction is used, but that requires SSE2, so it's more backwards-compatible in terms of CPU support.

Seeing as the new version of the AppleFSCompressionTypeZlib kext introduced in macOS 12.4 seems to rely heavily on VEX (Vector EXtension) encoding instructions, it looks like emulation probably isn't going to be the answer because emulating a whole instruction set will result in a real performance hit. If this kext is handling the reading of compressed system files as I suspect, AVX emulation could lead to all kinds of noticeable general slowness in day-to-day usage.

Perhaps a better approach might be to "patch" macOS >12.4 with the AppleFSCompressionTypeZlib kext from 12.3.1? I'm out of my depths already, but the concern there would be over any dependencies elsewhere in the 12.4+ system on the updated AppleFSCompressionTypeZlib kext.

The continued presence of AVX instructions in the 12.5 beta's AppleFSCompressionTypeZlib kext bears this out.

Looking at the AppleFSCompressionTypeZlib from 12.3.1 and 12.5b1 with Hopper, they seem quite comparable (apart from AVX usage). What is sub_2050 in .5b1 seems sub_2610 in.3.1; called from sub_5498 and sub_5494 resp. Generated asm files attached.
I still can't provoke the kp in my MBP5,2. Think I'll replace the AppleFSCompressionTypeZlib in .5b1 with the .3.1 and see what happens. (My MBP5,2 is now merely a testing machine since it has a fault in the charging circuitry.)
Anyway khronokernel has already provided a patch as reported on Discord / monterey.

hvds · May 25, 2022

hvds said:
Looking at the AppleFSCompressionTypeZlib from 12.3.1 and 12.5b1 with Hopper, they seem quite comparable (apart from AVX usage). What is sub_2050 in .5b1 seems sub_2610 in.3.1; called from sub_5498 and sub_5494 resp. Generated asm files attached.
I still can't provoke the kp in my MBP5,2. Think I'll replace the AppleFSCompressionTypeZlib in .5b1 with the .3.1 and see what happens. (My MBP5,2 is now merely a testing machine since it has a fault in the charging circuitry.)
Anyway khronokernel has already provided a patch as reported on Discord / monterey.

In 12.5b1, replaced the AppleFSCompressionTypeZlib in .kext with the one from 12.3.1. Used jackluke's good old BigSurmountsrw.app for this.
12.5b1 running fine with this downgraded AppleFSCompressionTypeZlib so far.

BTW 12.5b1 running fine in general on MBP5,2 including BT and WLAN. Using OCLP 046n from 23 May.

headlessmike · May 25, 2022

rehkram said:
Uh oh . . . did I miss a recent Catalina security release that had a firmware update bundled with it?

My rMBP 10,1 is on firmware 426.0.0.0.0, SilentKnight's just recently started advising that it should be on 429.0.0.0.0

I keep Catalina on an external SSD just for this purpose, since it's the last supported macOS version for this m/c. Before I go looking for the update, does anyone know the details?

Catalina Security Update 2022-004 was released together with Monterey 12.4. So the firmware update is probably part of that.

mwidjaya · May 25, 2022

headlessmike said:
Catalina Security Update 2022-004 was released together with Monterey 12.4. So the firmware update is probably part of that.

Confirmed.

If applied, firmware will move to 429.xxxx.

Tockman · May 25, 2022

Firmware updated successfully.

macOS 12 Monterey on Unsupported Macs Thread

macrumors 6502

macrumors member

macrumors 6502

macrumors member

macrumors newbie

macrumors 6502a

macrumors 6502

macrumors member

macrumors 603

Attachments

macrumors 68040

macrumors 603

macrumors 6502a

macrumors 68040

macrumors member

macrumors 604

macrumors 604

macrumors regular

macrumors regular

macrumors 6502a

macrumors 603

macrumors 6502a

Attachments

macrumors 6502a

macrumors 68000

macrumors 6502

macrumors 6502

Our Staff