** Changed in: bluez
Status: Unknown => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1962542
Title:
bose quietcomfort 35 unable to connect after suspend
To manage
OK the crash is a separate issue.
This is https://github.com/bluez/bluez/issues/284 which is also fixed in
BlueZ 5.64.
** Bug watch added: github.com/bluez/bluez/issues #284
https://github.com/bluez/bluez/issues/284
** Bug watch added: github.com/bluez/bluez/issues #284
See also bug 1962563.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1962542
Title:
bose quietcomfort 35 unable to connect after suspend
To manage notifications about this bug go to:
If you can find evidence of 'bluetoothd' crashing then it is
https://github.com/bluez/bluez/issues/272 (fixed in BlueZ 5.64).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1962542
Title:
bose
Actually it sounds like https://github.com/bluez/bluez/issues/272 but
yours isn't crashing(?)
There's mention of QC35 in https://github.com/bluez/bluez/issues/220
too, and that it works after downgrading to BlueZ 5.61.
Both seem to be fixed in upstream master (which will be BlueZ 5.64).
**
Reassigned to the kernel/firmware packages.
We next need to review what the kernel has logged during suspend/resume.
Comment #18 doesn't look like enough info so can you attach the full
log? (journalctl -b0)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
^^^
That's missing two of your radio devices (the Intel Wifi and Bluetooth), if you
compare to comment #17. So it looks like the kernel devices have vanished after
resuming from suspend the first time.
** Changed in: bluez (Ubuntu)
Status: New => Invalid
** Also affects: linux-firmware
There is no difference in 'rfkill' before/after suspend. In both cases,
the bluetooth line looks like this:
heather@fenrir:~$ rfkill
ID TYPE DEVICE SOFT HARD
0 bluetooth tpacpi_bluetooth_sw unblocked unblocked
And the PID of bluetoothd is the same before/after
apport information
** Description changed:
Bose quietcomfort 35 is a common headset that can no longer connect to a
jammy system after just one suspend. This started at the end of January
but just now really debugging the issue.
+
+ Side note that my bluetooth mouse works fine without
Also does the 'rfkill' command show any difference in the radio status
after resume?
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Firstly good news that it partially works now. It didn't before
according to bug 1620636.
What is the Bluetooth chip in the laptop (lspci / lsusb)? We probably
need to check to see if it is chip-specific (a kernel bug) or a BlueZ
bug.
Please also check the PID of bluetoothd to see if it's the
11 matches
Mail list logo
