Bug List: (3 of 49) First Last Prev Next   Show last search results
Bug 1070434 - Bluetooth/USB keeps failing in Tumbleweed in intel 8265 Bluetooth + Wifi and intel Sunrise Point-LP USB-3.0 xHCI Controller, including the current version 20171125, Linux 4.14.1-1-default #1 SMP PREEMPT
Summary: Bluetooth/USB keeps failing in Tumbleweed in intel 8265 Bluetooth + Wifi and...
Status: RESOLVED NORESPONSE
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Current
Hardware: x86-64 All
: P5 - None : Major with 1 vote (vote)
Target Milestone: ---
Assignee: Oliver Neukum
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-29 18:48 UTC by Foolish Ewe
Modified: 2020-12-07 11:33 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Foolish Ewe 2017-11-29 18:48:55 UTC 
Hello All:

I have been running Linux on this machine with unstable bluetooth
since October 21, 2017, and bluetooth keeps failing after working for some reasonably long period (minutes or hours, possibly due to usb issues).

The machine's specs per the vendor are  https://support.hp.com/us-en/document/c05787871. 
The hardware is pretty new hence the need for a new kernel
(4.6+ according to https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi ofr intel 8265 chipset),
motivating me to try tumbleweed.

The wlan and bluetooth chip according to the linux drivers is:
4.830236] iwlwifi 0000:3b:00.0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230

I dual boot into windows and the bluetooth seems reliable under windows, so I am ruling out hardware issues.
On a side note, I put Bumblebee on this system last night (tainting my kernel)  to address screen flicker, but the bluetooth issue predates that, the logs attached are prior to the installation of bumblebee.

I am using opensuse tumbleweed for the last 6 weeks or so and keep having my bluetooth support fail while I'm using my laptop.  I'm currently up to date (as of a few hours ago):
 
$uname -a
Linux linux 4.14.1-1-default #1 SMP PREEMPT Tue Nov 21 18:26:02 UTC 2017 (a5bca71) x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20171125"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="20171125"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20171125"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

Consider the following log, I think bluetooth failed around 21:53:54, what could be going on here?  Is this an usb error or bluetooth specific?  What information do I need to track this down?
$journalctl -all
[Stuff removed for brevity]
 
