Bluetooth drivers prevent system from sleeping in Mavericks - what's going on!?

I wish it was was Google Chrome causing the issue for me - I've never used or installed Google Chrome, so it's definately something else for me!

On a side note - I used the power button to send my MBP to sleep a few days ago with Wi-Fi connected (usually I always turn off Wi-Fi) and a couple of Safari windows open, and I noticed the sleep indicator light staying on for even longer than before. I hit spacebar to see if it would wake up and it didn't, the sleep indicator light just stayed on constant. Then the computer just crashed and restarted itself. When it came back on there was an error message along the lines of:

'There was a problem with the sleep / wake function...' blahblahblah - yea you don't say!

And it asked me to submit the error report to Apple, which I did. It's only happened once, but there is blatantly some sort of bug with sleep mode!

I had the problem with Chrome when I was with SL. But I could see that Chrome was the cause in the pmset log.

Now it's different, even with no application running, the sleep mode is very slow.

How did you "kill" Chrome? Just quit it or something more? Because for me it's ~40 seconds regardless of Chrome's running or not.

Just a regular Command+Q to quit. I've discovered that I can get a quick sleep when Chrome has just been started too - but once it's been running for afew min, I'm back to long waits.

Anyway, I'll stop this Chrome talk now so as to avoid hijacking the thread that clearly relates to the other root cause.

Hi everybody,

I can confirm I have the same problem with sleepmode.

UserIsActive 1

pid 78(hidd): [0x0000000a0000016b] 00:15:48 UserIsActive named: "com.apple.iohideventsystem.queue.tickle"

Timeout will fire in 876 secs Action=TimeoutActionRelease

My System is Mavericks 10.9, MacbookPro Retina 15.4, 16GB RAM, 512 GB SSD, Model Early 2013.

I just found something out:

Could it be that it has something to do with the screensaver?

When I killed the process 78 with "sudo kill 78" my Screensaver started loading pictures again. Before that the screensaver hang with the message "Loading Fotos". At least it loaded the ones from National Geographic but not the ones from my Aperture Library.

So at least one problem (Screensaver) solved half...

By the way: After killing the process it does take only second before a new hidd process pops up again and "UserIsActive 1" status reappears.

I appreciate all the efforts of the community and I am looking forward to a solution.

Regards

Same problem here 😟

Sleep worked perfectly fine in 10.8 and 10.7. Even works in Windows 8 Bootcamp right now. I hope Apple fixes this in 10.9.1

Assertion status system-wide:

BackgroundTask 0

PreventDiskIdle 0

ApplePushServiceTask 1

UserIsActive 1

PreventUserIdleDisplaySleep 0

InteractivePushServiceTask 0

PreventSystemSleep 0

ExternalMedia 0

PreventUserIdleSystemSleep 0

NetworkClientActive 0

Listed by owning process:

pid 48(hidd): [0x0000000a00000312] 08:11:09 UserIsActive named: "com.apple.iohideventsystem.queue.tickle"

Timeout will fire in 3583 secs Action=TimeoutActionRelease

pid 61(apsd): [0x0000000b00000446] 00:00:23 InteractivePushServiceTask named: "com.apple.apsd-connectionestablish-push.apple.com"

pid 183(ubd): [0x0000000c00000185] 09:06:42 ApplePushServiceTask named: "com.apple.ubiquity.push"

Kernel Assertions: 0x8=BT-HID

id=504 level=255 0x8=BT-HID mod=01/01/1970 5:00 am description=com.apple.driver.IOBluetoothHIDDriver owner=BNBMouseDevice

Thanks for the post. I'm really hoping that apple fixes this in 10.9.1.

Any developers out there who have downloaded 10.9.1? Can you tell us if this is fixed or not??

10.9.1 is out.

Problem has been fixed? 😕

No. 😟

Maybe it's the normal behavior... A friend of mine with a MacBook Air has the same log with "pmset -g assertions", but the sleep is very quick for him.

With Mavericks, the RAM management seems very different, all the memory is allocated by default, even if not needed by the apps. So when the computer goes to sleep mode and all the memory is copied to the hard drive, it takes much more time than before. If you have not much memory, or a very quick drive like SSD, you don't notice.

I am not sure of that, just wondering...

@Keumar

That can't be correct, as safe sleep / hibernation is off on my macbook pro, as stated before.

@Dan850

Interesting, I haven't seen that "InternalPreventSleep" line before.

I'm having this same problem, late 2011 MBP 8gigs ram, 500 gig HDD etc. etc. etc...

Appears to have something to do with the amount of Data Mavericks is now stoing in the Ram, if i change my hibernate "mode" through the terminal from the standard "safe sleep" that MBP's have, to the setting where it writes nothing to the HD, it goes to sleep in about 4 seconds.

If i leave the MBP in the hibernation mode that MBP's normally use (Safe sleep: takes time to write all the data from the ram to the HD) it takes upwards of 45 to 60 seconds.

I have no idea how the time it takes to write the information changed so drasticly from ML to Mavericks, but it did somehow. I never had an issue with SL or ML and now all of a sudden (on the exact same harddrive, with the same amount of RAM, mind you) it takes forever to write the info..

It might have something to do with how mavericks uses RAM, which coul be effected by the Energy saver properties Mavericks has.

All i know for sure is that I'm super close to putting ML back on this thing, Cause i move around to much to sit and wait for my computer to hopefully sleep. and i need information too fast to wait for it to start up all the time.

@AJ Soares

How exactly did you change your hibernate "mode" through the terminal to the setting where it writes nothing to the HD?

AFAIK my safe sleep is off, yet going to sleep still takes ~40s. (8 GB RAM, SSD)

Why is this issue marked as solved? What is the solution?

I have this problem since october and it driving me crazy.

Has anyone filled out a bug report? If so could you please post your bug report as a template so that everyone can fill it out easily and fast. Maybe with many bug reports Apple will finally take this bug seriously.