I have a Yosemite VM running in VB 5.2.6 under macOS 10.13.3 on a 2017 5K iMac (i5)
In Settings/General/Basic when I set the Version of the VM to "MacOS X 10.10 Yosemite (64-bit)" I get a critical error 'Guru Meditation' on starting the machine.
If reset the Version to 'Mac OS X (64-bit)', i.e. generic, the machine will start normally.
Config and Log for the first case attached.
Critical Error Exception
-
- Volunteer
- Posts: 704
- Joined: 3. Mar 2015, 07:27
- Primary OS: Mac OS X other
- VBox Version: OSE other
- Guest OSses: Linux, macOS, Windows
Critical Error Exception
- Attachments
-
- Yosemite.vbox.zip
- Configuration
- (2.02 KiB) Downloaded 62 times
-
- VBox.log.zip
- Log
- (63.64 KiB) Downloaded 51 times
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Critical Error Exception
Try with 1 CPU. 10.10 is really sensitive and not cooperating at all. It's a real pain if you have to work with it. Random crashes, non-cooperating graphics, bad audio, not really SMP... horrible.<CPU count="3">
This is one of the cases that I've used snapshots at its max. Take a snapshot:
- Launch 10.10, if it works, adjust a couple of settings, shut it down, take a snapshot, delete the previous one.
- Launch 10.10, if it doesn't work, revert to the previous snapshot.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Volunteer
- Posts: 704
- Joined: 3. Mar 2015, 07:27
- Primary OS: Mac OS X other
- VBox Version: OSE other
- Guest OSses: Linux, macOS, Windows
Re: Critical Error Exception
I did play with all sorts of settings before I thought about changing the version (number of CPUs, amount of RAM, amount of VideoRAM, hardware acceleration, 3D graphics etc), changing one variable at a time and a lot of rinsing/repeatingsocratis wrote: This is one of the cases that I've used snapshots at its max. Take a snapshot:Rinse and repeat.
- Launch 10.10, if it works, adjust a couple of settings, shut it down, take a snapshot, delete the previous one.
- Launch 10.10, if it doesn't work, revert to the previous snapshot.
I guess I am not sure what benefit I get from setting the VM Version to other than generic. When I isolated the problem to being the Version I was happy - I now have a working VM that enables me to do the backward compatibility tests I need to do on my software (compiled on 10.13.3 for 10.10 onwards) but I guess I'm missing out on some optimisation that the OS Version enables. Until now, I had thought it was just a descriptive label, but apparently not.
Maybe this trick might help anyone else who encounters a similar problem, so I posted here to make sure there is a record of what I found.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Critical Error Exception
Same here... Could you do me a favor and post a VBox.log.ZIP from a run with the template set to the generic "OSX" instead of the "10.10"? I want to see what's different between them during runtime. Just launch the VM, login, shut it down. Post the log...granada29 wrote:Until now, I had thought it was just a descriptive label, but apparently not.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Volunteer
- Posts: 704
- Joined: 3. Mar 2015, 07:27
- Primary OS: Mac OS X other
- VBox Version: OSE other
- Guest OSses: Linux, macOS, Windows
Re: Critical Error Exception
VB Config and Log for installed OS X 10.10, with Version MacOS X (64-bit) attached.socratis wrote:Could you do me a favor and post a VBox.log.ZIP from a run with the template set to the generic "OSX" instead of the "10.10"? I want to see what's different between them during runtime. Just launch the VM, login, shut it down. Post the log...
- Attachments
-
- Yosemite.vbox.zip
- Config
- (2.02 KiB) Downloaded 54 times
-
- VBox.log.zip
- Log
- (31.02 KiB) Downloaded 54 times
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Critical Error Exception
Excellent! Thank you...
Now to the diffs between the two runs. The red ones are the "10.10" ones, the rest are the "generic" ones. The first two entries do not exist in the "10.10" run:
After a little bit of search, that is indeed the case for guests up to 10.9. The "culprit" is at '/src/VBox/Main/src-client/ConsoleImpl2.cpp'. Pay closer attention to the comments:
Apparently this needs to be updated. There's also a ticket, #13118: Presenting compatible CPU architecture to Mac OS X guest VMs, which was closed as obsolete (and which I just re-opened), both for your crash, and for the fact that if I don't set the following for my 10.5 and 10.6 clients, they crash as well. You might want to do the same for your 10.10 guest:
Now to the diffs between the two runs. The red ones are the "10.10" ones, the rest are the "generic" ones. The first two entries do not exist in the "10.10" run:
I think I know where this is going... faking the CPU.00:00:02.606124 MaxIntelFamilyModelStep <integer> = 0x0000000000061701 (399 105) ... 00:00:02.614165 CPU: CPUID(0).EAX 0x906e9 -> 0x10671 (uMaxIntelFamilyModelStep=0x61701, uCurIntelFamilyModelStep=0x69e09 ... 00:00:02.628081 IEM: TargetCpu=CURRENT, Microarch=Intel_Core2_Penryn 00:00:01.555697 IEM: TargetCpu=CURRENT, Microarch=Intel_Core7_KabyLake ... 00:00:02.814622 Model: 7 Extended: 1 Effective: 23 00:00:02.814623 Stepping: 1 00:00:01.670271 Model: 14 Extended: 9 Effective: 158 00:00:01.670272 Stepping: 9
After a little bit of search, that is indeed the case for guests up to 10.9. The "culprit" is at '/src/VBox/Main/src-client/ConsoleImpl2.cpp'. Pay closer attention to the comments:
[quote] if (fOsXGuest) { /* Expose extended MWAIT features to Mac OS X guests. */ LogRel(("Using MWAIT extensions\n")); InsertConfigInteger(pIsaExts, "MWaitExtensions", true); /* Fake the CPU family/model so the guest works. This is partly because older mac releases really doesn't work on newer cpus, and partly because mac os x expects more from systems with newer cpus (MSRs, power features, whatever). */ uint32_t uMaxIntelFamilyModelStep = UINT32_MAX; if ( osTypeId == "MacOS" || osTypeId == "MacOS_64") uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482. */ else if ( osTypeId == "MacOS106" || osTypeId == "MacOS106_64") uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ else if ( osTypeId == "MacOS107" || osTypeId == "MacOS107_64") uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out what is required here. */ else if ( osTypeId == "MacOS108" || osTypeId == "MacOS108_64") uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out what is required here. */ else if ( osTypeId == "MacOS109" || osTypeId == "MacOS109_64") uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out what is required here. */ if (uMaxIntelFamilyModelStep != UINT32_MAX) InsertConfigInteger(pCPUM, "MaxIntelFamilyModelStep", uMaxIntelFamilyModelStep); } [/quote]which pretty much, and in conjunction with your VBox.log, tells me that if you set the template to "OSX" your CPU is presented as a Xeon "Harpertown" X5482, whereas if you set the template to "OSX 10.10" your i5-7600 is presented unfiltered.
Apparently this needs to be updated. There's also a ticket, #13118: Presenting compatible CPU architecture to Mac OS X guest VMs, which was closed as obsolete (and which I just re-opened), both for your crash, and for the fact that if I don't set the following for my 10.5 and 10.6 clients, they crash as well. You might want to do the same for your 10.10 guest:
VBoxManage modifyvm "Mac OSX 10.6" --cpu-profile "Intel Core i7-6700K"
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Volunteer
- Posts: 704
- Joined: 3. Mar 2015, 07:27
- Primary OS: Mac OS X other
- VBox Version: OSE other
- Guest OSses: Linux, macOS, Windows
Re: Critical Error Exception
Mystery solved. Thanks for reopening the bug. Hopefully it will be fixed at some date.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Critical Error Exception
I managed to get a hold of a couple of developers over IRC and here's the summary:
- That part of the code is indeed what makes your guest work/crash depending on the template chosen. That piece of code is a "hack", at best.
- The "--cpu-profile" is much more robust because it includes a complete profile of the CPU, not just the stepping family (that's the "hack" part). But the CPU profile was added at a much later time, most probably to address inefficiencies in the family model.
- They know about it and they're thinking of the best forward-looking implementation. From exposing the CPU as a GUI option (my idea, really dangerous) to changing it depending on the template, to...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Volunteer
- Posts: 704
- Joined: 3. Mar 2015, 07:27
- Primary OS: Mac OS X other
- VBox Version: OSE other
- Guest OSses: Linux, macOS, Windows
Re: Critical Error Exception
I would be happy with using --cpu-profile if I knew what the appropriate value is for each release of MacOS X, macOS. Possibly a table as an expansion of the documentation in Section 9 of the Help manual.
Or maybe thats what the effect of setting the OS version in system settings should be - i.e. don't just patch a few instructions but set the appropriate cpu-profile (but also continue to allow it be over-ridden through VBoxManage for the experimenters amongst us)
I'm glad to hear that the developers are looking at the issue and hopefully they will come up with a robust solution that takes into account these factors.
Or maybe thats what the effect of setting the OS version in system settings should be - i.e. don't just patch a few instructions but set the appropriate cpu-profile (but also continue to allow it be over-ridden through VBoxManage for the experimenters amongst us)
I'm glad to hear that the developers are looking at the issue and hopefully they will come up with a robust solution that takes into account these factors.