Mac Freeze on launching VM

Best of both worlds

If you also want to use some new features with 4560, and you have the kernel panics, and upgrading firmware did not work, here:

- Install 4128
- Backup /System/Library/Extensions/vmmain.kext
- Backup "/Applications/Parallels/Parallels Desktop.app"
- Install 4560 (you can uninstall 4128 first)
- Replace the vmmain.kext 4560 version by the 4128 version
- Show package content of "Parallels Desktop.app"
- Navigate in to Contents > MacOS and replace Parallels in it by the 4128 one
- Delete Extensions.kextcache and Extensions.mkext in /System/Library/Extensions/
- Repair permissions on the drive using Disk Utility
- Reboot
That's it, you have a 4128 version with most 4560 extras (it will even allow you to install the 4560 Parallels tool).
It worked for me...
The culprit is really vmmain.kext and its interaction with the binary Parallels.
Instead of bashing (and ducking), it will be more agreeable if we look for solutions together.

 

Do you guys possess real Mac computers?

I don't find a "firmware update option". Software Update shows only if there is something new or not, and in my case it's "not", because my machine anyway runs a daily automated software update.

How can I get to this "firmware update option"?

EDIT:

After further checking into the matter I get the impression that at least some Parallels folks appear not to know a Mac. At least the above firmware update suggestion doesn't make sense.

I've always stood at the defending side, but now I start to deem it possible that the Parallels organization really is not up to the job.

 

Yes, this trick is also OK, thank you for posting it.

I mean the following; note selected item ("Mac mini EFI Firmware Update"):



If you do not have an option like this try downgrading to build 4128 or trick described by bgrau2020.

 

I don't have this firmware option, because my Mac Mini has the actual firmware. So your conclusion that upgrading to this EFI version should make 4560 work appears to be wrong, and instead the reason for the kernel panic is something different. I thought Parallels had better knowledge.

Downgrading to 4128 makes me lose features I want.

The "trick" from bgrau2020 may or may not provide a solution. But because it's complicated, and after your firmware recommendation I have lost some trust in whether Parallels knows what's going on, I don't want to enter endless experimentation.

I'm way too old for wanting to be in a software boy scout camp...

 

Pretty lame response. This is not a firmware issue. The machine that I am having the issue with is entirely up to date as far as firmware is concerned. BTW you can check your firmware version against Apple's listing for latest versions here:

http://docs.info.apple.com/article.html?artnum=303880

You ie. Parallels also made no mention of when a real fix will be posted...

Obviously not...sigh

come on guys get it together

cheers

Rev Bem

 

Looking at your panic.log would help me very much. For now I've seen logs only from Butti and al3. Also, does putting Mac to sleep and waking it up before starting Parallels help avoid kernel panic?

 

1. According to the below quoted post, one of your own staff members has stated that the problem has been identified and a fix will be posted (no fix posted as of yet, so this is not true then?)

2. If you bothered to read this entire thread you would have seen this and would have answered your own question regarding the effect, or lack thereof of sleeping the mini prior to launching Parallels:

So what is the story here? Either you have identified the issue and can fix it or you haven't and can't.

Rev Bem

 

I fully second rev_bem's complaint!

Of course I would be prepaired to provide a panic.log or whatever is considered helpful, but I want to see my contributions to go into an organized process, and not into sort of a dark hole with unpredictable behavior and no responses.

The present outside impression - no special offense intended - is unfortunately more that of a software kindergarden or at best a software boy scout camp, instead that of a software company with predictable and understandable (to the outside) processes.

So please help to overcome this impression by giving at least some information on
a) how you assess the situation,
b) what you intend to do,
c) what you want from us as supportive contribution.

 

I can't resist the temptation to complete the picture. I see 4 main possibilities, because they may:
1. have identified the issue and can fix it. Then they should tell us when they intend to do so.
2. have identified the issue and can't fix it. This can happen, but then they should tell us and give an indication how big the obstacles are and when they see a potential chance to overcome them.
3. have not identified the issue and therefore obviously can't fix it, but would be interested in better identification and are working on it. Again then they should tell us and maybe ask us for further contributions for helping them to potentially identify the issue.
4. have not identified the issue and at present also don't intend to provide the resources for this. Then again they should tell us. Some may yell, but it would be fair enough.

 

I'm waiting too. same problem. I have tried at least a dozen times to resolve this.

 

OK, let's clarify the situation with this kernel panic. We managed to reproduce a kernel panic on build 4560 with exactly the same symptoms that I can see in the two panic logs posted in this thread. This bug is fixed and our support provides a hot-fix build to those customers that experience this kernel panic. I'll ask support team to post link to the update in this thread. This is not beta, it's official update distributed by request.

The bug is connected with VT-x support in driver and occurs on Macs that have VT-x locked by firmware. Updating firmware or putting Mac to sleep are of course not fixes but workarounds that can help avoid this kernel panic until you install the update.

Again, please show me your panic.log.

 

Guys,

Here is the link to download the new build that should fix the kernel panics - http://download.parallels.com/v3/en/GA/Parallels Desktop 4562 Mac en.dmg.
Please mind that this build doesn't contain any other changes or improvements except solving KP issue on Mac Minis, so you should install it only if you are experiencing such problem. Otherwise it's recommended to wait for the next regular update for Parallels Desktop 3.0.

 

Thanks - works nice like mint

 

Did you uninstall 4560 first, or did you just install new build over it?

Al

 

This is how the communication should be. Why not this way right from the beginning?

Anyway, better now than never ;-)

I installed 4562 over 4560 on my Mac Mini and everything works fine again.

 

Thanks. I won't get to it until this afternoon (PDT), but will report back as soon as I know something.

Send me your prayers!

Al

 

Hmmm. When I try to run 4562 installer it asks which application should be used to open it, then it starts Parallels and then shuts it back down. Using Get Info on the installer it shows Parallels Desktop as the app to open the installer with. Can't discount operator error somewhere along the line--any thoughts or recommendations?

 

is the fix also encorporated into the v.5060 release?

cheers

Rev Bem

 

If I may ask: what are you talking about?

 

This is exactly what I thought. The right way to handle this situation would've been as simple as providing two pieces of information. 1: We do see that there may be a serious problem on some machines. Please revert to build 4128 until further notice. 2: We're working on this.

Cheers, Uli