iMac 2014 5K Bluetooth Trackpad Problem after sleep

If you wanted to try that - the systems aren't locked down, and you can sleep them, restart, turn off.

I will be near a store on tuesday and will give it a try as well.

Hm..

I may still have a bootable backup of my former 10.9.x systems I will try. Also used CC though, so if yours did not work I assume I'll have the same trouble and the 5k firmware may just need 10.10....

I would by the way assume that all 5k have the potential of being affected, since the broadcom chip is universal throughout. Is everyone on this thread utilizing 802.11ac wireless? Or everyone on 5Ghz (n, ac)? Just wondering.

Upsetting as this is, seems pretty clear that it's something fixable in software, since we can all circumvent the issue via the 'power button' wake.

cheers

d

all, just want to give an update of my debug and call to tech support.

I have been doing testing hours today, and I am not happy to found what I observed. After waiting for a hour to finally get through to a live tech support, I pointed her to this thread. To her credit she have read it. I believe she was able to pull it up because I added the link to Apple Feedback of the 5k iMac purchase. She is one of the best tech support I had talked to in terms of being patient and empathy. With a lot of misgiving, In her insistence I let her walk me thru the process of deleting the files in the Caches folders, shut down, and then restart. This time I wanted to give ample time for the system to enter deep sleep before restarting. We waited 5 min. We tested twice during the call. In both cases both KB and mouse didn't fail upon resume. We agreed to have an Apple tech support to make a follow up call 45 min later so I can continue to do more tests to confirm it is fixed.

The first test I did after the all immediately failed when I wake with the mouse. In the ensuring rest of the day I performed 16 test cycles. most of the test with 5 min of sleep, and 3 with 10 min. The failure was no longer 100% reproducible. 6 failures out of 16 test cycles. My last test I thought that may be there is a magic window instead of my original thinking of longer in sleep the better. I changed the sleep time to 4 min this time. I then woke it with a press of the space bar of the KB and this time failed!

I am suspicious if this magic window of failure does exist, it is very much the function of the system in which what processes/programs needs to be restore upon resume from sleep. These variables must affect the timing of the SW gets to reconfigure/resume the BT host controller and the KB and Mouse/touchpad.

In summary, the biggest finding I have in today's tests is it is no longer 100% repeatable. If this is true, a lot of 5k users may take time before they realize this.

Thanks. I do think this is still fairly consistent with the finding that the system has to wake from deep sleep. There a number of levels of sleep and it would appear that deep sleep is followed by wake that does not properly initialize the BT module. If you have 'nap' in by the way, the system doesn't fully wake and I suspect never initializes BT and other modules at all.

I Think that if you check your console log and BT diagnostics you may find the inconsistencies connected to sleep levels, but just s hunch.

SUpport is bit not going to be able to solve this unless they have a KB in their systems other than by luck. The more users open a case however, the better chance this will be picked up by the dev team quickly. Apple bug reporter is a direct line to them if you have access.

Nire it sure we can hope for a real quick fix as so far no test build of 10.10.1 has been released to developers yet...

thx hx for testing and posting!

I have been following a few well known tech bloggers and SW developers who I know ordered the 5k with high spec. One is Marco at marco.org who is a part of ATP podcast. He has 2 ordered but have not yet receive due to the slow business discount he order thru. The other is John Gruber of Daring Fireball. He hasn't written about his first experience of his 5k so I assume he has not receive his either.

In my most recent test cycle after the failure. I restarted the system. When the log in screen appears the mouse pointer did not move. I waited nearly 10 sec to see what happen, and it did not come alive. As the cursor is not in the password field, i have to click the mouse once to start it. While I was writing down what transpired on my paper notepad before logging into the system, a small pop up says the mouse is disconnected. Moments later another pop up says the mouse is connected. I logged in and the kb and mouse are fine. I started typing this post.

