Hi Luiz, On Fri, Dec 2, 2016 at 3:56 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Petri, > > On Thu, Dec 1, 2016 at 11:12 PM, Petri Gynther <pgynther@xxxxxxxxxx> wrote: >> However, in this case, I think this handling is correct. >> load_gatt_db() showed "No cache for LEFQAU", so BlueZ has to >> re-discover everything from the device over BLE. >> But, since the device disconnected in the middle of discovery, BlueZ >> couldn't fully populate the GATT DB and has to clean it. >> If the device didn't disconnect so quickly, this would have most likely worked. >> >>> But I do agree that we should not reset the db if that was populated >>> already, so I will try to fix that. >> >> Yes, once BlueZ does not reset the GATT DB on failed reconnects, this >> problem will be solved. > > Please check if everything is alright when using upstream, it should > clear the database anymore if we get an early disconnect. I applied my 2 patches and your 2 patches on top of 5.43. GATT DB is no longer destroyed on reconnection errors, so that's excellent. However, we are still seeing reconnect problems, but not GATT DB related: bluez: bluetoothd[17780]: src/gatt-client.c:btd_gatt_client_connected() Device connected. bluez: bluetoothd[17780]: profiles/gap/gas.c:read_device_name_cb() Reading device name failed with ATT error: 0 bluez: bluetoothd[17780]: profiles/gap/gas.c:read_appearance_cb() Reading appearance failed with ATT error: 0 bluez: bluetoothd[17780]: Error reading PNP_ID value: Unexpected error code bluez: bluetoothd[17780]: BATT level_read_char_cb failed: Request attribute has encountered an unlikely error We are still investigating this. Likely a firmware issue on the remote. > > > -- > 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
