Hi Arjen: You suggested just blacklisting the btusb device.  >    USB_BLACKLIST="8087:0a2b" I had considered trying just the btusb device (as you suggest)  approach, but I wanted to stop the failures, I really wanted to stop rebooting to enable bluetooth.  If I get good results over a few days, I'll try relaxing that setting. You also suggested:

I would expect similar results from just

   USB_BLACKLIST_BTUSB=1

In fact, I tried this first, it was not sufficient to stop the usb/bluetooth shutdowns/failures. I don't know if that is a bug or if I just didn't understand the semantics of that setting. With best regards: Bill From: Arjen de Korte Sent: Saturday, December 2, 2017 8:35 PM To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Bluetooth keeps failing in Tumbleweed, including the current version 20171125, Linux 4.14.1-1-default #1 SMP PREEMPT   Citeren Foolish Ewe :

Hello All:

Thank you Knurpht, I'm hoping this is the fix.  Following up in case  anybody else sees simillar symptoms.  So far my bluetooth has not  failed.  I'll post an update if it does, but I'm guardedly  optimistic that Knurpht's trick helped.

Bill

From: Foolish Ewe Sent: Friday, December 1, 2017 8:54 AM To: knurpht@opensuse.org Subject: Re: [opensuse-factory] Bluetooth keeps failing in  Tumbleweed, including the current version 20171125, Linux  4.14.1-1-default #1 SMP PREEMPT  

Hi Knurpht:

I rolled back bumblebee and zypper dup to get the latest changes, but had a bluetooth failure before taking your advice.  Here is my attempt to  follow this advice, I am now awaiting the outcome.

As per your recommendation I looked at lsusb $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"

You listed all USB devices. Not necessarily wrong, but probably the  following should be enough:      USB_BLACKLIST="8087:0a2b" I would expect similar results from just      USB_BLACKLIST_BTUSB=1 It might be worthwhile to investigate if the latter (commenting out  the line USB_BLACKLIST) is sufficient. If so, the default setting of  *not* blacklisting BTUSB devices might be a better default.

With best regards:

Bill

From: Knurpht - Gertjan Lettink Sent: Thursday, November 30, 2017 5:03 PM To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Bluetooth keeps failing in  Tumbleweed, including the current version 20171125, Linux  4.14.1-1-default #1 SMP PREEMPT  

Op donderdag 30 november 2017 17:52:33 CET schreef Foolish Ewe:

...

Hello Knurpht:

I had my laptop charging overnight and bluetooth did not fail, but as an experiment I removed the charging cable and the bluetooth went out shorty afterwards, so perhaps you and Arjen are on to something? I've rebooted since, while plugged in I see.

Please also try this: Use lsusb to find the manufacturor and device ID Now edit /etc/default/tlp ( needs root permissions ) and search for 'USB_BLACKLIST='. , and add the manufacturor and device ID between quotes, like below. USB_BLACKLIST="04e8:3292" for example.

This should prevent the USB device to be switched off by power saving settings.

...

Before pulling the power cable I saw:

$ sudo rfkill list [sudo] password for root: 0: phy0: Wireless LAN          Soft blocked: no          Hard blocked: no 5: hci0: Bluetooth          Soft blocked: no          Hard blocked: no

-- Gertjan Lettink, a.k.a. Knurpht

openSUSE Board Member openSUSE Forums Team

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Citeren Oliver Neukum :

Am Samstag, den 02.12.2017, 21:03 +0000 schrieb Foolish Ewe:

...

You suggested just blacklisting the btusb device.

 >    USB_BLACKLIST="8087:0a2b"

I had considered trying just the btusb device (as you suggest)  approach, but I wanted to stop the failures, I really wanted to stop rebooting to enable bluetooth.  If I get good results over a few days, I'll try relaxing that setting.

I cannot send a patch to disable runtime PM for a very common device upstream, unless I am positive it really is the device which causes the issue, as opposed to a wierd interaction of the device and your hub or chip set. So we really need to know whether blacklisting the device alone stops the problems.

I'm not sure what the problem is, but I see similar problems if I don't use either of the below lines in my /etc/default/tlp file USB_BLACKLIST="8087:07dc" or USB_BLACKLIST_BTUSB=1 Which isn't totally surprising, since the above device is the btusb device. A more generic fix may therefor be to default to the second line, blacklisting all btusb devices and advising people to try *not* blacklisting the btusb device in order to save power. It took me quite a while to figure out why my mouse wasn't working properly under Linux, while on the same machine, the same mouse worked well under Windows. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org