For months - since perhaps June or July - my MacBook Air has sometimes taken over a minute to fully awaken from sleep. It quickly puts up the password box, but then takes a very long time to enter a usable state. I've finally found the cause: The Parallels-hosted virtual drive isn't ready. Take a look at this portion of the kernel log - it's spending 90 seconds on that, all of it before giving the user control. That path (Win7-64) is the "device name" in Finder under the Computer name of the Windows C: drive. So there's no doubt the start-up is waiting on Parallels. And of course this file is on the internal SSD; it doesn't cease to be present. It's at file://localhost/Volumes/C/ according to Finder's Info. Other than exiting Parallels before sleeping, how can I prevent this slowdown? Thanks. Nov 24 06:40:07 TMacAir kernel[0]: AFP_VFS afpfs_DoReconnect: get the reconnect token Nov 24 06:40:17 TMacAir kernel[0]: add_fsevent: unable to get path for vp 0xffffff800e655aa8 (Win7-64-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds; ret 22; type 2) Nov 24 06:40:17 TMacAir kernel[0]: add_fsevent: unabled to get a path for vp 0xffffff800e655aa8. dropping the event. Nov 24 06:40:30 TMacAir kernel[0]: add_fsevent: unable to get path for vp 0xffffff800e655aa8 (Win7-64-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds; ret 22; type 2) Nov 24 06:40:30 TMacAir kernel[0]: add_fsevent: unabled to get a path for vp 0xffffff800e655aa8. dropping the event. Nov 24 06:40:44 TMacAir kernel[0]: add_fsevent: unable to get path for vp 0xffffff800e655aa8 (Win7-64-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds; ret 22; type 2) Nov 24 06:40:44 TMacAir kernel[0]: add_fsevent: unabled to get a path for vp 0xffffff800e655aa8. dropping the event. Nov 24 06:40:57 TMacAir kernel[0]: en0: 802.11d country code set to 'US'. Nov 24 06:40:57 TMacAir kernel[0]: en0: Supported channels 1 2 3 4 5 6 7 8 9 10 11 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140 149 153 157 161 165 Nov 24 06:41:54 TMacAir kernel[0]: add_fsevent: unable to get path for vp 0xffffff800e655aa8 (Win7-64-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds; ret 22; type 2) Nov 24 06:41:54 TMacAir kernel[0]: add_fsevent: unabled to get a path for vp 0xffffff800e655aa8. dropping the event. Nov 24 06:42:04 TMacAir kernel[0]: nspace-handler-set-snapshot-time: 1353768125 Nov 24 06:42:14 TMacAir kernel[0]: add_fsevent: unable to get path for vp 0xffffff800e655aa8 (Win7-64-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds; ret 22; type 2) Nov 24 06:42:14 TMacAir kernel[0]: add_fsevent: unabled to get a path for vp 0xffffff800e655aa8. dropping the event. Nov 24 06:42:35 TMacAir kernel[0]: CODE SIGNING: cs_invalid_page(0x1000): p=42338[GoogleSoftwareUp] clearing CS_VALID
Unhelpful Parallels Support So I wound up getting a call from Parallels after registering this as an issue. They -know- about it. And can only suggest disabling sharing of the Windows disk. Even with the [Configure] - [Sharing] - [Share Windows][Access Windows Folders From Mac] option unchecked (and everything rebooted), I still get up to two minutes of... Dec 15 05:49:49 TMacAir kernel[0]: add_fsevent: unable to get path for vp 0xffffff8012523e88 (Win7-64-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds; ret 22; type 2) Dec 15 05:49:49 TMacAir kernel[0]: add_fsevent: unabled to get a path for vp 0xffffff8012523e88. dropping the event. In the Kernel log at boot, when it stops resume. This is with Build 8.0.18314 (Revision 813278; October 31, 2012) I am seriously appalled that Parallels doesn't have a solution to a problem they create, that I've given them good detail and can easily reproduce on!
