Launchpad has imported 14 comments from the remote bug at https://bugzilla.suse.com/show_bug.cgi?id=1076898.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2018-01-20T14:48:14+00:00 Vincent Petry wrote: Before upgrading, connecting to bluetooth headset from TaoTronics worked correctly. I also have a cheap bluetooth watch and connecting to it with bluetoothctl worked fine. Today I updated Tumbleweed to snapshot 20180117 and I observe the following behavior: 1) Connecting to bluetooth headset does not work any more even after a fresh boot. It connects shortly then disconnects. Both with the Plasma widget and with bluetoothctl. 2) Sometimes even after a fresh boot, the plasma widget doesn't show any of the known bluetooth devices 3) Strangely connecting to my bluetooth watch still works with bluetoothctl. >From what I remember, before the update I had bluez-5.47 and now it has been updated to 5.48. Furthermore there is a similar report here for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1534857 The workaround, as indicated in that link, is to restart the bluetooth service with "systemctl restart bluetooth". After that the headset can connect again. This is on a Dell XPS 13 9333 (different model than the above). There are already logs in the Fedora ticket, I'll reboot now to try and gather some from here. Please let me know if you need further information. Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/0 ------------------------------------------------------------------------ On 2018-01-20T14:53:29+00:00 Vincent Petry wrote: Created attachment 756957 Log with errors I've attached the log from journalctl from the connection failure. Please note that during the short time where the connection to the headset is done, I can hear a beep in the headset which is an indication from its hardware that the connection was done. However the laptop / bluez somehow decides to disconnect again. Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/1 ------------------------------------------------------------------------ On 2018-01-20T15:06:15+00:00 Vincent Petry wrote: Okay, so I forgot to mention something: I had the module "btusb" blacklisted by default. The reason was mostly to save some power when I don't use bluetooth. I wonder if those Fedora users did the same. Anyway, now I removed "btusb" from blacklist and rebooted. And now it all works ! This seems to make sense because I suspect that whenever the bluetooth service is started at boot time, it needs btusb to be loaded already. So if you load the module afterwards, you need to restart the service. At this point, if this is by design, feel free to close as the problem is solved for me. ----------------------- My bluetooth adapter is built-in, so far so good. But what happens for people who have bluetooth USB dongles ? Would btusb only load later once the dongle is plugged in ? If that's the case, then the problem I describe *might* happen for said users who might need to restart the bluetooth service. Now this is marked as regression, it used to work with previous bluez versions. So not sure if this is something to be fixed upstream or whether this slight change of behavior / expectation is by design. Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/2 ------------------------------------------------------------------------ On 2018-01-24T13:56:16+00:00 Seife-c wrote: well, blacklisting the driver for the hardware is of course not helping :-) I think bluetoothd should still pick up devices that are added after starting (hot-plugged USB dongles come to my mind). Anyway, this is not an openSUSE problem, so I'd kindly ask you to report the issue upstream to the bluez-devel mailinglist at linux- blueto...@vger.kernel.org Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/3 ------------------------------------------------------------------------ On 2018-01-25T06:46:40+00:00 Vincent Petry wrote: Thanks, makes sense. I just observed that resuming from suspend also causes the issue and requires to restart the bluetooth service. Thanks for mentioning the mailing list. It was already reported by someone here on the mailing list: https://www.spinics.net/lists/linux-bluetooth/msg73824.html. I've sent my own message there which should appear shortly in the archives. Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/4 ------------------------------------------------------------------------ On 2018-02-06T15:33:32+00:00 Vincent Petry wrote: Email discussion and investigation in progress: https://marc.info/?l =linux-bluetooth&m=151792734112865&w=2 Breaking commit in bluez: d6e9539e31c6bb5afd39ec6f09c518d232e6345d Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/5 ------------------------------------------------------------------------ On 2018-02-11T21:22:13+00:00 Seife-c wrote: I have added the patch from commit 1873096352f518d3247f8efb3c2e0aa8804e50ac to the bluez package in home:seife:testing Could you please test if this fixes the issue for you? If yes, I'll submit this to Factory. Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/6 ------------------------------------------------------------------------ On 2018-02-11T22:13:34+00:00 Vincent Petry wrote: I have tested it and posted here https://marc.info/?l=linux- bluetooth&m=151815774828197&w=2 If this is the same patch from that email then yes it worked for me! Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/7 ------------------------------------------------------------------------ On 2018-02-11T22:14:17+00:00 Vincent Petry wrote: I'll test the package from your home also and report back. Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/8 ------------------------------------------------------------------------ On 2018-02-12T06:37:29+00:00 Vincent Petry wrote: Tested with bluez package from home:seife:testing and I can confirm that: - resuming after suspend can properly reconnects the headset - loading btusb module after restarting bluetooth service works Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/9 ------------------------------------------------------------------------ On 2018-02-12T07:38:40+00:00 Seife-c wrote: Thanks, package with patch is on its way to factory. https://build.opensuse.org/request/show/575486 (And yes, testing the package is IMO important because a) I could have done something wrong integrating the patch and b) maybe it works against git master but not older released code :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/10 ------------------------------------------------------------------------ On 2018-02-12T08:09:14+00:00 Vincent Petry wrote: Of course, makes perfect sense :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/11 ------------------------------------------------------------------------ On 2018-02-12T09:00:07+00:00 Swamp-a wrote: This is an autogenerated message for OBS integration: This bug (1076898) was mentioned in https://build.opensuse.org/request/show/575499 Factory / bluez Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/12 ------------------------------------------------------------------------ On 2018-02-18T12:08:17+00:00 Seife-c wrote: the fix has landed in Factory Reply at: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/comments/13 ** Changed in: suse Status: Unknown => Fix Released ** Changed in: suse Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759628 Title: bluez regression: Bluetooth audio fails to reconnect after resume Status in bluez package in Ubuntu: New Status in bluez package in Fedora: Fix Released Status in Suse: Fix Released Bug description: STEPS TO REPRODUCE: 1. Connect to Bluetooth audio device 2. Suspend & Resume 3. Reconnect to Bluetooth device. This regression in bluez 5.48 has already been identified and fixed upstream. Report is here <https://marc.info/?l=linux- bluetooth&m=151616078627045&w=2> and patch is here <https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=d6e9539e31c6bb5afd39ec6f09c518d232e6345d>. Syslog reports messages as follows when this issue is happening (I have replaced my device's MAC address with [MAC]): Mar 28 12:34:29 cue pulseaudio[1859]: [pulseaudio] bluez5-util.c: Information about device /org/bluez/hci0/dev_[MAC] is invalid Mar 28 12:34:29 cue bluetoothd[984]: Endpoint replied with an error: org.bluez.Error.InvalidArguments Mar 28 12:34:33 cue pulseaudio[1859]: [pulseaudio] bluez5-util.c: Information about device /org/bluez/hci0/dev_[MAC] is invalid Mar 28 12:34:33 cue bluetoothd[984]: Endpoint replied with an error: org.bluez.Error.InvalidArguments Workaround is to run sudo systemctl restart bluetooth after resume. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: bluez 5.48-0ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 Uname: Linux 4.15.0-12-generic x86_64 ApportVersion: 2.20.9-0ubuntu1 Architecture: amd64 CurrentDesktop: KDE Date: Wed Mar 28 12:37:11 2018 InstallationDate: Installed on 2018-03-23 (5 days ago) InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1) InterestingModules: rfcomm bnep btusb bluetooth MachineType: Hewlett-Packard HP ProBook 640 G1 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-12-generic root=/dev/mapper/internal-root ro quiet splash vt.handoff=1 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2018 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: L78 Ver. 01.43 dmi.board.name: 2101 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 16.3C dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvrL78Ver.01.43:bd01/25/2018:svnHewlett-Packard:pnHPProBook640G1:pvrA3009DD10303:rvnHewlett-Packard:rn2101:rvrKBCVersion16.3C:cvnHewlett-Packard:ct10:cvr: dmi.product.family: 103C_5336AN G=N L=BUS B=HP S=PRO dmi.product.name: HP ProBook 640 G1 dmi.product.version: A3009DD10303 dmi.sys.vendor: Hewlett-Packard hciconfig: hci0: Type: Primary Bus: USB BD Address: 80:00:0B:C7:4D:1C ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:5025 acl:32 sco:0 events:202 errors:0 TX bytes:5785 acl:32 sco:0 commands:103 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759628/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
