Hello, I have bisected bluez between 5.47 (good) and 5.48 (bad) to find the breaking commit for the headset reconnect issue. Here are the results: git bisect start # bad: [0d1e3b9c5754022c779da129025d493a198d49cf] Release 5.48 git bisect bad 0d1e3b9c5754022c779da129025d493a198d49cf # good: [d139fd866241fe0d99b5e430f937c8d6160cc7dd] Release 5.47 git bisect good d139fd866241fe0d99b5e430f937c8d6160cc7dd # bad: [65aaf36f2a36895e4a351ac3fa1cb8da87d4589c] mesh: Correct length test in agent.c:request_ascii git bisect bad 65aaf36f2a36895e4a351ac3fa1cb8da87d4589c # good: [c50a8a397d4abd994a9115230279d5fe922b4aa5] adapter: Add btd_request_authorization_cable_configured() git bisect good c50a8a397d4abd994a9115230279d5fe922b4aa5 # bad: [c133489d54cb6d28c3fd308557937acbc5245f5e] battery: Add BT SIG reserved number used by Battery Service git bisect bad c133489d54cb6d28c3fd308557937acbc5245f5e # good: [e577e478e9cb1d1a22e63fd7d8fff07c471590de] gatt: Add implementation of link option git bisect good e577e478e9cb1d1a22e63fd7d8fff07c471590de # bad: [5b9596dac4d0e25c5179be8643726a02c058b00a] advertising: Add implementation of Duration and Timeout git bisect bad 5b9596dac4d0e25c5179be8643726a02c058b00a # bad: [f9a2b1f515c7f5dced80397f4ea891d6c372175d] client: Fix not detecting advertising instance is no longer valid git bisect bad f9a2b1f515c7f5dced80397f4ea891d6c372175d # bad: [d6e9539e31c6bb5afd39ec6f09c518d232e6345d] doc/advertising-api: Mark LEAdvertisingManager1 stable git bisect bad d6e9539e31c6bb5afd39ec6f09c518d232e6345d # good: [10760c91c234fe2bfedf924c9e61f31861c2dc72] gatt: Fix crash while disconnecting ATT git bisect good 10760c91c234fe2bfedf924c9e61f31861c2dc72 # first bad commit: [d6e9539e31c6bb5afd39ec6f09c518d232e6345d] doc/advertising-api: Mark LEAdvertisingManager1 stable For every step I ran the following script that compiles and install into the system and then restarts the service, followed by modprobe btusb. The order is important to simulate hotplug or a return from a suspended system. Steps: 1. Run compile script from https://gist.github.com/PVince81/95d01439490355babd4c405d28a548dc 2. Enable bluetooth in Plasma 5 panel 3. Run bluetoothctl 4. Run "connect" command with headset's address 5. Wait for connect. If it connects, test changing the volume in Plasma 5 which will trigger a pop sound to confirm it works. Looking at the commit in question I can't tell in what way it is related to our headset issues. Maybe a bluez expert can help here ? :-) Please let me know if I can help testing patches. Cheers, Vincent On 02/01/2018 07:36 PM, Nathaniel McCallum wrote: > I'm seeing this too. My headphones go through a connect/disconnect > cycle a few times and then quit. Unpairing and repairing does make it > work. > > On Tue, Jan 30, 2018 at 1:47 AM, Vincent Petry <pvince81@xxxxxxxxxxxxxx> wrote: >> Hello, >> >> On 01/25/2018 07:43 PM, Luiz Augusto von Dentz wrote: >>> Hi Vincent, >>> >>> On Thu, Jan 25, 2018 at 4:44 AM, Vincent Petry <pvince81@xxxxxxxxxxxxxx> wrote: >>>> Hello, >>>> >>>> I just joined the mailing list so can't directly reply to old messages, >>>> so sending with same title. >>>> >>>> I'm experiencing the same issue as Robert here >>>> https://www.spinics.net/lists/linux-bluetooth/msg73824.html, happening >>>> on the same laptop Dell XPS 13 but with different sub-model 9333, but on >>>> openSUSE Tumbleweed. >>>> >>>> It looks like the bluez component is in a wrong state when either >>>> loading btusb with modprobe later on or resuming from suspend. The >>>> workaround is to restart the systemd bluetooth daemon. I suspect that >>>> plugging in USB bluetooth dongles would also have the same issue but I >>>> don't have one to test. >>> Does the system have any controller after resume? Does bluetoothctl >>> report any device at all? >> After resume from suspend, bluetoothctl sees the controller, yes and it >> does report my usual three devices from the saved list. >> >> When I tell it to connect to the headset (which is turned on), I can >> hear the headset beep shortly which is the signal for connection, but >> then it disconnects again: >> Attempting to connect to E3:XX:XX:XX:XX:XX >> [CHG] Device E3:XX:XX:XX:XX:XX Connected: yes >> Failed to connect: org.bluez.Error.Failed >> [CHG] Device E3:XX:XX:XX:XX:XX Connected: no >> >> If I tell it to connect to my bluetooth watch it stays connected. >> >> Now I wanted to try accessing characteristics but the command >> "select-attribute" has gone missing ? I also tried "help gatt" as it >> seems to be a submenu but it says "Too many argumnets". Possibly another >> bug in bluez ? (I can send a separate email for this one if you want) >> >> Anyway, I have a Python script that uses Dbus and said Python script is >> able to connect to my watch and talk to it even in this state. >> >> So the bluez 5.48 regression seems to be specifically with headsets and >> also with scanning/discovering. I don't have any other device types to >> test with. >> >> The workaround is to restart the bluetooth service and enable bluetooth >> afterwards. >> >> Please make sure to look at >> https://bugzilla.suse.com/show_bug.cgi?id=1076898 for logs I posted. >> >> If you guys cannot reproduce the first regression I could try and bisect >> bluez locally to find the breaking change. For this I need to know how >> to set up bluez on my system after compiling. Is there any guide about >> this ? Should I tell it to overwrite the existing libs and reboot or is >> restarting the bluetooth service sufficient to make it use the newly >> installed version ? >> >> Thanks, >> >> Vincent >> >>>> It used to work correctly before the upgrade from 5.47 to 5.48. >>>> >>>> See my original report here for details: >>>> https://bugzilla.suse.com/show_bug.cgi?id=1076898 >>>> Robert's report https://bugzilla.redhat.com/show_bug.cgi?id=1534857, >>>> also confirmed by a third person. >>>> >>>> Please let us know if this is reproducible on your side or whether it's >>>> an isolated case specific to our Dell hardware. >>>> >>>> Thanks, >>>> >>>> Vincent Petry >>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> -- >> 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 -- 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
