I am not able to find the set advertising interval errors in the logs collected for running MT in 1+ week. If anyone happens to encounter this error, would you please attach the /var/log/messages and ui.LATEST? (Please enable bluetoothd debug log in your testing.) Thanks!

Re C#0: 

> "The end result is that Instant Tethering becomes disabled and does not work until you power cycle your machine."

Hi Kyle, if setting advertising interval failed, the adapter would just use the default advertising interval which is 1,280 ms. Although slower, it could still perform advertising tasks.

I suspect that you encountered a "controller lost" issue in the very beginning. Since the controller was down, it was not able to take any advertising command which was reasonable.

Next time, please keep the /var/log/messages, and we could check whether the adapter is turned off before the advertising interval command is issued. Thanks!

I have not reproduced this issue with Joseph's patches. I think they may have solved the issue.

Re: comment #3: We've tried using Instant Tethering with the default advertising interval and found that we could not reliably form connections. That's why we disable the feature for devices which cannot set the advertising interval.

c#4: Kyle, hmm, why would using default advertising internal have an impact on the reliability of forming connections?  Can you provide more details on what the unreliability here is?

Removing RBS as well as M62 labels since the issue is not reproducible currently. Lets close it out in couple of weeks if we still can't repro it.

To clarify, I meant that the Android device could not scan the advertisement consistently when we do not set the advertising interval. (Sorry - the "connection" phrasing was unclear.)

Agree with Sameer that we should close the bug out if we can no longer repro the issue after Joseph's patches.

Kyle, you are right that if the advertising interval is long such as 1,280 ms, other devices may have a hard time to scan the its advertisements consistently. This is especially true when there are many bluetooth devices in an area.  It is not uncommon for a device to take 30 - 60 secs to find a target device.

However, looking at btmon logs collected for MT, it shows that SetAdvertisingInterval is performed in the very beginning of the tethering procedure before advertising and scanning start. Hence, the advertising patches may not actually help in this regard.

If the controller lost issue occurs in the beginning of tethering, you would see the SetAdvertisingInterval error.  

If the controller lost issue occurs in the middle of tethering, you would see the advertisement registration errors.

Let's wait for a while and maybe close it; or collect logs should it occur again.

Closing this bug out. I haven't been seeing it ever since Joseph landed his advertising fixes.