[Kernel-packages] [Bug 1790454] Re: Bluetooth (btintel) stops working after suspend/resume

[DH]

I am having a similar issue with Intel 8260. Wifi and BT works correctly
after cold boot. Wifi works correctly after suspend, but BT was showing
no adapters available in KDE plasma widget. dmesg would report "[
150.064149] Bluetooth: hci0: Failed to send firmware data (-38)" after
each resume.

My 8260 was not listed in lsusb, but is listed in lspci.

Fix in #47 did not work for me. However, adding a systemd service to
rmmod and modprobe btusb after each resume seems to have the BT adapter
working correctly now.

uname -a:
Linux uranus 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:04:24 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1790454

Title:
  Bluetooth (btintel) stops working after suspend/resume

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I run cosmic on my Dell Latitude E7470, which has an intel usb
  bluetooth device (8087:0a2b).

  Sometimes (not every time) after a suspend/resume cycle, my laptop's
  bluetooth stops working.  hciconfig shows:

  hci0: Type: Primary  Bus: USB
BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
DOWN 
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:3 acl:0 sco:0 commands:1 errors:0

  and dmesg tells me (various combinations of):

  [237660.728312] Bluetooth: hci0: command tx timeout
  [237732.339965] Bluetooth: hci0: command 0xfc05 tx timeout
  [237925.202500] Bluetooth: hci0: Reading Intel version information failed 
(-110)

  
  Trying to reinitialize the device by reloading the driver has no effect:

  ╰─▶ modprobe -r btusb; modprobe -r btintel; modprobe btintel; modprobe
  btusb

  shows in dmesg:

  [237938.219190] usbcore: deregistering interface driver btusb
  [237938.601731] usbcore: registered new interface driver btusb
  [237940.626392] Bluetooth: hci0: Reading Intel version information failed 
(-110)
  [237940.626426] Bluetooth: hci0: command tx timeout

  Strangely enough, reloading the module sometimes does work, upon which the 
kernel tells me :
  aug 20 15:36:08 regan kernel: usbcore: deregistering interface driver btusb
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: Bootloader revision 0.0 build 
2 week 52 2014
  aug 20 15:36:30 regan kernel: usbcore: registered new interface driver btusb
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: Device revision is 5
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: Secure boot is enabled
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: OTP lock is enabled
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: API lock is enabled
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: Debug lock is disabled
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: Minimum firmware build 1 week 
10 2014
  aug 20 15:36:30 regan kernel: Bluetooth: hci0: Found device firmware: 
intel/ibt-11-5.sfi
  aug 20 15:36:31 regan kernel: Bluetooth: hci0: Waiting for firmware download 
to complete
  aug 20 15:36:31 regan kernel: Bluetooth: hci0: Firmware loaded in 1590852 
usecs
  aug 20 15:36:31 regan kernel: Bluetooth: hci0: Waiting for device to boot
  aug 20 15:36:31 regan kernel: Bluetooth: hci0: Device booted in 11654 usecs
  aug 20 15:36:31 regan kernel: Bluetooth: hci0: Found Intel DDC parameters: 
intel/ibt-11-5.ddc
  aug 20 15:36:31 regan kernel: Bluetooth: hci0: Applying Intel DDC parameters 
completed

  
  Looking further back in the kernel log, the difference between failed and 
successful resumes seems to be this:

  Resume with broken bt:
  [236481.370814] Restarting tasks ... 
  [236491.580841] Bluetooth: hci0: Reading Intel boot parameters failed (-110)

  Resume with working bt:
  [16562.706263] Restarting tasks ... 
  [16562.709034] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
  [16562.716050] Bluetooth: hci0: Device revision is 5
  [16562.716052] Bluetooth: hci0: Secure boot is enabled
  [16562.716053] Bluetooth: hci0: OTP lock is enabled
  [16562.716054] Bluetooth: hci0: API lock is enabled
  [16562.716055] Bluetooth: hci0: Debug lock is disabled
  [16562.716056] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
  [16562.716404] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
  [16564.202470] Bluetooth: hci0: Waiting for firmware download to complete
  [16564.203017] Bluetooth: hci0: Firmware loaded in 1459449 usecs
  [16564.203091] Bluetooth: hci0: Waiting for device to boot
  [16564.215021] Bluetooth: hci0: Device booted in 11693 usecs
  [16564.215080] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
  [16564.219033] Bluetooth: hci0: Applying Intel DDC parameters completed

  
  and everything works fine after that.


  The first kernel on which this error occurred was 4.17.0-6-generic.  Before 
