Consistent wake problems on a MacBookPro

1.83ghz MBP, 1.5 gigs RAM, today's beta release of parallels for Mac. Mac OS X Version 10.4.6 (Build 8I1119), Firmware update that came with Bootcamp.

One virtual OS installed: Windows 2000, upgraded to SP4.

The MBP sleeps reliably, but if parallels is running, a wake gives a complete restart.

Are there any known steps to take to avoid this problem?

 

Same problem here on MBP 2 GHz.

 

same problem here on a MBP 2.0

 

Yup. Hosed up my workflow for the morning...

 

Yep, same problem here. MBP 2Gz, 2GB Mem.

 

Same here. But tis really rocks. Too bad I paid 40$ to M$ through our Universty bookstore for XP. All I need in win2k for which I already have a CD.

 

I'm experiencing the same problem, but with Windows XP. That said, this software is amazing. This is the only thing that would prevent me from plunking down $50 for this software today. In fact, if a purchase gave something like free updates for the next 6 months, I'm even ready to pay my $50 now, in the faith that this problem will be fixed. Awesome software at a fairly reasonable price.

 

I'm having the same issue as everyone else with my MBP not being able to wake without a full restart if Parallels is running. Hopefully we'll see another beta release soon addressing this one.

 

Same problems here. Windows XP on MBP 2Ghz. 1GB Ram.

I paused the VM last night and shut my MBP lid. Opened lid this morning and clicked on VM play button. MBP rebooted.

 

Same issue. Seems to be a bug. If I pause the VM, then it seems fine.

 

Yeah if you sleep the VM while it's running it will reboot when you wake up the system. Guess it's a bug, and I assume will be fixed in next release. I'm running both FreeBSD and Windows and they both have the same issue.

 

Same problem here.. MBP 2.0 Ghz...

 

I just tested this on my MBP and saw the same behavior. But, I don't quite think this is a bug, but a limitation--expected behavior.

When a VM is powered on, there are several files open and being written to on the guest side, and one file on the host side--the virtual hard drive. Pausing the VM keeps the VM from using CPU cycles, but it doesn't commit anything to disk. Closing the lid on my MBP suspends OSX, but a paused (or even running Windows Guest) has no idea how to handle having it's disk and other hardware pulled out from under it. Pressing resume chokes OS X because the virtual hard drive isn't in the exact state it was in when the guest was paused.

This is theory, of course. I could be wrong. I wonder how VMWare handles a similar situation with their product for Windows hosts.

 

Hello,

Guys, thanks for noticing that. That's our serious miss. Anyhow, we shouldn't cause any primary OS unexpected behavior as it happens in this case. This one will be addressed seriously and the final version will not cause restarts.

 

I don't know how they deal with it technically, only that it works great. Suspending a Windows laptop with a running VM suspends that too. When the box resumes, the VM chugs happily along as if nothing happened.

 

Nice.

And as Tim just posted, this is going to be addressed. Excellent.

 

Two Systems Down

My brother and I loaded up Parallels on each of our MacBook Pros yesterday. I noticed the reboot issue after resuming from sleep on mine yesterday. Then things got a little worse.

This morning when I woke themachine up (with Parallels still running - I hadn't known of the problem with sleep and Parallels yet) and tried to resume, the system rebooted and never came back up.

Booting into single user mode revealed that the Parallels problem had caused invalid sibling links in my filesystem. Disk utility was unable to fix these linkage errors. I am pursuing a copy of DiskWarrior to attempt to recover from this unfortunate Parallels problem. I am still unable to boot my Macbook.

My brother had the reboot problem and, though his machine is still booting, his disk has bad links also now. This is a pretty serious issue for Parallels, considering it compromises the integrity of the user's filesystem.

A beta version entails risk but it certainly shouldn't disable a system.

I suggest anyone who has had the reboot-after-sleep problem run a verification check with disk utility immediately. My guess is you have some system damage to deal with.

Systems Comrpomised (FIRMWARE UPDATED ON BOTH):
2.16 GHz Macbook Pro
2.0 GHz Macbook Pro

 

There's a reason it's called a beta!
Sigh,
David

 

Pausing the VM doesn't exactly work for me. That is, if the VM is paused, I don't get the reboot on wake from sleep. But if my MacBook has slept while the VM was paused, as soon as I un-pause, I get the reboot.

Is that the same for you?

 

Do you mean to suggest that it's somehow acceptable for a public beta to hose a filesystem? If this was a CVS snapshot then I might accept that as part of the equation (though even then it's pretty extreme).

Is that what the mac community is coming to? We take filesystem corruption from a public beta as just part of the package?

I think the Parallels developer, who said repeatedly that this is a very serious problem, would disagree with any notion that this is acceptable or part of the normal risk with beta software.

Parallels worked great for me until this unfortunate error occured. The speed, with virtualization, was phenomenal. I wish their crew the best in the future but I'm too gun-shy to risk my Macbook again (which, along with my brother's, is still being repaired by diskwarrior).