extract latest windowserver crash log from /Library/Logs/DiagnosticReports folder
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 10.14 Mojave on Unsupported Macs Thread
- Thread starter dosdude1
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Another data point re: SSE4.2 patch for MP3,1:
I have been working on a full SSE4.2 emulator kext that will (hopefully) support the AMD video cards, as well as any new SSE4.2 software that comes down the road later. I'm still testing, but one thing I noticed is that AMDMTLBronzeDriver (for which Netkas came up with a very clever patch) isn't the only ATI/AMD-related file that uses SSE4.2. Depending on what flavor ATI/AMD card you use, and what software you're trying to load (e.g. Metal vs. OpenGL vs. other), the actual device driver itself might use SSE4.2 instructions (notably, AMDRadeonX3000, AMDRadeonX4000, AMDRadeonX5000, and a shared bundle, AMDSharedIL - there may be others; these are just the ones I've identified so far). Those of you experiencing problems with Netkas' patch might be encountering these other drivers - if any of your logs show "invalid opcode", "illegal instruction", TRAP 0x06, or similar, that's the likely culprit. (Sadly, I've also found that illegal instructions at the kernel level often produce no useful logs due to the way panics are handled, so you might have few clues to follow.)
Netkas' patch will always be faster than a full emulation, because it doesn't have the overhead of exception processing and instruction decoding. However, it applies only to a single file (AMDMTLBronzeDriver), which may or may not fill all of the needs of a given AMD GPU, and it appears (for now) to be OS version-specific. I think that long-term, an external SSE4.2 emulator will hold up better in the face of updates from both Apple and third-party driver suppliers - assuming the emulator is fast enough to avoid graphical anomalies, timing glitches, etc. Time will tell.
I'll post more about the emulator here when it's ready for release (or broader beta-testing).
I have been working on a full SSE4.2 emulator kext that will (hopefully) support the AMD video cards, as well as any new SSE4.2 software that comes down the road later. I'm still testing, but one thing I noticed is that AMDMTLBronzeDriver (for which Netkas came up with a very clever patch) isn't the only ATI/AMD-related file that uses SSE4.2. Depending on what flavor ATI/AMD card you use, and what software you're trying to load (e.g. Metal vs. OpenGL vs. other), the actual device driver itself might use SSE4.2 instructions (notably, AMDRadeonX3000, AMDRadeonX4000, AMDRadeonX5000, and a shared bundle, AMDSharedIL - there may be others; these are just the ones I've identified so far). Those of you experiencing problems with Netkas' patch might be encountering these other drivers - if any of your logs show "invalid opcode", "illegal instruction", TRAP 0x06, or similar, that's the likely culprit. (Sadly, I've also found that illegal instructions at the kernel level often produce no useful logs due to the way panics are handled, so you might have few clues to follow.)
Netkas' patch will always be faster than a full emulation, because it doesn't have the overhead of exception processing and instruction decoding. However, it applies only to a single file (AMDMTLBronzeDriver), which may or may not fill all of the needs of a given AMD GPU, and it appears (for now) to be OS version-specific. I think that long-term, an external SSE4.2 emulator will hold up better in the face of updates from both Apple and third-party driver suppliers - assuming the emulator is fast enough to avoid graphical anomalies, timing glitches, etc. Time will tell.
I'll post more about the emulator here when it's ready for release (or broader beta-testing).
Very clear pictures and description, I also use some Kingston SSD, many here complained of them, but I have no issues using them too on legacy machines.
Any chance that even a full SSE4.x emulator could be done? That would bring latest macOS (from 10.12 upwards) to MacPro 1,1 & 2,1 Xeons and MacBook Pro 3,1 Meroms... ?
@dosdude1 I cannot say "Thank you!" enough...
I've been in software development since 1979. For 40 years, I have -- and still do -- make my living developing software. The last 18 years, that has been on Microsoft platforms.
In mid-2009, I moved away from Windows and the PC platform in my personal life. First it was an iPhone, then a MacBookPro5,5 and, finally, a iMac9,1. This was one of the smartest moves I ever made in my use of technology. In 10 years, Apple's hardware and OSes have just worked... and worked... and worked... I've upgrade my iPhone a few times -- currently on a 6s, but my MBP and iMac are still around. I've maxed out memory, upgraded hard drives and replaced the power supply and battery on the MBP, but, otherwise, these two have just been rock solid.
The only downside has been being dead-ended at macOS El Capitan (10.11). Don't get me wrong, El Capitan is (was?) great! However, the various applications that I rely on every day in my personal life have, one-by-one, begun to require the latest version of macOS to upgrade to the most recent release.
Last summer, I began considering building a Hackintosh. I have spent months looking at system configurations, pricing, installation guides, reading blogs, etc. For some reason, I have never been able to wrap my head around the whole thing. What about reliability? Cost? Support? I wasn't going to save any money and I was getting the entire support burden -- hardware and software -- back on my plate. That's why I moved to the Mac platform in the first place.
A couple of weeks ago, it suddenly dawned on me that I had two perfectly good, paid-for Mac sitting on my desk. I thought, "If somebody figured out how to install Mojave on non-Apple hardware, maybe somebody has figured out how to install Mojave on old, unsupported Apple hardware. Hmmmmm...."
I now have my MBP up and running on Mojave. That was pretty straight-forward thanks to macOS Mojave Patcher. I also have my most important application -- Quicken 2019 -- up and running on Mojave. That however, took a bit more work.
After upgrading my MBP from El Capitan to Mojave (10.14.5) and installing Quicken 2019 (the latest version), Quicken was having trouble with Webkit. Basically, when the product asks you to enter your credentials ("Quicken ID"), it attempts to retrieve a Web page using WebKit. WebKit tried three times, got an error every time and then crashing after the third attemp, leaving Quicken high and dry.
I spent several hours chatting with two Quicken support reps and on the phone with two more. I was able to capture the crashes both with
and with the Console app. Dutifully and hopefully, I sent it all to Quicken Support.
Being unsatisfied waiting on Quicken, I started over. This time I erased the hard drive on the MBP (formatting it as APFS) and did a clean install of Mojave using the patcher. Then I installed Quicken 2019. I was disappointed -- but not surprised -- when Quicken and Webkit did the same old fatal dance. Then, something magical happened.
First, the Patch Updater informed me there were some updates available. So, I updated... and rebooted. Then, System Preferences > Software update alerted me that there was a Mojave update for the MBP. I thought, "What the heck? I might as well give it a try..." So, I applied the update and rebooted.
Apparently, that fix had something to do with WebKit or another component that it relies upon. All I can tell you is this. After that last update, Quicken and WebKit are no longer fighting to the death!
I am gradually installing other apps that I use regularly on my iMac. I want to ensure that I can live with what does and doesn't work under Mojave. The MBP upgrade has been an experiment. Now that it appears to have been successful, I think I'll soon be upgrading my iMac to Mojave as well.
Thanks again to @dosdude1 and everyone who has contributed. This has been an amazing experience. This is what the Internet is all about... at least for this old geezer, LOL!
Cheers!
I've been in software development since 1979. For 40 years, I have -- and still do -- make my living developing software. The last 18 years, that has been on Microsoft platforms.
In mid-2009, I moved away from Windows and the PC platform in my personal life. First it was an iPhone, then a MacBookPro5,5 and, finally, a iMac9,1. This was one of the smartest moves I ever made in my use of technology. In 10 years, Apple's hardware and OSes have just worked... and worked... and worked... I've upgrade my iPhone a few times -- currently on a 6s, but my MBP and iMac are still around. I've maxed out memory, upgraded hard drives and replaced the power supply and battery on the MBP, but, otherwise, these two have just been rock solid.
The only downside has been being dead-ended at macOS El Capitan (10.11). Don't get me wrong, El Capitan is (was?) great! However, the various applications that I rely on every day in my personal life have, one-by-one, begun to require the latest version of macOS to upgrade to the most recent release.
Last summer, I began considering building a Hackintosh. I have spent months looking at system configurations, pricing, installation guides, reading blogs, etc. For some reason, I have never been able to wrap my head around the whole thing. What about reliability? Cost? Support? I wasn't going to save any money and I was getting the entire support burden -- hardware and software -- back on my plate. That's why I moved to the Mac platform in the first place.
A couple of weeks ago, it suddenly dawned on me that I had two perfectly good, paid-for Mac sitting on my desk. I thought, "If somebody figured out how to install Mojave on non-Apple hardware, maybe somebody has figured out how to install Mojave on old, unsupported Apple hardware. Hmmmmm...."
I now have my MBP up and running on Mojave. That was pretty straight-forward thanks to macOS Mojave Patcher. I also have my most important application -- Quicken 2019 -- up and running on Mojave. That however, took a bit more work.
After upgrading my MBP from El Capitan to Mojave (10.14.5) and installing Quicken 2019 (the latest version), Quicken was having trouble with Webkit. Basically, when the product asks you to enter your credentials ("Quicken ID"), it attempts to retrieve a Web page using WebKit. WebKit tried three times, got an error every time and then crashing after the third attemp, leaving Quicken high and dry.
I spent several hours chatting with two Quicken support reps and on the phone with two more. I was able to capture the crashes both with
Code:
log streamBeing unsatisfied waiting on Quicken, I started over. This time I erased the hard drive on the MBP (formatting it as APFS) and did a clean install of Mojave using the patcher. Then I installed Quicken 2019. I was disappointed -- but not surprised -- when Quicken and Webkit did the same old fatal dance. Then, something magical happened.
First, the Patch Updater informed me there were some updates available. So, I updated... and rebooted. Then, System Preferences > Software update alerted me that there was a Mojave update for the MBP. I thought, "What the heck? I might as well give it a try..." So, I applied the update and rebooted.
Apparently, that fix had something to do with WebKit or another component that it relies upon. All I can tell you is this. After that last update, Quicken and WebKit are no longer fighting to the death!
I am gradually installing other apps that I use regularly on my iMac. I want to ensure that I can live with what does and doesn't work under Mojave. The MBP upgrade has been an experiment. Now that it appears to have been successful, I think I'll soon be upgrading my iMac to Mojave as well.
Thanks again to @dosdude1 and everyone who has contributed. This has been an amazing experience. This is what the Internet is all about... at least for this old geezer, LOL!
Cheers!
My emulator traps invalid opcodes and tries to handle them if it can. There's no reason it couldn't have more instructions added, including SSE4.1. However, I'd note that while SSE4.2 adds a manageable 7 instructions (each with their own various addressing modes), SSE4.1 adds another 47 (or 48, I haven't really researched it), each of those having various addressing modes, quirks, etc. It would be a major undertaking, and I'm not sure if there would be sufficient demand to warrant the effort.
Great news
emu is always better becauseit will support all current and future versions
my pcmpgtq emu isn't the fastest one, I have compiled original c code without -Os. there is about 3-4 instrucitons that can be thrown away easily. And I have placed in the code code which I believe is dead (r800 mtl driver bits)
I also have checked opengl bundle and it doesn't use sse4.2 recently (but was using it in 10.14.0)
afair, I have only seen pcmpgtq as the only sse4.2 instruction to be used by drivers.
Last edited:
The other one that's common in the AMD drivers/bundles is popcnt (technically not SSE4.2, but contemporary, so it might as well be), which is easy enough to emulate efficiently. The tricky bit is supporting all the addressing modes...
Since there appears to be significant consensus,
that a specific build of 10.14.3 is the most stable/efficient Mojave OS to run on unsupported Mac's, what is the Terminal command to ignore ALL subsequent Mojave Updates please?
And then the reverse command, if 10.14.16 proves to be better, when publicly released?
Thank you.
EDIT:
Indeed, if time proves 10.14.16 to be better, can this command below be incorporated,
to avoid the apparent firmware issues it introduces?
softwareupdate --ignore "MacBook Pro Supplemental Update"
that a specific build of 10.14.3 is the most stable/efficient Mojave OS to run on unsupported Mac's, what is the Terminal command to ignore ALL subsequent Mojave Updates please?
And then the reverse command, if 10.14.16 proves to be better, when publicly released?
Thank you.
EDIT:
Indeed, if time proves 10.14.16 to be better, can this command below be incorporated,
to avoid the apparent firmware issues it introduces?
softwareupdate --ignore "MacBook Pro Supplemental Update"
That would be awesome. I think the cMP got enough juice left for emulation.
[doublepost=1560097381][/doublepost]
I can’t give you an exact number but if you have a look here:
https://forums.macrumors.com/thread...s-x-el-capitan.1890435/page-186#post-27445222
There are plenty of cMP 1,1 user still around.
Could you please point to exact binary in 10.14.5 to use popcnt ?
I have searched with otool -Vvt binary | grep popcnt
and haven't found in kext/opengl/metal
Thanks!
Sorry, I misspoke earlier (too many windows open at once) - the only AMD binary I've found that uses popcnt is AMDSharedIL (/S*/L*/E*/AMDShared.bundle). This is the same in High Sierra. The other drivers (AMDRadeonX3000GLDriver, AMDRadeonX4000GLDriver, AMDRadeonX5000GLDriver, AMDRadeonX5000MTLDriver, AMDMTLBronzeDriver) all use pcmpgtq. (Note that I haven't looked at everything, those are just what I've encountered so far.) (Also note: I'm at 10.14.3, but IIRC, every 10.14.0-10.14.3 I've looked at so far has shown the same thing. I can't speak directly re 10.14.5, though. Also, all but AMDRadeonX5000MTLDriver use pcmpgtq in High Sierra as well.)
you can install the legacy video patch from your usb Mojave patcher boot into it then click on post install select it from the list
im do it but went the system boots up the app notify me there's a update
maybe reinstall the patch updater from the post install then try the legacy patch update after booting back into your desktop
Ok i go to do that.
[doublepost=1560125336][/doublepost]thank you now all work well.
Interesting, I should open my machine and check that.
Ah great, I found it in AMDSharedIL
strange enough I haven't had a crash on rx560 due to this
strange enough I haven't had a crash on rx560 due to this
Code:
00000000000439bc popcntq %rax, %rax
00000000000439e8 popcntq (%rcx), %rsi
0000000000043a21 popcntq %rdx, %rcx
0000000000065793 popcntq %rax, %rax
00000000000657bf popcntq (%rcx), %rsi
00000000000657f8 popcntq %rdx, %rcx
000000000006f3a7 popcntq (%r15,%rcx,8), %rdxSee page #1 for details.
Works fine, depending mainly on GPU(s).
Well I got an i5 MBP mid 2010 and the last time I tested (before .4) all was working fine with general slowness. Anyone has tested it on latest versions?
If the 2010 with i5 is not up to your performance expectations, there must be something wrong on your individual system. Low RAM, HDD instead of SSD, or some additional quirky software installations perhaps. Make sure that graphics accel. really works. After spotlight indexing is done, Mojave runs as fast as (High)Sierra did, from C2D systems upwards...
Perhaps you should complain to General Patton instead of General Slowness? ;-)
I think that it was a problem due to graphics accel.
Intel hd graphics works as expected, but I think the Nvidia card Is making troubles when I open apps like Spotify that need graphics accel.
Later I'll test the new version, but how to make sure that graphics acceleration works for both cards?
A sure way to tell if accel works on any GPU is to see if you get opacity on the finder (side bar, dock, window panes etc.). If not accelerated, you get solid black or white surfaces there.
In addition to the energy saver system settings (where you can specify to always use the more powerful GPU if you have two in your system) there are good tools like gfxCardStatus to set this permanently or switch on the fly.