that, I used 4.15.0-25-generic which works perfectly.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.10-0ubuntu9
  Architecture: amd64
  AudioDevicesInUse:
   USER   

[Kernel-packages] [Bug 1759628] Re: bluez regression: Bluetooth audio fails to reconnect after resume

[DH]

#29 Fix confirmed on Ubuntu 18.04 on Miix 700 / Intel 8260

-- 
You received this bug notification because you are a member of Kernel
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:
  Fix Released
Status in bluez source package in Bionic:
  Fix Committed
Status in bluez package in Fedora:
  Fix Released
Status in Suse:
  Fix Released

Bug description:
  [Impact]

  Users of Bluetooth audio have no sound after they suspend and resume
  the system.

  [Test Case]

   1. Connect to Bluetooth audio device
   2. Suspend & Resume
   3. Reconnect to Bluetooth device.

  [Regression Potential]

  Low. Although common Bluetooth code is modified in the fix, it has
  been released as a patch in other distros for some time already.

  [Other Info]

  Already released to cosmic as part of bluez version 5.50.

  This regression in bluez 5.48 has already been identified and fixed
  upstream. Report is here  and patch is here
  
.

  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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Kernel-packages] [Bug 1670041] Re: Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless 1535)

[dh]

Dell XPS owner, I would also suggest you hassle Dell.. selling a laptop
with Ubuntu installed, where one of the devices doesn't even work properly
is a bit of a d1ck move. I've reported the issue with them which they
promised would be relayed to their hw team. More reports can't hurt!
Not that it helps but the card swap I mentioned earlier was effective
(better range, throughput and speed reporting now correct (I failed to
gather useful data for comparison before the card swap though).

On 29 Jun 2017 23:45, "Kir Kolyshkin"  wrote:

> I also suffer from the same bug on dell xps 13 9360, tcp wi-fi is 5-10x
> slower than on other devices.
>
> @kalle we understand the patch you refer to is just a workaround, not a
> solution. Is anyone working on a real fix?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1670041
>
> Title:
>   Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless
>   1535)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
> 1670041/+subscriptions
>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1670041

Title:
  Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless
  1535)

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Zesty:
  In Progress

Bug description:
  Update (2017-05-20):
  Kalle Valo suggested a hack which increased client -> AP TCP performance - so 
it does not look like a firmware issue as I thought originally, rather an 
ath10k driver issue:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041/comments/11
  https://patchwork.kernel.org/patch/5784701/ (the hack is at the bottom)
  Tested here:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041/comments/17

  Update: added some forensics in the paste (a long read):
  http://paste.ubuntu.com/24118478/

  -

  3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless 
Network Adapter (rev 32)
  qca6174 hw3.2 target 0x0503 chip_id 0x00340aff sub 1a56:1535

  Original message:
  --
  I experience a very poor 802.11ac performance of a QCA6174 Wireless card 
(Killer Wireless 1535).

  This is a dev version of Zesty with a recently released 4.10 kernel:

  uname -r
  4.10.0-9-generic

  dpkg -l linux-firmware | grep ii
  ii  linux-firmware 1.163all  Firmware for Linux kernel drivers

  lspci -vvv:

  ...
  3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless 
Network Adapter (rev 32)
  Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network 
Adapter
  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
  Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
  Kernel driver in use: ath10k_pci
  Kernel modules: ath10k_pci

  -

  Testing wireless speed with RT-87U 802.11ac router shows that the
  speed is only 27.3 megabits per second which is very low for an
  802.11ac card:

  iperf -c rtr
  
  Client connecting to rtr, TCP port 5001
  TCP window size: 85.0 KByte (default)
  
  [  3] local 10.10.10.78 port 48930 connected with 10.10.10.1 port 5001
  [ ID] Interval   Transfer Bandwidth
  [  3]  0.0-10.0 sec  32.6 MBytes  27.3 Mbits/sec

  

  For comparison, on the same network (from the same distance to the
  router) I have the following result with an Intel's card (on a 4.8
  kernel, different laptop):

  UX32LN:~$ lspci | grep 7260
  02:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)

  UX32LN:~$ iperf -c rtr
  
  Client connecting to rtr, TCP port 5001
  TCP window size: 85.0 KByte (default)
  
  [ 3] local 10.10.10.208 port 37196 connected with 10.10.10.1 port 5001
  [ ID] Interval Transfer Bandwidth
  [ 3] 0.0-10.1 sec 237 MBytes 198 Mbits/sec
  administrator@UX32LN:~$ lsp
  lspci lspcmcia lspgpot

  200 Mbps is much better.

  ---

  Back to the problematic card:

  Booted 16.04.2 with the rolling HWE kernel 4.8:

  journalctl -k | grep -i ath
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: enabling device ( 
-> 0002)
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: pci irq msi 
oper_irq_mode 2 irq_mode 0 reset_mode 0
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: Direct firmware load 
for ath10k/pre-cal-pci-:3b:00.0.bin failed with error -2
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: Direct 

