MP 1,1-5,1 MP3,1 (& others?) SSE 4.2 emulation (to enable AMD Metal driver)

[Syncretic]

MouSSE (Partial SSE4.2 Emulator) Public Release
Current version: 0.95 (8 Jun 2021)
When referring folks to MouSSE, please just link directly to this post, which will always contain the latest version & info.​

EDIT (8 Jun 2021/1 Sep 2021): Monterey changed things up, so a new version was required. Version 0.95 (attached to this post) supports Monterey (as well as earlier MacOS versions). No new functionality was added, so if you're already using MouSSE on a pre-Monterey MacOS, there is no need to "upgrade" to v0.95. (I posted this version on 8 Jun 2021, but I was too busy to update Post #1 until 1 Sep 2021, hence the two dates.)

EDIT (22 May 2020): I found what should be a fairly rare bug in v0.92, which is fixed in the current attached version (v0.93). This is a low-priority update, so if you have a working system, don't feel any urgency to replace your copy of MouSSE.

EDIT (5 May 2020): There is a new version of MouSSE (v0.92) attached to this post. It represents a major rewrite, and should be more stable, more robust, and faster than the previous public version (v0.38). To upgrade from the previous release, either overwrite the existing kext with this one (then kextcache -i / and reboot) or get the newest MacOS patcher that contains MouSSE and let it upgrade for you (as of this writing, the authors of both patchers are aware of the new MouSSE version but have not yet released updates to their patchers).

EDIT (13 November 2019): If your system does not contain a Metal AMD GPU, you should not install MouSSE. There are several reported instances of instability in non-AMD-GPU systems, with no clear cause yet identified. Instructions on how to uninstall MouSSE appear in this post (see below).

This software has been tested on various hardware and software configurations, and it seems to be stable enough to release from beta. Please provide any feedback you have, positive or negative, success or failure, in this thread or via direct message to me.

*** IMPORTANT: USE AT YOUR OWN RISK!

This software is provided as-is, without any warranty whatsoever. There is no reason it should cause any problems, but if things go wrong, they're your responsibility. It has been tested and benchmarked on various systems and various versions of MacOS, but there are no guarantees that it will work on any given system or version of MacOS. The author is not responsible for any losses of time, money, hair, memory, peace of mind, car keys, or television remote controls related in any way to the use of this software.​

(And now, after that ringing endorsement...)​

*** What is it?

Newer AMD Mac video drivers use some SSE 4.2 instructions. Older CPUs (Penryn, Harpertown, and earlier) don't support those instructions. Older Mac Pro systems (such as the Mac Pro 3,1) use those older CPUs - therefore, the new AMD drivers won't work in those systems. MouSSE is a partial SSE4.2 emulator that allows those old CPUs to use the newer AMD drivers. While its primary focus has always been making the AMD drivers work, it also appears to allow World of Warcraft to run on a Mac Pro 3,1 regardless of whether or not AMD drivers are in use.​

​

In theory, depending upon what you're trying to accomplish, this emulator could prove useful on any Mac system with a Penryn/Harpertown/Wolfdale CPU. These include:​

Mac Pro 3,1 (Early 2008)​

Xserve 2,1 (Early 2008)​

MacBook Pro 4,1 (Early 2008)​

MacBook 4,1 (Early 2008)​

MacBook 7,1 (Mid-2010)​

MacBook Air 2,1 (October 2008)​

