Hi Lukasz, On Wed, Dec 10, 2014 at 11:20 AM, Lukasz Rymanowski <lukasz.rymanowski@xxxxxxxxx> wrote: > Hi Luiz, > > On 10 December 2014 at 09:56, Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: >> Hi Lukasz, >> >> On Wed, Dec 10, 2014 at 10:53 AM, Lukasz Rymanowski >> <lukasz.rymanowski@xxxxxxxxx> wrote: >>> Hi Luiz, >>> >>> On 10 December 2014 at 09:46, Luiz Augusto von Dentz >>> <luiz.dentz@xxxxxxxxx> wrote: >>>> Hi Lukasz, >>>> >>>> On Wed, Dec 10, 2014 at 10:38 AM, Lukasz Rymanowski >>>> <lukasz.rymanowski@xxxxxxxxx> wrote: >>>>> Hi Luiz, >>>>> >>>>> On 10 December 2014 at 08:23, Luiz Augusto von Dentz >>>>> <luiz.dentz@xxxxxxxxx> wrote: >>>>>> Hi Lukasz, >>>>>> >>>>>> On Tue, Dec 9, 2014 at 5:11 PM, Lukasz Rymanowski >>>>>> <lukasz.rymanowski@xxxxxxxxx> wrote: >>>>>>> When testing HOG against PTS we got failing testes if devices were >>>>>>> not bonded before the test. >>>>>>> With those patches this issue is not valid anymore. >>>>>>> >>>>>>> This set address couple of issues: >>>>>>> * Some minor fixes found during work on those patches (first 4 patches) >>>>>>> >>>>>>> * Changed GATT behaviour during dedicated bonding. Now GATT will not start >>>>>>> search services until bonding is done. That fixes PTS connection issue >>>>>>> (patches 5-8) >>>>>>> >>>>>>> * Tracking of GATT operations in hog/dis/bas/scpp. After I solved PTS >>>>>>> connection issue I could very easily observe many of crashes in BfA when >>>>>>> disconnecting HOG during service search session. This is because HOG >>>>>>> talks directly to gattrib and clear his attrib instance on HOG disconnect >>>>>>> even there are ongoing GATT operations. Patches 9 - 25 solve this issue. >>>>>> >>>>>> I remember applying a patch from Arman that should have fixed the >>>>>> problem above: shared/att: cancel_all before calling disconnect cb. In >>>>>> any if that doesn't really solve the problem the client should cancel >>>>>> their pending operations before releasing its reference which means no >>>>>> callback should be called after that. >>>>> >>>>> This is problem above bt_att, but It might be worth to consider such >>>>> scenario in shared/gatt. >>>>> Anyway, In Android attrib is used by HOG and also GATT with all the >>>>> applications above. GATT controls registered clients so if one client >>>>> unregister we should not see the problem. But if HOG and GATT have >>>>> ongoing gatt operations and in this point of time we disconnect HOG, >>>>> we should not break ongoing gatt operations for GATT (Android apps). >>>>> Note that link LE link can be still up because of some other GATT >>>>> application so no disconnect_cb will be called by shared/add. Thats >>>>> why attrib client should take care for its operations >>>> >>>> Yep, but that why I said you should probably cancel any operations, >>>> which seems you did, but then why you keep checking for disconnected >>>> in the callbacks? There looks like there another bug going on. >>> >>> Canceling operation might not succeed, in that case callback will be >>> called anyway but unfortunately e.g. hog->attrib will be not valid >>> anymore and that's we need that additional check. >> >> Not succeed? bt_att_cancel should always succeed except if we cannot >> find the id. > > Just checked bt_att code and indeed, after calling cancel we should be > sure that callback will not be called. > However, I've seen something else during testing. That might be other > bug then. Will look into it probably tomorrow. Yep, it might be another bug or perhaps one operation that was not canceled for some reason. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
