Hi Naresh, On Tue, Oct 25, 2016 at 6:00 PM, Naresh <kbn456@xxxxxxxxx> wrote: > Hi Luiz, > > > On Monday 24 October 2016 09:33 PM, Luiz Augusto von Dentz wrote: >> >> Hi Naresh, >> >> On Mon, Oct 24, 2016 at 6:11 PM, Naresh <kbn456@xxxxxxxxx> wrote: >>> >>> On Thursday 20 October 2016 03:28 PM, Luiz Augusto von Dentz wrote: >>> Hi Luiz, >>>> >>>> Hi Naresh, >>>> >>>> On Thu, Oct 20, 2016 at 12:43 PM, Naresh <kbn456@xxxxxxxxx> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've been writing ble client application using latest bluez version >>>>> (5.42) >>>>> and based on gatttool. We have some different requirement, so we didn't >>>>> used >>>>> D-Bus based API's as its not implement with D-BUS API's, Like we wanted >>>>> to >>>>> disable filter duplicate to receive all the advertisement(Even all the >>>>> parameters are same) for proximity check and than connect and pair. >>>>> >>>>> We have used HCI layer api for getting advertisement with filter >>>>> duplicate >>>>> disabled and based on the BD address we connect using the Btio layer >>>>> API >>>>> than used gattrib API to perform read/write/Notification confirmation >>>>> operations. >>>> >>>> gattrib API is deprecated, you should use what is under src/shared >>>> since that is what we unit test. >>> >>> Yes, Now we have migrated and used API's under src/shared for read/Write. >>>>> >>>>> We are performing some write/write_without operation continuously based >>>>> on >>>>> request by the our app(it kind of stress test) but after some write, >>>>> its >>>>> gets stuck I mean write queue is not being processed, there is no ATT >>>>> logs >>>>> once write is failed (returning some negative id) but write are being >>>>> queued. >>>>> >>>>> We have debugged this issue in bluez and found that once wakeup_writer >>>>> sets >>>>> the io_set_write_handler for queued operation than set writer_active to >>>>> true, after that write is performed and destroyer callback will set >>>>> writer_active back to false. >>>>> >>>>> But in failed case before wakeup_writer being set writer_active to >>>>> true, >>>>> the >>>>> write and destroy operation are being processed i.e writer_active never >>>>> set >>>>> to false and io_set_write_handler are never set for upcoming >>>>> operations. >>>>> >>>>> I don't know what causing this scenario. >>>> >>>> I guess the first thing to do is to attempt to reproduce with >>>> bt_gatt_client API and have HCI traces so we can see where it fails, >>>> perhaps it is even disconnecting in the meantime, but it shouldn't >>>> queue them up. >>>> >>> But we are still facing the same problem with write, Please find an >>> attachment of hci trace logs and write logs. >> >> Yep, good luck scanning and transferring data at same time, about half >> of the logs are just reports you get from scanning. Btw APIs such as >> bt_gatt_client_write_without_response return unsigned int so it can >> never be a negative id, either you are printing as a signed or there >> is something else perhaps out of memory, bottom line is if it fails it >> should return 0. >> > Below are the scenario's observed while running the stress test, > 1) In the success case: "write without response" will internally calls > bt_att_send(bluez version:5.42 file:src/shared/att.c, line:1206) there it > will create att_send_op instance(op) and pushes op into write queue then > calls the wakeup_writer() and returns op->id. afterwards can_write_data pops > data from queue(mainloop thread context) and calls io_send method. After the > successful write op instance will be destroyed. > > 2)But in failure case: after wakeup_writer() is called and before returning > the proper op->id, can_write_data gets scheduled from mainloop thread > context and op instance is destroyed. So bt_att_send returns garbage op id, > because of this att->writer_active flag is also corrupted(writer_active > remains in true) which doesn't allow any further calling of > io_set_write_handler to schedule write operation. Then this looks like a thread issue, note our shared libraries are not thread safe. > We ran the test after disabling scan(once client is connected) but still > same problem is observed. > > Thanks in advance for any suggestions/comments. > > > Regards, > Naresh K -- 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