MacBook Air 3,1 (October 2010) (11")​

MacBook Air 3,2 (October 2010) (13")​

iMac 8,1 (April 2008)​

iMac 9,1 (March 2009)​

iMac 10,1 (October 2009) (with Core2 Duo, not i5)​

Mac Mini 3,1 (March 2009, October 2009)​

Mac Mini 4,1 (Mid 2010) (aka Mac Mini Server)​

Not all of these have been tested; your mileage may vary. In addition, CPUs even older than Penryn could utilize this emulator; however, since they lack SSE4.1, adding only partial SSE4.2 would probably be of little or no benefit. IMPORTANT: If you don't have one of those systems - and, in particular, if you have a newer system (such as a Mac Pro 4,1 or 5,1) - you should not install MouSSE. It can't do anything useful for those systems, and could potentially get in the way or cause other issues.​

​

I personally have tested this on MacOS 10.13-10.15 (High Sierra, Mojave, and Catalina 15.0-15.4). Others report that it loads on 10.12 (Sierra), although its AMD drivers do not seem to require emulation.​

*** What does it do?

MouSSE traps illegal instructions in both privileged (kernel) mode and unprivileged (user) mode, and emulates the POPCNT, PCMPGTQ, and CRC32 instructions. As of this writing, PCMPGTQ and POPCNT are the only problematic instructions used in the AMD drivers. (And, apparently, the only two currently used in World of Warcraft.)​

​

MouSSE is fully reentrant, and automatically runs on all CPUs/cores/threads.​

*** What does it NOT do?

At this time, MouSSE does not implement any SSE4.2 instructions other than POPCNT, PCMPGTQ, and CRC32. If there is sufficient demand, a future version may include support for additional SSE4.2 (or other) instructions. If MouSSE encounters an unsupported instruction, it passes control to MacOS, and you will see the same error handling you'd see if MouSSE was not installed (usually, an "Illegal instruction" message and program termination).​

* As of version 0.32, MouSSE no longer behaves transparently when an​

unsupported instruction is encountered. In order to assist troubleshooting,​

MouSSE loads the 16 bytes at the illegal opcode into XMM15, and the first​

8 bytes of that into R15. Both registers are used because while 16 bytes​

provides all the context necessary for analysis, some crash dumps do not​

include the XMM registers, so R15 is also loaded (8 bytes is better than​

nothing). This violates the transparency principle, but given that the​

"illegal opcode" error is generally fatal, the effect is negligible. If you​

know of a situation where this is problematic, please let me know so I can​

devise an alternative. (As of version 0.45, XMM15 and R15 are left untouched,​

and the first 8 bytes of the illegal opcode are returned in RAX instead.)​

* As of version 0.38, a "magic" illegal opcode is handled: the​

normally-illegal instruction 3f 55 44 ("?UD") returns "MouSSE42" in RAX,​

as a way to test that MouSSE is loaded and active. Without MouSSE running,​

that instruction will throw a #UD exception on any system, new or old.​

* As of version 0.91, MouSSE keeps statistics on the instructions it emulates, as​

well as AVX/AVX2/AVX-512 instructions it finds (but does not emulate). These​

statistics are returned with the "magic" instruction is trapped.​

The new MouSSEstats utility can display these statistics.​

Also as of version 0.91, the SSE4.2 CRC32 instruction is implemented.​

At this point, only the SSE4.2 PCMP?STR? instructions remain un-emulated.​

​

Aside from whatever IOKit uses at startup, MouSSE uses no dynamically allocated memory, so there's no chance of a memory leak. MouSSE does not create any processes; it's simply an extension of the kernel.​

​

MouSSE doesn't read or write any files, or access any networks, or touch any other devices. All it does is watch for the instructions it knows about, and emulate those when they turn up. At present, logging only occurs at load time.​

​

MouSSE also does not check to see if your CPU already supports SSE4.2. If you install MouSSE on a newer system, it will load, but it won't ever do anything besides take up a bit of memory, because newer CPUs can handle the SSE4.2 instructions themselves, and MouSSE will silently bear the loneliness of a program that's never asked to actually do anything.​

* As of version 0.38, that's not entirely true - MouSSE does check for​

native SSE 4.2, and explicitly disables itself if the CPU natively supports it.​

At present, there's no simple way to make MouSSE completely unload itself​

in this situation, so it still takes up kernel memory space, but never does​

anything else.​

​

Because an earlier version of MouSSE seemed to cause some confusion, let me be clear: MouSSE does not "advertise" SSE4.2 capability, it simply provides emulation for certain instructions if the CPU tries to execute them. If the CPUID instruction is used to check for SSE4.2 capability on a pre-SSE4.2 CPU, that test will return "SSE4.2 not supported," because MouSSE does not trap CPUID. In practice, this is not an issue, since the SSE4.2 usage that MouSSE primarily targets (the AMD video driver) does not perform this CPUID check.​

Because of all this, MouSSE is passive - if no SSE4.2/illegal instructions are ever encountered, MouSSE will never do anything at all.​

*** Why do I see "AAA.LoadEarly.MouSSE" in my kextstat output?
*** Why is the kext named "AAAMouSSE.kext"?

MacOS has a complex startup procedure. Since the main point of MouSSE is to allow AMD video drivers to work, MouSSE must load and initialize before the AMD drivers do. Part of the system initialization creates a dependency tree, and MouSSE tries to put itself as close to the top of that tree as possible. Outside of that tree, things are handled alphabetically - so, sticking "AAA" at the beginning of the kext name puts it at the top of the alphabetical list (much like finding "AAA-BestPlumbers" at the beginning of the Yellow Pages (does anyone even use the Yellow Pages any more?)). Ordinarily, the full name of the kext would include a right-to-left domain name, such as "com.apple.xyzzy" - but here again, by using a top-level domain named "AAA", MouSSE can push itself to the top of the alphabetical list. It's all just an effort to have MouSSE load and initialize before anything that might use an SSE4.2 instruction.​

*** Anything else?

If you're running newer AMD drivers under a newer OS on an old Mac, you're probably already running with SIP disabled. If not, sorry - this software requires SIP to be disabled.​

​

To simplify the IOKit interface, MouSSE has a small C++ wrapper, but all of the important code is written in assembly language (for speed).​

​

Just to repeat myself, USE THIS SOFTWARE AT YOUR OWN RISK. I've been using it daily on my Mac Pro 3,1 with an AMD Radeon RX 570 for nearly a year without incident, but your mileage may vary. If you lose time, money, or your sanity because of flaws in this software, consider yourself forewarned.​

​

The semi-whimsical name came from elsewhere, but you can think of it as "Macs oughta understand SSE" (MouSSE) if you like. Or, if you're not fond of your sibling, "My outrageously ugly sister sickens everybody." Or, if you're a megalomaniac, "My objective ultimately should supersede everything." Whatever makes you happy.​

​

As of version 0.91, I've added a command-line utility called MouSSEstats that will display some statistics about what MouSSE has encountered since it was last loaded (presumably, the last time the system was rebooted).​

​

For the time being, this post will be the official repository for MouSSE, with updates posted as they occur. At some point in the future, I may move it to a separate host, which will be noted here. When referring people to MouSSE, please just link directly to this post, which will always have the latest version and information.​

*** How do I install it?

The easiest way to install MouSSE is to use one of the MacOS patchers, either from @dosdude1 (http://dosdude1.com) or @0403979/RMC Team (https://github.com/rmc-team/macos-patcher/releases).​

​

I haven't written a standalone installer. For the time being, if you are not installing MouSSE using a MacOS patcher, you need to do the installation manually. Because this forum doesn't allow uploads of .tgz files, the .tgz is zipped - meaning you'll have to uncompress/expand it twice. I suggest the following:​

1. expand the ZIP file, then the enclosed .TGZ file
2. open a terminal
3. type cd {path to the .TGZ file}/MouSSE_RELEASE (change the path for your system)
4. type sudo tar cf - ./AAAMouSSE.kext | (cd /Library/Extensions;tar xf -)
5. type sudo kextcache -i /
6. reboot

(If you're installing to an alternate partition, prepend the root of that partition to both paths, e.g. cd /Volumes/OtherDisk/Library/Extensions and kextcache -i /Volumes/OtherDisk/ - but note that if your currently-booted OS is Mojave or earlier, and /Volumes/OtherDisk/ contains Catalina or later, the kextcache operation will silently fail. This has to do with how Apple divided up the filesystems in Catalina, and has nothing to do with MouSSE.)​

* As of version 0.45, it is recommended to use /Library/Extensions instead​

of /System/Library/Extensions, particularly on Catalina (due to the root​

filesystem being read-only).​

​

Third-party kext managers, such as KextBeast, should also work (but I haven't tested any of those).​

*** How to I uninstall it?

Since MouSSE isn't the sort of thing you'll probably install and uninstall regularly, I also haven't bothered creating an uninstall script. To uninstall MouSSE on the current running system, just do the following:​

1. open a terminal
2. type cd /Library/Extensions, press ENTER
3. type sudo rm -rf AAAMouSSE.kext, press ENTER
4. type sudo kextcache -i /, press ENTER
5. reboot

(To uninstall MouSSE from an alternative disk/partition, change the path in steps 2 and 4 to include the leading volume information, e.g. cd /Volumes/MyOtherMacOSinstallation/Library/Extensions and kextcache -i /Volumes/MyOtherMacOSinstallation/ - but note that if your currently-booted OS is Mojave or earlier, and /Volumes/MyOtherMacOSinstallation/ contains Catalina or later, the kextcache operation will silently fail. This has to do with how Apple divided up the filesystems in Catalina, and has nothing to do with MouSSE.)​

* As of version 0.45, it is recommended to use /Library/Extensions instead of /System/Library/Extensions, particularly on Catalina (due to the root filesystem being read-only).​

​

Just to be clear, if you load the kext manually (via kextload or kextutil), you can safely unload it and it will clean up after itself. If you have a version of MouSSE currently running, you can try replacing it on-the-fly by executing kextunload AAAMouSSE.kext;kextload ./AAAMouSSE.kext in the directory containing ./AAAMouSSE.kext - in my experience, about 75% of the time, this will cause the WindowServer to crash and restart (you'll have to log in again), but the system will remain up; about 20% of the time, nothing will crash/die and the replacement will be seamless; and about 5% of the time, changing MouSSE on-the-fly will result in a blackscreen/reboot.​

I suggest not doing this real-time substitution unless you're prepared for a hard crash, but it is workable most of the time.​

*** OK, I installed MouSSE, but now my new AMD video card is misbehaving...

The most common problems occur if you've previously installed patches to make legacy video cards work. If those patches are installed, MacOS can get confused about which display to use, which framebuffer to use for which display, etc. If you're experiencing problems with a supported modern AMD video card and you still have those patches installed, you'll need to remove them (which unfortunately, in most cases, involves reinstalling the OS). Using a legacy video card (to see the MacOS boot screen) and a modern AMD video card simultaneously, without the "legacy video" patches, is a hit-and-miss proposition - some combinations work some of the time, some don't work at all. While it would be nice to have the "best of both worlds" (visible boot screen and modern GPU acceleration), your best bet is to keep the legacy card on a nearby shelf and only use it when necessary.​

If you're having problems but don't have any legacy video patches installed, please try contacting the author on the MacRumors forum. (I also lurk on the "MacOS * on Unsupported Macs" threads, if you'd rather try me there.)​

​

(As an aside, if you want to change your setup so you can see boot screens on a video card lacking a Mac EFI ROM, check out this post - it works very well. You can also pair it with OpenCore.)​

*** I have a Penryn CPU, but I'm not using a Metal AMD card or running World of Warcraft. Should I install MouSSE?

The short answer is "no." If your system is running OK, and you're not planning to upgrade your video card to a modern AMD model, and/or you're not planning to run any software that requires SSE4.2, then installing MouSSE will just eat up some kernel memory and not provide you any real benefit.​

VERSION HISTORY (only versions that escaped captivity are listed):
v0.20 - 15 Aug 2019 - First version released into the wild.
v0.30 - 12 Sep 2019 - Tweaks to allow installation from El Capitan onward
v0.32 - 20 Sep 2019 - Capture of illegal opcode data in XMM15/R15
v0.35 - 07 Oct 2019 - Added more initialization diagnostics
v0.38 - 17 Oct 2019 - Added more logging, "magic" opcode detection
v0.45 - 28 Feb 2020 - Moved illegal opcode return to RAX for compatibility, fixed POPCNT +32d bug
v0.91 - 14 Apr 2020 - Major rewrite of parser. Fixed several bugs. Added many optimizations. Added CRC32 functionality. Added support for all addressing modes. Added statistics (returned when "magic" instruction is trapped). Recognizes (but does not emulate) AVX/AVX2/AVX-512 instructions.
v0.92 - 28 Apr 2020 - Major rewrite of trap-handling infrastructure, which should make MouSSE far more stable in challenging environments. Also a few minor bug fixes. Improvements to MouSSEstats program.
v0.93 - 22 May 2020 - Minor bug fix (rare - miscalculated displacement)
v0.95 - 08 Jun 2021 - Monterey support

 

[joevt]

I haven't done much testing yet, but I did try it in Catalina on my MacPro3,1. Without it, World of Warcraft.app crashes at launch. With it, it loads and plays. I'm using a GTX 680. There is some strange issue with text drawing though.



I will test other OS versions later. I also have an RX580 to try.
10.11 El Capitan
10.12 Sierra
10.13 High Sierra
10.14 Mojave

Just to be clear, if you load the kext manually (via kextload or kextutil), you can safely unload it and it will clean up after itself.

You can safely unload it even if you did not load the kext manually.

The most common problems occur if you've previously installed patches to make legacy video cards work.

How to determine if "legacy video" patches are installed? The patchers have very little documentation. I would like to see a list of all the patches, what they're for, and what files they affect (so maybe a patch could be undone be replacing the files with the original version from the macOS installer).

UPDATE: a later version (0.93) of the AAAMouSSE.kext fixes the text drawing in World of Warcraft.

 

[joevt]

Some ideas:
If the emulator is installed, then people won't know it fixed anything unless they ran into problems before installing the emulator. Maybe the emulator could have two different code paths:
1) quick path - for best speed
2) debug path - for logging and statistics - keeps track of locations that have illegal instructions. has a count for each location, maybe a stack dump.

The kext could have a UserClient that allows switching between the code paths, dumping and clearing the statistics.

Then a command line utility can be created to call the UserClient.

Keeping track of locations and stack dumps would take memory, so maybe just keep track of the last 100 unique locations (pid, time, address, count).

 

[SanderG]

Hy Syncretic,
I have an iMac 10,1 with ATI Radeon HD 4670, running Mojave with Dosdude1's patcher.
'sysctl machdep.cpu.features machdep.cpu.feature_bits' shows SSE4.1.
Would you recommend installing MouSSE? I'm not playing games but always looking to get the best performance, and am considering to install Catalina.

 

[Syncretic]

How to determine if "legacy video" patches are installed? The patchers have very little documentation. I would like to see a list of all the patches, what they're for, and what files they affect (so maybe a patch could be undone be replacing the files with the original version from the macOS installer).

Alas, I'm as much in the dark about that as you are. I've been bitten by the situation where I've upgraded MacOS and explicitly not applied a legacy video patch, only to later discover that the patch from the previous OS persisted. Hopefully, the patch authors will provide some guidance on this issue in the future.

re:quick/debug options - good suggestions, I'll keep them in mind for future releases. They do seem geared for a fairly narrow audience, though.

Hy Syncretic,
I have an iMac 10,1 with ATI Radeon HD 4670, running Mojave with Dosdude1's patcher.
'sysctl machdep.cpu.features machdep.cpu.feature_bits' shows SSE4.1.
Would you recommend installing MouSSE? I'm not playing games but always looking to get the best performance, and am considering to install Catalina.

If your system (and all the apps you need to run) works, you don't need MouSSE. Your HD4670 card is not metal-compatible, so there's no benefit (of which I'm aware) to trying to switch from Legacy to native AMD drivers. Unless you're planning to upgrade your video card, or have some software that crashes with a mysterious "illegal instruction" fault, I wouldn't add MouSSE to the mix.

 

[jackluke]

How to determine if "legacy video" patches are installed? The patchers have very little documentation. I would like to see a list of all the patches, what they're for, and what files they affect (so maybe a patch could be undone be replacing the files with the original version from the macOS installer).

You can easily check from Catalina Terminal (copy/paste in one line):

find /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/ -name SkyLightOriginal

if you have one occurrence then surely you have a legacy video patch applied, but it's not only that on Catalina the "legacy video patches" imply these (taken from Mojave and patched):

Frameworks: OpenGL.framework , CoreDisplay.framework
Privateframeworks: SkyLight.framework , GPUSupport.framework
Extensions: IOSurface.kext, IOGraphicsFamily.kext, IOAcceleratorFamily2.kext , IONDRVSupport.kext , AppleGraphicsControl.kext

in order to remove the video patch you have to replace them with the stock current Catalina ones, simpler way re-install Catalina over your volume.

 

[netkas]

Finally mousse was released, great!

 

[Steenvoorde]

I tried the (I think) first release of this patch but it didn't work for me. Just a black screen, and I think I saw a cursor in the first second before the screen went dark. So for now I used a 2nd hand GTX 680 with a EFI boot ROM, which works fine. I would love to give it another try with this version and my RX580 in my Mac Pro 3.1, does anybody got a working setup with this combination of MP and GPU?

For the rest, great work. Thanks for the effort Syncretic!

 

[joevt]

You can easily check from Catalina Terminal (copy/paste in one line):

find /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/ -name SkyLightOriginal

if you have one occurrence then surely you have a legacy video patch applied, but it's not only that on Catalina the "legacy video patches" imply these (taken from Mojave and patched):

Frameworks: OpenGL.framework , CoreDisplay.framework
Privateframeworks: SkyLight.framework , GPUSupport.framework
Extensions: IOSurface.kext, IOGraphicsFamily.kext, IOAcceleratorFamily2.kext , IONDRVSupport.kext , AppleGraphicsControl.kext

in order to remove the video patch you have to replace them with the stock current Catalina ones, simpler way re-install Catalina over your volume.

I found no files containing an Original suffix.

sudo find /System/Library /Library -iname '*original*'

This is not sufficient to find patches.

 

[jackluke]

I found no files containing an Original suffix.

sudo find /System/Library /Library -iname '*original*'

This is not sufficient to find patches.

You asked "How to determine if "legacy video" patches are installed?"

I indicated how to find a trace of the "video patches", if you find no "*Original" means you don't have "Video patch" applied to your machine, most probably you have a Metal GPU, that's why.

Don't forget that on any unix shell a search (and any other action: rm, mv, cp and so on) on a file/folder is case-sensitive. You typed in your example a wrong syntax, moreover it's not *original* rather *Original*

Anyway there is no easy way to revert to a unpatched system, because you have to rebuild a prelinkedkernel from patched ones to non-patched ones, also some tricky frameworks are in constant use by macOS, so you can only replace them from a Recovery environment, the quick solution is to re-install .

 

[Ludacrisvp]

Great job again on this. Glad to have it available for everyone now.

 

[joevt]

I indicated how to find a trace of the "video patches", if you find no "*Original" means you don't have "Video patch" applied to your machine, most probably you have a Metal GPU, that's why.

Cool, thanks for confirming.

Don't forget that on any unix shell a search (and any other action: rm, mv, cp and so on) on a file/folder is case-sensitive. You typed in your example a wrong syntax, moreover it's not *original* rather *Original*

I think the syntax is correct. I used -iname for case insensitive name match.

Anyway there is no easy way to revert to a unpatched system, because you have to rebuild a prelinkedkernel from patched ones to non-patched ones, also some tricky frameworks are in constant use by macOS, so you can only replace them from a Recovery environment, the quick solution is to re-install .

I didn't think about modifying frameworks from a running system. I'll keep that in mind if I need to do that in the future. I have many other OSs on my Mac Pro to boot from so it won't be as bad as booting into a Recovery partition.

 

[Ludacrisvp]

I did find an application that causes panic that calls out this kext.
Not a deal breaker for me as this app doesn't really "do" anything other than provide some benchmark type info.

That being said i'm still running version 0.32 of this kext.

"CL!ng" is a small app that shows info about OpenCL devices. And displays some memory bandwidth and compute performance tests for various precisions. Just launching this app causes panic.

Spoiler: Panic stack

Anonymous UUID:       427601D5-A2A6-71E2-7A30-A36B5994CE92

Sun Oct 20 23:48:42 2019

*** Panic Report ***
panic(cpu 0 caller 0xffffff801e2dbadd): Kernel trap at 0xffffff7fa2e3c020, type 6=invalid opcode, registers:
CR0: 0x0000000080010033, CR2: 0x00007fff4d333fb8, CR3: 0x000000078a239000, CR4: 0x00000000000026e0
RAX: 0x0000000000000000, RBX: 0x00007fff9fb2ded0, RCX: 0x000070000cfc00ac, RDX: 0xffffffffffffffff
RSP: 0xfffff6b3c0080130, RBP: 0x000070000cfbd390, RSI: 0x0000000000000000, RDI: 0x000000000000003c
R8:  0x0000000000000000, R9:  0x00000000000f4240, R10: 0x0000000000000001, R11: 0x0000000000000247
R12: 0x00007f92e4001cc0, R13: 0x000070000cfbd420, R14: 0x00007f92e360ba58, R15: 0x0000441f0f660b0f
RFL: 0x0000000000010083, RIP: 0xffffff7fa2e3c020, CS:  0x0000000000000008, SS:  0x0000000000000000
Fault CR2: 0x00007fff4d333fb8, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0

Backtrace (CPU 0), Frame : Return Address
0xffffff801df7fcd0 : 0xffffff801e1ae6ed
0xffffff801df7fd20 : 0xffffff801e2ea185
0xffffff801df7fd60 : 0xffffff801e2db8ba
0xffffff801df7fdd0 : 0xffffff801e15bb40
0xffffff801df7fdf0 : 0xffffff801e1ae107
0xffffff801df7ff10 : 0xffffff801e1adf53
0xffffff801df7ff80 : 0xffffff801e2dbadd
0xffffff801df800f0 : 0xffffff801e15bb40
0xffffff801df80110 : 0xffffff7fa2e3c020
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0x70000cfbd390
      Kernel Extensions in backtrace:
         AAA.LoadEarly.MouSSE(0.32)[6C9C2D6F-A13A-3C61-B239-1F7E81B6C8E4]@0xffffff7fa2e3b000->0xffffff7fa2e3ffff

BSD process name corresponding to current thread: CVMCompiler
Boot args: -v debug=0x144 shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94 -no_compat_check

Mac OS version:
18G103

Kernel version:
Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
Kernel UUID: C41337A1-0EC3-3896-A954-A1F85E849D53
Kernel slide:     0x000000001de00000
Kernel text base: 0xffffff801e000000
__HIB  text base: 0xffffff801df00000
System model name: MacPro3,1 (Mac-F42C88C8)

System uptime in nanoseconds: 125101074062
last loaded kext at 90077186757: com.apple.filesystems.smbfs    3.3.2 (addr 0xffffff7fa22af000, size 442368)
loaded kexts:
fi.dungeon.driver.SATSMARTDriver    0.10.1
com.paragon-software.kext.VDMounter    4.2
com.evosx86.driver.lspcidrv    1.0
org.apple.dont.block.DirectHW    1.4
com.makemkv.kext.daspi    1.5
com.intel.driver.EnergyDriver    3.5.5
net.lundman.zfs    1.7.0
net.lundman.spl    1.7.0
org.rehabman.driver.AppleSmartBatteryManager    1.52
as.vit9696.WhateverGreen    1.2.9
as.vit9696.Lilu    1.3.6
AAA.LoadEarly.MouSSE    0.32
com.parrotgeek.SIPManager    1
com.apple.filesystems.smbfs    3.3.2
com.apple.driver.AudioAUUC    1.70
com.apple.driver.AppleUpstreamUserClient    3.6.5
com.apple.driver.AppleMCCSControl    1.5.9
com.apple.kext.AMDFramebuffer    2.1.1
com.apple.fileutil    2



EOF

 

[joevt]

I did find an application that causes panic that calls out this kext.
Not a deal breaker for me as this app doesn't really "do" anything other than provide some benchmark type info.

That being said i'm still running version 0.32 of this kext.

"CL!ng" is a small app that shows info about OpenCL devices. And displays some memory bandwidth and compute performance tests for various precisions. Just launching this app causes panic.

Try again with the latest version.

CL!ng didn't panic on my MacPro3,1, GTX 680 running 0.35 of the kext. Actually, it works even if I unload the kext.

sudo kextunload -b AAA.LoadEarly.MouSSE

This might be AMD specific.

 

[Shaneee]

Nice work. Any chance of getting the source to look at? Github link or something maybe.

 

[Syncretic]

I did find an application that causes panic that calls out this kext.
Not a deal breaker for me as this app doesn't really "do" anything other than provide some benchmark type info.

That being said i'm still running version 0.32 of this kext.

"CL!ng" is a small app that shows info about OpenCL devices. And displays some memory bandwidth and compute performance tests for various precisions. Just launching this app causes panic.

Sun Oct 20 23:48:42 2019

*** Panic Report ***
panic(cpu 0 caller 0xffffff801e2dbadd): Kernel trap at 0xffffff7fa2e3c020, type 6=invalid opcode, registers:

Interesting - that stack dump suggests that MouSSE itself threw a #UD, which shouldn't be possible. Please try version 0.38 and let me know if anything changed. You've got me curious.

Nice work. Any chance of getting the source to look at? Github link or something maybe.

Thanks. At present, I have no plans to make this an open-source project.

 

[Ludacrisvp]

Try again with the latest version.

CL!ng didn't panic on my MacPro3,1, GTX 680 running 0.35 of the kext. Actually, it works even if I unload the kext.

sudo kextunload -b AAA.LoadEarly.MouSSE

This might be AMD specific.

I have an RX 580 in the 3,1.
CL!ng works fine on my other machine with another RX 580 in it.

 

[Ludacrisvp]

Interesting - that stack dump suggests that MouSSE itself threw a #UD, which shouldn't be possible. Please try version 0.38 and let me know if anything changed. You've got me curious.

I'm still panicking with the 0.38 of MouSSE, the panic, however is so quick / abrupt the Mac can't save anything, just instant reboot.

I also realized I was using version 1.0 of CL!ng, rather than a much more recent version 1.6 that works fine.

The reason I wanted to test with CL!ng is that it can help you determine your actual PCIe bus speed.
In my case it seems I'm stuck with 2.5GT/s (aka PCIe 1.1/1.0) even when this card is in a 16x 2.0 slot.
I wonder if anyone has any ideas on how to get it running at 5.0GT/s (aka PCIe 2.0) speeds in the 3,1.

Spoiler: lspci -vvnn (from macOS)

02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev e7) (prog-if 00 [VGA controller])
    Subsystem: Sapphire Technology Limited Device [1da2:e387]
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 256 bytes
    Interrupt: pin A routed to IRQ 19
    Region 0: Memory at 3f80000000 (64-bit, prefetchable)
    Region 2: Memory at 3f90000000 (64-bit, prefetchable)
    Region 4: I/O ports at 3000 [disabled]
    Region 5: Memory at 91500000 (32-bit, non-prefetchable)
    Expansion ROM at 91540000 [disabled]
    Capabilities: [48] Vendor Specific Information: Len=08 <?>
    Capabilities: [50] Power Management version 3
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
        Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
        DevCap:    MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
            ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
        DevCtl:    CorrErr- NonFatalErr- FatalErr- UnsupReq-
            RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
            MaxPayload 128 bytes, MaxReadReq 512 bytes
        DevSta:    CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend-
        LnkCap:    Port #8, Speed 8GT/s, Width x16, ASPM L1, Exit Latency L1 <1us
            ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
        LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- CommClk-
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta:    Speed 2.5GT/s (downgraded), Width x16 (ok)
            TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR+, OBFF Not Supported
        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
             AtomicOpsCtl: ReqEn-
        LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
             Compliance De-emphasis: -6dB
        LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
    Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Address: 00000000fee00000  Data: 4073
    Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
    Capabilities: [150 v2] Advanced Error Reporting
        UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
        UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
        UESvrt:    DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
        CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
        CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
        AERCap:    First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
            MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
        HeaderLog: 00000000 00000000 00000000 00000000
    Capabilities: [200 v1] Resizable BAR <?>
    Capabilities: [270 v1] Secondary PCI Express <?>
    Capabilities: [2b0 v1] Address Translation Service (ATS)
        ATSCap:    Invalidate Queue Depth: 00
        ATSCtl:    Enable-, Smallest Translation Unit: 00
    Capabilities: [2c0 v1] Page Request Interface (PRI)
        PRICtl: Enable- Reset-
        PRISta: RF- UPRGI- Stopped+
        Page Request Capacity: 00000020, Page Request Allocation: 00000000
    Capabilities: [2d0 v1] Process Address Space ID (PASID)
        PASIDCap: Exec+ Priv+, Max PASID Width: 10
        PASIDCtl: Enable- Exec- Priv-
    Capabilities: [320 v1] Latency Tolerance Reporting
        Max snoop latency: 0ns
        Max no snoop latency: 0ns
    Capabilities: [328 v1] Alternative Routing-ID Interpretation (ARI)
        ARICap:    MFVC- ACS-, Next Function: 1
        ARICtl:    MFVC- ACS-, Function Group: 0
    Capabilities: [370 v1] L1 PM Substates
        L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
              PortCommonModeRestoreTime=0us PortTPowerOnTime=170us
        L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
               T_CommonMode=0us LTR1.2_Threshold=0ns
        L1SubCtl2: T_PwrOn=10us

 

[MIKX]

I had a problem with my Sapphire Dual-X 7970 showing 2.5GT/s in Mojave 10.14.6 18G103 build early this month.

I shut and moved the 7970 to slot 2 and then re-started ( cold boot ) magically fixed this as the card came at at 5GT/S.
Another shutdown, moved the 7970 back to slot 1, restarted plus a THREE TIMES ( consecutively ) NVRAM re-set. It again came up at 5GT/S.

It looks like this re-set my PCIe slots.

I have since removed the 7970 and re-installed my MSI Armor RX 580 8gb which is running correctly at X 16 Link Width @ 5GT/S.

Perhaps older cards ( HD 7970 ) have occasional issues with Mojave 10.14.6 ?

 

[Syncretic]

I'm still panicking with the 0.38 of MouSSE, the panic, however is so quick / abrupt the Mac can't save anything, just instant reboot.

I also realized I was using version 1.0 of CL!ng, rather than a much more recent version 1.6 that works fine.

The reason I wanted to test with CL!ng is that it can help you determine your actual PCIe bus speed.
In my case it seems I'm stuck with 2.5GT/s (aka PCIe 1.1/1.0) even when this card is in a 16x 2.0 slot.
I wonder if anyone has any ideas on how to get it running at 5.0GT/s (aka PCIe 2.0) speeds in the 3,1.

I peeked down the 5.0GT/s rabbit hole once, but didn't make the leap (yet) due to other obligations. @tsialex suggested looking at the end of this document (search for "Enabling PCIe 2.0 on Slot #2" - intended for NVMe SSDs, but PCIe should be PCIe). He also said this was the essential command:

# Set Target Link Speed of MacPro3,1 slot 2 root port to 5GT/s
sudo setpci -s 00:1 CAP_EXP+30.w=2:F

I have not tried any of this myself (yet), but it seems promising.


re: MouSSE panic
I'm still curious what could be causing that panic, assuming it's really coming from within MouSSE. If you're happy running CL!ng v1.6, I'm content to leave well enough alone. If you do discover a saved log or get any stack dump/trace information using MouSSE 0.38, please let me know so I can track it down and sleep better at night.

 

[Ludacrisvp]

I peeked down the 5.0GT/s rabbit hole once, but didn't make the leap (yet) due to other obligations. @tsialex suggested looking at the end of this document (search for "Enabling PCIe 2.0 on Slot #2" - intended for NVMe SSDs, but PCIe should be PCIe). He also said this was the essential command:

# Set Target Link Speed of MacPro3,1 slot 2 root port to 5GT/s
sudo setpci -s 00:1 CAP_EXP+30.w=2:F

I have not tried any of this myself (yet), but it seems promising.

I've tried this countless times using different versions of setpci ... the version that is mentioned in the guide is 3.2.2, and i've also installed 3.5.6.
No matter what i try it does not work it just stays stuck at PCIe 1.0

 

[joevt]

I peeked down the 5.0GT/s rabbit hole once, but didn't make the leap (yet) due to other obligations. @tsialex suggested looking at the end of this document (search for "Enabling PCIe 2.0 on Slot #2" - intended for NVMe SSDs, but PCIe should be PCIe). He also said this was the essential command:

# Set Target Link Speed of MacPro3,1 slot 2 root port to 5GT/s
sudo setpci -s 00:1 CAP_EXP+30.w=2:F

The command was originally from #207 . It usually only works with PCIe devices that are not graphics cards. It sets a target link speed. A second command asks the link to be retrained #212. A PCIe device can choose to ignore the target link speed and choose a lower speed. That's what GPU's do. The GPU driver probably sets a target link speed elsewhere (probably a manufacturer specific register) depending on whether or not compute or rendering is being done.

The command is needed to run PCIe 3.0 devices (like NVMe, Thunderbolt, or new USB cards) at PCIe 2.0 speed instead of PCIe 1.0 speed on Mac Pros before the new firmware installed by Mojave existed (or on MacPro3,1 or earlier which don't get a new firmware). You can also use the command to test lower link speeds for a device (if you have a PCIe 3.0 or PCIe 2.0 slot and want to see how a device behaves at PCIe 2.0 or PCIe 1.0 speed).

Instructions: #474 , Downloads: #482

 

[mani]

Hi,

I'm using a Mac Pro 3,1 on 10.5.2 with RX560 using your patch. The card runs very well under macOS itself, no slow down whatsoever. However, I've been trying to run a Windows 10 VM in Parallels 15 and it seems there is no hardware acceleration at all..so basically unusable. Could this be because you're not emulating the full SSE 4.2 instruction set?

edit: just had the idea of trying parallels 14 on 10.15 which didn't have metal support yet

 

[joevt]

Hi,

I'm using a Mac Pro 3,1 on 10.5.2 with RX560 using your patch. The card runs very well under macOS itself, no slow down whatsoever. However, I've been trying to run a Windows 10 VM in Parallels 15 and it seems there is no hardware acceleration at all..so basically unusable. Could this be because you're not emulating the full SSE 4.2 instruction set?

edit: just had the idea of trying parallels 14 on 10.15 which didn't have metal support yet

Parallels doesn't work on MacPro3,1 at full speed beyond macOS 10.14.3. Nothing to do with SSE emulation - you can uninstall that and Parallels will still work, just unbearably slow.

 

[amd64]

Hello. I am using MacPro3,1 (2 x 2.8 GHz Quad-Core Intel Xeon) on 10.13.6 (17G11023). I've tried to install AAAMouSSE.kext to /S/L/E in order to use my RX470. The Mac OS does boot up successfully but with some glitches, and I am not able to login. After I entered password and then press enter, the login failed and Mac OS only reloads the login screen (back to the user selection screen).

I change back my GTX960 into the Mac Pro and tried executing:
sudo kextunload /System/Library/Extensions/AAAMouSSE.kext
and it was successful, means that the kext is properly installed.

Am I missing something, or are there any solutions? Thank you so much.