** 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 notifications
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
https://github.com/
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:
https://bugs.la
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 quietc
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).
** Chang
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 suspend
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 prob
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.
https://bugs.launchpad.ne
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 sam
11 matches
Mail list logo