In my previous professional life, I had done a lot of debugs of this sort on Windows PC affecting major OEMs and manufacturing line down situations. Our efforts involving a team of trouble shooters. Have seen similar issues like this often involving SW timing in re-initialize the h/w upon resume. I concur that Apple really need to step up their resource and effort in compatibility and pre-release testing. Unlike microsoft, in which the permutations of the h/w and s/w is virtually infinite, Apple has a much easier job.

i think dev team (or senior support team) may have realized the problem. i chatted with apple care the other day, they have no idea what was going on except ask me to reset smc and reinstall the system (and things like that). in the end she told me to bring the device to a local store.

BUT, BUT, BUT, on saturday (and friday i believe since i did get a missed call from apple), a senior technician called me and asked about the situation, and asked for some log/diag files. i also gave him a short video i took about this issue. so i believe apple may have realized this problem already and working on it. lets just hope things goes well.

BTW, is there anyone who solved this problem via exchange?

I want to clarify my observations with the series of tests and the result I reported above in the attempt to characterize the failures. Because to replicate the failure involves putting the system into sleep, and the realization that there are not just one sleep state, but rather a few I have to decide on what is a shortest duration that I can replicate the failure. Unlike Windows PC Apple's computers (mac, iPhone, iPad etc) are designed to hide these complexity from the user. Without resort to or access to special debugging tools I have to experiment and find emperically the adequate sleep duration that the system reaches deep sleep. Our observation is only if we wake the system with a bluetooth human interface devices the failure occur.

My choice of the duration of approximately 4 min or more was based on my initial experience when the failure was readily reproducible and this is also not exceeding long to use during a tech support phone call. Unfortunately as I would later find out after hours of test cycles that the time it take for the system to reach deep sleep is very variable (I have some insight to the countless factors that contributes to this varied duration but would be too complex for this post). I have observed failure after system is put to sleep as long as 10 min. In two tech support calls now, the tech patiently waited for my to confirm if the issue has been fix with 2 test cycles after their different steps to reset some stored system parameters. While I warned them that the limitation of time during the call, we need to be careful to interpret the "good" test result during the call. Sure enough after both calls I was able to replicate the failure.

I decide to length the sleep duration to 20 - 30 min. With this duration the failure is 100% reproducible. So for the record, my system still readily fails in a normal use of sleep.

i am at my local store right now. it has a low spec basic model with a touchpad. I did one test of 10 min sleep and it did not fail

i now suspect that the failure may be masked her by all the stray BT and wifi signal around

not hoprful able to replicate here

I did another test of 20 min of sleep. I woke it up with a click on he touch pad and it did't fail. I was expecting it.

I am home now. they only has one machine and I feel guilty hogging it for testing. I underlined the difference from yours. To my new to mac eyes, the one that may be significant is sleep = 0 instead of yours 1 (updated 1:45pm)

here is the pmset parameters

Active Profiles:

AC Power -1*

Currently in use:

standby 1

Sleep On Power Button 1

womp 1

halfdim 1

hibernatefile /var/vm/sleepimage

gpuswitch 2

darkwakes 1

autorestart 1

networkoversleep 0

disksleep 10

sleep 0

autopoweroffdelay 14400

hibernatemode 0

autopoweroff 1

ttyskeepawake 1

displaysleep 0

standbydelay 10800

OK. I just read up online of the sleep = parameter:

sleep - system sleep timer (value in minutes, or 0 to disable)

I think this just so that the display systems don't nap off when on one play with it after a while.

My contention is in the presence of a lot of BT or may be even wifi 2.4GHz stay signal, the host's BT controller and/or the KB/mouse never goes into the low power stage as in our home. The failure may only occur with this very low power state (in which the HID devices still must be ready, or continue to communicate with the host)

In my many test cycles yesterday I unwittingly have my monaural BT headset switch on and placed nearby because I was calling the tech support.

Yes, I hear you and in agreement. Most often the difficult problem is to convince the dev or sustain team the problem exist and is real. They are like NSA, way too much noise to see the real weak signal.