Hi Luiz, > Hi Vincent, > > On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@xxxxxxxxxxxxxx> wrote: >> 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 > Im not able to decipher this, what is the patch where the problem > first appeared? Also could you collect the HCI trace and syslog when > it happens? Please try this: 1. git clone git://git.kernel.org/pub/scm/bluetooth/bluez.git 2. cd bluez 3. git show d6e9539e31c6bb5afd39ec6f09c518d232e6345d This will show your the first bad commit / the patch that introduces the issue. For the syslog, see attachments to my original report here https://bugzilla.suse.com/show_bug.cgi?id=1076898 Do you have more information about how I could get the HCI trace ? Should I run bluetoothd through gdb and query the backtrace from the point where the error message happens, if that's what you are asking for ? On 02/06/2018 02:03 PM, Luiz Augusto von Dentz wrote: > >> 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
