search

RehabMan / OS-X-BrcmPatchRAM

Broadcom PatchRAM driver for OS X
GNU General Public License v2.0
243 stars 47 forks source link

Intermittently no bluetooth after wake from sleep #2

Closed RehabMan closed 9 years ago

RehabMan commented 9 years ago

In some cases, the system doesn't tear down the USB tree on wake from sleep and as a result BrcmPatchRAM is not re-probed. This means the firmware is never loaded and the native personality for Broadcom bluetooth is never registered.

Result: no bluetooth after sleep.

Will try uploading firmware on power state change...

RehabMan commented 9 years ago

Loading firmware at power on is probably not workable. The code in setConfiguration fails when called directly from setPowerState (power up case). So... it would probably need to spin up another thread. But I'm concerned over conflicts for the case of reprobe (common case) if that thread is actively running (loading firmware) while the device is USB tree is torn down.

But it definitely is a rare case of the device not being re-probed.

Next attempt is to call IOService::terminate for self prior to entering sleep...

RehabMan commented 9 years ago

This is an intermittent problem and somewhat rare. But usually once per day...

I think the commit referenced above fixes it, but I'll leave this open until the fix is further "time tested"...

Meanwhile, I uploaded a build with this fix in it to butbucket.

RehabMan commented 9 years ago

So far so good. No case of non-working BT after sleep in 48+ hours.

RehabMan commented 9 years ago

This appears to be fixed.

RehabMan commented 9 years ago

I saw it happen one more time, although it is exceedingly rare.

I have some other ideas to try... will update this space as I make progress.

This problem is not new. It happens with the original as well. It could be something specific with my USB configuration.

RehabMan commented 9 years ago

Another instance of it today.

I'm going to start a one-shot watchdog timer on wake. The timer will be canceled by a ::stop. But if the timer expires, it means that there was no re-probe and so I'll spin up a thread to upload the firmware and re-register the native bluetooth personality.

Since it doesn't happen very often, it will take a while to verify the fix.

RehabMan commented 9 years ago

It is possible the missing mDevice->release in stop (to match retain in probe) could be the cause. Will not know for a while... testing this intermittent condition is a PITA.

RehabMan commented 9 years ago

I've removed the terminate() call from setPowerState. Testing is showing that it is not effective against this problem and is not needed. Commit 208a0cc7218ef51813dac30d0cbd3c40ffb21a8f.

It is looking more and more that the missing mDevice->release was the issue. That issue was fixed by commit 0c0fb4c6da61857255a59ce4019f05baa6a22c17.

RehabMan commented 9 years ago

I think this is finally fixed. Closing for now.

RehabMan commented 9 years ago

It happened again. Super annoying. Now back to testing branch: watchdog_threaded_firmware_upload

RehabMan commented 9 years ago

The workaround in the 'watchdog...' branch is working. I'll be able to tighten the timing a bit (I see max 104ms between setPowerState and probe in the normal case).

But in addition to that fix, I needed additional DSDT work to be sure the USB controller drivers were ready (Notify on _WAK). At this point, I have several changes I've made to the DSDT, so I also need to determine which ones are really necessary.

RehabMan commented 9 years ago

This is fixed.