* Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume @ 2018-01-25 6:44 Vincent Petry 2018-01-25 18:43 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 14+ messages in thread From: Vincent Petry @ 2018-01-25 6:44 UTC (permalink / raw) To: linux-bluetooth 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. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-01-25 6:44 Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume Vincent Petry @ 2018-01-25 18:43 ` Luiz Augusto von Dentz 2018-01-30 6:47 ` Vincent Petry 0 siblings, 1 reply; 14+ messages in thread From: Luiz Augusto von Dentz @ 2018-01-25 18:43 UTC (permalink / raw) To: Vincent Petry; +Cc: linux-bluetooth Hi Vincent, On Thu, Jan 25, 2018 at 4:44 AM, Vincent Petry <pvince81@googlemail.com> 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? > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-01-25 18:43 ` Luiz Augusto von Dentz @ 2018-01-30 6:47 ` Vincent Petry 2018-02-01 18:36 ` Nathaniel McCallum 0 siblings, 1 reply; 14+ messages in thread From: Vincent Petry @ 2018-01-30 6:47 UTC (permalink / raw) To: Luiz Augusto von Dentz, Vincent Petry; +Cc: linux-bluetooth 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@googlemail.com> 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@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-01-30 6:47 ` Vincent Petry @ 2018-02-01 18:36 ` Nathaniel McCallum 2018-02-06 6:53 ` Vincent Petry 0 siblings, 1 reply; 14+ messages in thread From: Nathaniel McCallum @ 2018-02-01 18:36 UTC (permalink / raw) To: Vincent Petry; +Cc: Luiz Augusto von Dentz, linux-bluetooth 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@googlemail.com> 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@googlemail.com> 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@vger.kernel.org >>> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-01 18:36 ` Nathaniel McCallum @ 2018-02-06 6:53 ` Vincent Petry 2018-02-06 13:03 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 14+ messages in thread From: Vincent Petry @ 2018-02-06 6:53 UTC (permalink / raw) To: Nathaniel McCallum, Vincent Petry; +Cc: Luiz Augusto von Dentz, linux-bluetooth 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@googlemail.com> 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@googlemail.com> 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@vger.kernel.org >>>> 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@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-06 6:53 ` Vincent Petry @ 2018-02-06 13:03 ` Luiz Augusto von Dentz 2018-02-06 13:17 ` Vincent Petry 0 siblings, 1 reply; 14+ messages in thread From: Luiz Augusto von Dentz @ 2018-02-06 13:03 UTC (permalink / raw) To: Vincent Petry; +Cc: Nathaniel McCallum, linux-bluetooth Hi Vincent, On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@googlemail.com> 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? > 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@googlemail.com> 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@googlemail.com> 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@vger.kernel.org >>>>> 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@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-06 13:03 ` Luiz Augusto von Dentz @ 2018-02-06 13:17 ` Vincent Petry 2018-02-06 13:30 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 14+ messages in thread From: Vincent Petry @ 2018-02-06 13:17 UTC (permalink / raw) To: Luiz Augusto von Dentz, Vincent Petry; +Cc: Nathaniel McCallum, linux-bluetooth Hi Luiz, > Hi Vincent, > > On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@googlemail.com> 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@googlemail.com> 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@googlemail.com> 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@vger.kernel.org >>>>>> 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@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-06 13:17 ` Vincent Petry @ 2018-02-06 13:30 ` Luiz Augusto von Dentz 2018-02-06 14:28 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 14+ messages in thread From: Luiz Augusto von Dentz @ 2018-02-06 13:30 UTC (permalink / raw) To: Vincent Petry; +Cc: Nathaniel McCallum, linux-bluetooth Hi Vincent, On Tue, Feb 6, 2018 at 11:17 AM, Vincent Petry <pvince81@googlemail.com> wrote: > Hi Luiz, > >> Hi Vincent, >> >> On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@googlemail.com> 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 ? Jan 20 15:50:47 vvortex.ttv pulseaudio[1964]: [pulseaudio] bluez5-util.c: Information about device /org/bluez/hci0/dev_E3_28_E9_20_58_08 is invalid Jan 20 15:50:47 vvortex.ttv bluetoothd[3136]: Endpoint replied with an error: org.bluez.Error.InvalidArguments So this is really PulseAudio rejecting the connection, it probably loose track of the objects when resuming or we did not send the objects but in that case bluetoothctl would not be able to list them as well. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-06 13:30 ` Luiz Augusto von Dentz @ 2018-02-06 14:28 ` Luiz Augusto von Dentz 2018-02-07 6:52 ` Vincent Petry 0 siblings, 1 reply; 14+ messages in thread From: Luiz Augusto von Dentz @ 2018-02-06 14:28 UTC (permalink / raw) To: Vincent Petry; +Cc: Nathaniel McCallum, linux-bluetooth Hi Vincent, On Tue, Feb 6, 2018 at 11:30 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Vincent, > > On Tue, Feb 6, 2018 at 11:17 AM, Vincent Petry <pvince81@googlemail.com> wrote: >> Hi Luiz, >> >>> Hi Vincent, >>> >>> On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@googlemail.com> 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 ? > > Jan 20 15:50:47 vvortex.ttv pulseaudio[1964]: [pulseaudio] > bluez5-util.c: Information about device > /org/bluez/hci0/dev_E3_28_E9_20_58_08 is invalid > Jan 20 15:50:47 vvortex.ttv bluetoothd[3136]: Endpoint replied with an > error: org.bluez.Error.InvalidArguments > > So this is really PulseAudio rejecting the connection, it probably > loose track of the objects when resuming or we did not send the > objects but in that case bluetoothctl would not be able to list them > as well. And I couldn't reproduce it myself: https://gist.github.com/anonymous/423edb41e572577b8507d8d0662acc84 -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-06 14:28 ` Luiz Augusto von Dentz @ 2018-02-07 6:52 ` Vincent Petry 2018-02-08 15:15 ` Julien Nicoulaud 0 siblings, 1 reply; 14+ messages in thread From: Vincent Petry @ 2018-02-07 6:52 UTC (permalink / raw) To: Luiz Augusto von Dentz, Vincent Petry; +Cc: Nathaniel McCallum, linux-bluetooth Hi Luiz, Can you give me some pointers where I should put the gdb breakpoint to get a useful trace ? I also saw that there is some DBG function logging things. How do I enable this logging and from where can I get its output ? Useful would probably to log some internal state with and without returning from suspend. Regarding the breaking patch, it seems to be related to some advertising API that used to be marked experimental and is now not experimental any more in 5.48. Does maybe pulseaudio use this API and had a fallback at the time said API was disabled ? And now that it's enabled its code path changed and maybe triggered a hidden bug ? Would need to look at the pulseaudio bluetooth source code. Or does the patch in question enabled advertising where no advertising was done before ? Maybe it is advertising too early at a time where the system hasn't fully resumed from suspend ? My pulseaudio version: pulseaudio-11.1-2.1.x86_64 Would be good if the other affected users post their distro + pulseaudio versions for cross-reference. Cheers, Vincent On 02/06/2018 03:28 PM, Luiz Augusto von Dentz wrote: > Hi Vincent, > > On Tue, Feb 6, 2018 at 11:30 AM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> Hi Vincent, >> >> On Tue, Feb 6, 2018 at 11:17 AM, Vincent Petry <pvince81@googlemail.com> wrote: >>> Hi Luiz, >>> >>>> Hi Vincent, >>>> >>>> On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@googlemail.com> 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 ? >> Jan 20 15:50:47 vvortex.ttv pulseaudio[1964]: [pulseaudio] >> bluez5-util.c: Information about device >> /org/bluez/hci0/dev_E3_28_E9_20_58_08 is invalid >> Jan 20 15:50:47 vvortex.ttv bluetoothd[3136]: Endpoint replied with an >> error: org.bluez.Error.InvalidArguments >> >> So this is really PulseAudio rejecting the connection, it probably >> loose track of the objects when resuming or we did not send the >> objects but in that case bluetoothctl would not be able to list them >> as well. > And I couldn't reproduce it myself: > https://gist.github.com/anonymous/423edb41e572577b8507d8d0662acc84 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-07 6:52 ` Vincent Petry @ 2018-02-08 15:15 ` Julien Nicoulaud 2018-02-08 16:28 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 14+ messages in thread From: Julien Nicoulaud @ 2018-02-08 15:15 UTC (permalink / raw) To: Vincent Petry; +Cc: Luiz Augusto von Dentz, Nathaniel McCallum, linux-bluetooth 2018-02-07 7:52 GMT+01:00 Vincent Petry <pvince81@googlemail.com>: > > Hi Luiz, > > Can you give me some pointers where I should put the gdb breakpoint to > get a useful trace ? > > I also saw that there is some DBG function logging things. How do I > enable this logging and from where can I get its output ? Useful would > probably to log some internal state with and without returning from suspend. > > Regarding the breaking patch, it seems to be related to some advertising > API that used to be marked experimental and is now not experimental any > more in 5.48. > Does maybe pulseaudio use this API and had a fallback at the time said > API was disabled ? And now that it's enabled its code path changed and > maybe triggered a hidden bug ? Would need to look at the pulseaudio > bluetooth source code. > Or does the patch in question enabled advertising where no advertising > was done before ? Maybe it is advertising too early at a time where the > system hasn't fully resumed from suspend ? > > My pulseaudio version: pulseaudio-11.1-2.1.x86_64 > > Would be good if the other affected users post their distro + pulseaudio > versions for cross-reference. Hi, I am also affected by this since updating to bluez 5.48. My distro is Arch Linux, pulseaudio 11.1-1, linux 4.14.15, using a Bose QuietComfort 35 headset with an Asus zenbook laptop (Intel 7260 wireless chip). Please let me know if I can be of any help. Cheers, Julien > > > Cheers, > > Vincent > > > On 02/06/2018 03:28 PM, Luiz Augusto von Dentz wrote: > > Hi Vincent, > > > > On Tue, Feb 6, 2018 at 11:30 AM, Luiz Augusto von Dentz > > <luiz.dentz@gmail.com> wrote: > >> Hi Vincent, > >> > >> On Tue, Feb 6, 2018 at 11:17 AM, Vincent Petry <pvince81@googlemail.com> wrote: > >>> Hi Luiz, > >>> > >>>> Hi Vincent, > >>>> > >>>> On Tue, Feb 6, 2018 at 4:53 AM, Vincent Petry <pvince81@googlemail.com> 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 ? > >> Jan 20 15:50:47 vvortex.ttv pulseaudio[1964]: [pulseaudio] > >> bluez5-util.c: Information about device > >> /org/bluez/hci0/dev_E3_28_E9_20_58_08 is invalid > >> Jan 20 15:50:47 vvortex.ttv bluetoothd[3136]: Endpoint replied with an > >> error: org.bluez.Error.InvalidArguments > >> > >> So this is really PulseAudio rejecting the connection, it probably > >> loose track of the objects when resuming or we did not send the > >> objects but in that case bluetoothctl would not be able to list them > >> as well. > > And I couldn't reproduce it myself: > > https://gist.github.com/anonymous/423edb41e572577b8507d8d0662acc84 > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-08 15:15 ` Julien Nicoulaud @ 2018-02-08 16:28 ` Luiz Augusto von Dentz 2018-02-09 6:28 ` Vincent Petry 0 siblings, 1 reply; 14+ messages in thread From: Luiz Augusto von Dentz @ 2018-02-08 16:28 UTC (permalink / raw) To: Julien Nicoulaud; +Cc: Vincent Petry, Nathaniel McCallum, linux-bluetooth Hi, On Thu, Feb 8, 2018 at 5:15 PM, Julien Nicoulaud <julien.nicoulaud@gmail.com> wrote: > 2018-02-07 7:52 GMT+01:00 Vincent Petry <pvince81@googlemail.com>: >> >> Hi Luiz, >> >> Can you give me some pointers where I should put the gdb breakpoint to >> get a useful trace ? >> >> I also saw that there is some DBG function logging things. How do I >> enable this logging and from where can I get its output ? Useful would >> probably to log some internal state with and without returning from suspend. >> >> Regarding the breaking patch, it seems to be related to some advertising >> API that used to be marked experimental and is now not experimental any >> more in 5.48. >> Does maybe pulseaudio use this API and had a fallback at the time said >> API was disabled ? And now that it's enabled its code path changed and >> maybe triggered a hidden bug ? Would need to look at the pulseaudio >> bluetooth source code. >> Or does the patch in question enabled advertising where no advertising >> was done before ? Maybe it is advertising too early at a time where the >> system hasn't fully resumed from suspend ? >> >> My pulseaudio version: pulseaudio-11.1-2.1.x86_64 >> >> Would be good if the other affected users post their distro + pulseaudio >> versions for cross-reference. > > Hi, I am also affected by this since updating to bluez 5.48. > > My distro is Arch Linux, pulseaudio 11.1-1, linux 4.14.15, using a > Bose QuietComfort 35 headset with an Asus zenbook laptop (Intel 7260 > wireless chip). > > Please let me know if I can be of any help. Please check with the patch Ive sent yesterday: core: Fixes order InterfaceAdded ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume 2018-02-08 16:28 ` Luiz Augusto von Dentz @ 2018-02-09 6:28 ` Vincent Petry 0 siblings, 0 replies; 14+ messages in thread From: Vincent Petry @ 2018-02-09 6:28 UTC (permalink / raw) To: Luiz Augusto von Dentz, Julien Nicoulaud Cc: Vincent Petry, Nathaniel McCallum, linux-bluetooth Hello Luiz, I've applied the patch "[PATCH v2] core: Fixes order InterfaceAdded" from https://marc.info/?l=linux-bluetooth&m=151801178209679&w=2. Then tried suspend/resume a few times and can confirm that the headset is now able to connect again ! I can confirm that the patch fixes the issue for me ! Is there a timeline for the next bluez release ? Just asking because if it happens much later we might want to apply the patch directly on distribution packages (once reviewed and merged). Cheers and thanks for the great work ! Vincent On 02/08/2018 05:28 PM, Luiz Augusto von Dentz wrote: > Hi, > > On Thu, Feb 8, 2018 at 5:15 PM, Julien Nicoulaud > <julien.nicoulaud@gmail.com> wrote: >> 2018-02-07 7:52 GMT+01:00 Vincent Petry <pvince81@googlemail.com>: >>> Hi Luiz, >>> >>> Can you give me some pointers where I should put the gdb breakpoint to >>> get a useful trace ? >>> >>> I also saw that there is some DBG function logging things. How do I >>> enable this logging and from where can I get its output ? Useful would >>> probably to log some internal state with and without returning from suspend. >>> >>> Regarding the breaking patch, it seems to be related to some advertising >>> API that used to be marked experimental and is now not experimental any >>> more in 5.48. >>> Does maybe pulseaudio use this API and had a fallback at the time said >>> API was disabled ? And now that it's enabled its code path changed and >>> maybe triggered a hidden bug ? Would need to look at the pulseaudio >>> bluetooth source code. >>> Or does the patch in question enabled advertising where no advertising >>> was done before ? Maybe it is advertising too early at a time where the >>> system hasn't fully resumed from suspend ? >>> >>> My pulseaudio version: pulseaudio-11.1-2.1.x86_64 >>> >>> Would be good if the other affected users post their distro + pulseaudio >>> versions for cross-reference. >> Hi, I am also affected by this since updating to bluez 5.48. >> >> My distro is Arch Linux, pulseaudio 11.1-1, linux 4.14.15, using a >> Bose QuietComfort 35 headset with an Asus zenbook laptop (Intel 7260 >> wireless chip). >> >> Please let me know if I can be of any help. > Please check with the patch Ive sent yesterday: core: Fixes order InterfaceAdded ^ permalink raw reply [flat|nested] 14+ messages in thread
* Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume @ 2018-01-17 3:46 Robert Hancock 0 siblings, 0 replies; 14+ messages in thread From: Robert Hancock @ 2018-01-17 3:46 UTC (permalink / raw) To: linux-bluetooth I've come across an apparent regression in Fedora 27 as a result of an update to bluez 5.48 with Intel 8265 Bluetooth and some Monster Clarity HD headphones. After a suspend/resume of the laptop, the headphones refuse to reconnect until either removing the device entry and re-pairing or restarting bluetoothd. Downgrading bluez to 5.47 seems to fix the problem. I've added some hcidump output and log output in Red Hat Bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=1534857 Any thoughts on what could be going on? ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-02-09 6:28 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-25 6:44 Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume Vincent Petry 2018-01-25 18:43 ` Luiz Augusto von Dentz 2018-01-30 6:47 ` Vincent Petry 2018-02-01 18:36 ` Nathaniel McCallum 2018-02-06 6:53 ` Vincent Petry 2018-02-06 13:03 ` Luiz Augusto von Dentz 2018-02-06 13:17 ` Vincent Petry 2018-02-06 13:30 ` Luiz Augusto von Dentz 2018-02-06 14:28 ` Luiz Augusto von Dentz 2018-02-07 6:52 ` Vincent Petry 2018-02-08 15:15 ` Julien Nicoulaud 2018-02-08 16:28 ` Luiz Augusto von Dentz 2018-02-09 6:28 ` Vincent Petry -- strict thread matches above, loose matches on Subject: below -- 2018-01-17 3:46 Robert Hancock
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.