|
Bugzilla – Full Text Bug Listing |
| Summary: | 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 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Foolish Ewe <foolishewe> |
| Component: | Kernel | Assignee: | Oliver Neukum <oneukum> |
| Status: | RESOLVED NORESPONSE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | acho, foolishewe, forgotten_LWuDZpRgIk, jcheung, jslaby, oneukum, tiwai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Foolish Ewe
2017-11-29 18:48:55 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? Please check whether blacklisting 8087:0a2b alone is enough. Trying it, I'll follow up if there are issues or not. Closing due to lack of response. 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. 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. 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. 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. 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 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? Making no progress |