Nov 28 21:39:08 linux dbus[1126]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Nov 28 21:39:18 linux systemd[1]: Starting Cleanup of Temporary Directories...
Nov 28 21:39:18 linux systemd[1]: Started Cleanup of Temporary Directories.
Nov 28 21:41:51 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:43:39 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:44:20 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:47:20 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:47:28 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:52:04 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:53:54 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 21:53:54 linux kernel: xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
Nov 28 21:53:54 linux kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Nov 28 21:53:54 linux kernel: usb 1-5: USB disconnect, device number 2
Nov 28 21:53:54 linux kernel: usb 1-7: USB disconnect, device number 3
Nov 28 21:53:54 linux systemd[1]: Starting Load/Save RF Kill Switch Status...
Nov 28 21:53:54 linux systemd[1]: bluetooth.target: Unit not needed anymore. Stopping.
Nov 28 21:53:54 linux systemd[1]: Stopped target Bluetooth.
Nov 28 21:53:54 linux systemd[1]: Started Load/Save RF Kill Switch Status.
Nov 28 21:53:54 linux bluetoothd[1117]: Endpoint unregistered: sender=:1.39 path=/MediaEndpoint/A2DPSource
Nov 28 21:53:54 linux bluetoothd[1117]: Endpoint unregistered: sender=:1.39 path=/MediaEndpoint/A2DPSink
Nov 28 21:53:54 linux dbus[1126]: [system] Rejected send message, 1 matched rules; type="error", sender=":1.39" (uid=1000 pid=2094 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.1" (uid=0 pid=1117 comm="/usr/lib/bluetooth/bluetoothd ")
Nov 28 21:53:54 linux dbus[1126]: [system] Rejected send message, 1 matched rules; type="error", sender=":1.39" (uid=1000 pid=2094 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.1" (uid=0 pid=1117 comm="/usr/lib/bluetooth/bluetoothd ")
Nov 28 21:53:54 linux dbus[1126]: [system] Rejected send message, 1 matched rules; type="error", sender=":1.39" (uid=1000 pid=2094 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.1" (uid=0 pid=1117 comm="/usr/lib/bluetooth/bluetoothd ")
Nov 28 21:53:54 linux dbus[1126]: [system] Rejected send message, 1 matched rules; type="error", sender=":1.39" (uid=1000 pid=2094 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.1" (uid=0 pid=1117 comm="/usr/lib/bluetooth/bluetoothd ")

After a reboot, I bluetooth failed pretty quickly, I see:
ov 28 22:02:44 linux nm-dispatcher[2752]: req:2 'connectivity-change': start running ordered scripts...
Nov 28 22:02:51 linux PackageKit[2580]: daemon quit
Nov 28 22:02:51 linux packagekitd[2580]: Source ID 11 was not found when attempting to remove it
Nov 28 22:02:57 linux kernel: xhci_hcd 0000:00:14.0: xHC is not running.
Nov 28 22:02:57 linux kernel: xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
Nov 28 22:02:57 linux kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Nov 28 22:02:57 linux kernel: usb 1-5: USB disconnect, device number 2
Nov 28 22:02:57 linux kernel: usb 1-7: USB disconnect, device number 3
Nov 28 22:02:57 linux systemd[1]: Starting Load/Save RF Kill Switch Status...
Nov 28 22:02:57 linux systemd[1]: bluetooth.target: Unit not needed anymore. Stopping.
Nov 28 22:02:57 linux systemd[1]: Stopped target Bluetooth.

What information would help to track down and fix this problem?

Thanks:

Bill
Comment 1 Foolish Ewe 2017-12-02 20:06:13 UTC 
Prior to this bug reaport I opened a discussion on the opensuse factory mailing list, see https://lists.opensuse.org/opensuse-factory/2017-11/msg00718.html.

Knurpht and Arjen suggested that power management might be shutting down the usb devices as a likely cause.  I've adopted Knurpht's suggested counter measures, namely:



I looked at lsusb to get and recorded the device ID's.
$lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 002: ID 064e:3401 Suyin Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 7: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 7: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M

I then blacklisted the bluetooth device in /etc/default/tlp:

# Exclude listed devices from USB autosuspend (separate with spaces).
# Use lsusb to get the ids.
# Note: input devices (usbhid) are excluded automatically
#USB_BLACKLIST="1111:2222 3333:4444"
USB_BLACKLIST="1d6b:0002 1d6b:0003 064e:3401 8087:0a2b"

I also enabled blacklisting of USB_BLACKLIST_BTUSB based on a different hint
(that setting alone was not sufficient) as seen in the following diff
showing all changes to /etc/default/tlp
5diff /etc/default/tlp /etc/default/tlp.original 
207d206                                                                                                                                                             
< USB_BLACKLIST="1d6b:0002 1d6b:0003 064e:3401 8087:0a2b"                                                                                                           
211,213c210                                                                                                                                                         
< #   Changed setting original commented out                                                                                                                        
< #USB_BLACKLIST_BTUSB=0                                                                                                                                            
< USB_BLACKLIST_BTUSB=1                                                                                                                                             
---                                                                                                                                                                 
> USB_BLACKLIST_BTUSB=0  

So far 2 days an no bluetooth outages, if I get another bluetooth failure,
I'll send an update, but I'm guardedly optimistic that this is the fix.

I would propose changing the default /etc/default/tlp settings to match the
ones here if this is indeed the fix.

I am curious why setting USB_BLACKLIST_BTUSB=1 wasn't enough to fix the issue?
Comment 2 Oliver Neukum 2017-12-05 15:18:37 UTC 
Please check whether blacklisting 8087:0a2b alone is enough.
Comment 3 Foolish Ewe 2017-12-06 06:08:16 UTC 
Trying it, I'll follow up if there are issues or not.
Comment 4 Jiri Slaby 2018-02-08 15:31:26 UTC 
Closing due to lack of response.
Comment 5 Forgotten User LWuDZpRgIk 2018-05-04 22:34:50 UTC 
In case anyone is interested:

I had the exact same problem on a HP ProBook G5 with OpenSuse Leap 15 beta (kernel 4.12.14-lp150.10-default). The ProBOok G5 also uses the 8087:0a2b device.

Blacklisting 8087:0a2b is sufficient to prevent the Bluetooth controller from disappearing. So blacklisting the other USB devices and the USB_BLACKLIST_BTUSB=1 setting are not necessary.
Comment 6 Oliver Neukum 2018-05-07 14:51:53 UTC 
We need to know whether we got that from upstream.
Please test whether this kernel:

http://kernel.suse.com/packages/vanilla

works without the blacklist.
Comment 7 Forgotten User LWuDZpRgIk 2018-05-08 10:39:47 UTC 
Installed vanilla kernel of the day (4.17.0-rc4-1.g8257a00-vanilla) via the suggested package, after disabling secure boot.

With that kernel it is not needed anymore to blacklist the 8087:0a2b device in /etc/default/tlp. Bluetooth controller doesn't disappear anymore.
Comment 8 Forgotten User LWuDZpRgIk 2018-05-08 12:36:54 UTC 
Wait, I'm also not able to reproduce the issue anymore with kernel 4.12.14-lp150.10-default. Maybe it depends on the battery level ? I'll test again when the battery is getting empty.
Comment 9 Forgotten User LWuDZpRgIk 2018-05-08 21:38:48 UTC 
When battery is at 20%:

- bluetooth controller disappears within 1 minute with kernel 4.12.14-lp150.10-default
- bluetooth controller works as expected with kernel 4.17.0-rc4-1.g8257a00-vanilla
Comment 10 Oliver Neukum 2018-05-14 12:59:21 UTC 
This means tha this bug depends on some ACPI powersave feature. Meaning that your specific hardware is needed to replicate it.

Al, should we disable runtime PM for releases based on older kernels or do we need the code for DMI based blacklists?
Comment 12 Oliver Neukum 2020-12-07 11:33:57 UTC 
Making no progress
Bug List: (3 of 49) First Last Prev Next   Show last search results