[Kernel-packages] [Bug 1670041] Re: Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless 1535)

[dh]

My observations are mostly just significantly lower signal strength than
another laptop I have with intel wireless during side by side test.  I'm
receiving an intel AC 8265 (Model 8265NGW) in the coming days to do a
comparison in the same chassis for a fair test (in case of antenna
performance issues).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1670041

Title:
  Poor performance of Atheros QCA6174 802.11ac (rev 32) (Killer Wireless
  1535)

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Update: added some forensics in the paste (a long read):
  http://paste.ubuntu.com/24118478/

  TL;DR with a bit of intuition:
  We need a new firmware-5.bin from Qualcomm Atheros for this rev 32 card in 
order to make it work well - if anybody has contacts there it would be nice to 
ask them to upload this to the upstream linux-firmware tree.

  3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless 
Network Adapter (rev 32)
  qca6174 hw3.2 target 0x0503 chip_id 0x00340aff sub 1a56:1535

  
  Original message:
  --
  I experience a very poor 802.11ac performance of a QCA6174 Wireless card 
(Killer Wireless 1535).

  This is a dev version of Zesty with a recently released 4.10 kernel:

  uname -r
  4.10.0-9-generic

  dpkg -l linux-firmware | grep ii
  ii  linux-firmware 1.163all  Firmware for Linux kernel drivers

  lspci -vvv:

  ...
  3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless 
Network Adapter (rev 32)
  Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network 
Adapter
  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
  Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
  Kernel driver in use: ath10k_pci
  Kernel modules: ath10k_pci

  -

  Testing wireless speed with RT-87U 802.11ac router shows that the
  speed is only 27.3 megabits per second which is very low for an
  802.11ac card:

  iperf -c rtr
  
  Client connecting to rtr, TCP port 5001
  TCP window size: 85.0 KByte (default)
  
  [  3] local 10.10.10.78 port 48930 connected with 10.10.10.1 port 5001
  [ ID] Interval   Transfer Bandwidth
  [  3]  0.0-10.0 sec  32.6 MBytes  27.3 Mbits/sec

  

  For comparison, on the same network (from the same distance to the
  router) I have the following result with an Intel's card (on a 4.8
  kernel, different laptop):

  UX32LN:~$ lspci | grep 7260
  02:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)

  UX32LN:~$ iperf -c rtr
  
  Client connecting to rtr, TCP port 5001
  TCP window size: 85.0 KByte (default)
  
  [ 3] local 10.10.10.208 port 37196 connected with 10.10.10.1 port 5001
  [ ID] Interval Transfer Bandwidth
  [ 3] 0.0-10.1 sec 237 MBytes 198 Mbits/sec
  administrator@UX32LN:~$ lsp
  lspci lspcmcia lspgpot

  200 Mbps is much better.

  ---

  Back to the problematic card:

  Booted 16.04.2 with the rolling HWE kernel 4.8:

  journalctl -k | grep -i ath
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: enabling device ( 
-> 0002)
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: pci irq msi 
oper_irq_mode 2 irq_mode 0 reset_mode 0
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: Direct firmware load 
for ath10k/pre-cal-pci-:3b:00.0.bin failed with error -2
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: Direct firmware load 
for ath10k/cal-pci-:3b:00.0.bin failed with error -2
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: Direct firmware load 
for ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: could not fetch 
firmware file 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: qca6174 hw3.2 target 
0x0503 chip_id 0x00340aff sub 1a56:1535
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: kconfig debug 0 
debugfs 1 tracing 1 dfs 0 testmode 0
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: firmware ver 
WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad 
crc32 75dee6c5
  Mar 04 18:28:31 ubuntu kernel: ath10k_pci :3b:00.0: board_file api 2 
bmi_id N/A crc32 6fc88fe7
  Mar 04 18:28:34 ubuntu kernel: ath10k_pci :3b:00.0: htt-ver 3.26 wmi-op 4 
htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
  Mar 04 18:28:34 ubuntu kernel: ath: EEPROM regdomain: 0x6c
  Mar 04 18:28:34 ubuntu kernel: ath: EEPROM indicates we