Description of problem: Fedora 28 enabled auto suspend for bluetooth USB dongles, this break many HID devices as they will require to "wakeup" the device to perform an action. For example, with my bluetooth gamepad if I don't press any button for 1-2 seconds, I need to press it twice to get it recognized by Fedora. This is just painful. Version-Release number of selected component (if applicable): 28 How reproducible: always Steps to Reproduce: 1. Use fedora 28 2. Use a bluetooth dongle and a gamepad 3. Don't touch your gamepad for 2 seconds, then press a button. Actual results: We need to press the button twice.
This sounds like it is an issue with your specific bluetooth dongle. This feature is working fine for most users. Can you provide lsusb output and attach "dmesg" output please?
Note that as a workaround (and to confirm this issue is the cause) you can add "btusb.enable_autosuspend=0" to your kernel commandline.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.17.7-200.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The btusb.enable_autosuspend=0 indeed works. I personally think this autosuspend is pretty useless. People who really want to save power will just disable bluetooth completely instead of saving 0.4W by autosuspending the device. I immediately known that my gamepad was running into troubles because of this "improvement" setting because I experienced the same issue in a USB keyboard where autosuspend was enabled too. Now I imagine a Linux newcomer that has no ideas of this, will get troubles with its devices because of this autosuspend everywhere. What will he think? 1. Either the device look broken (terribly wrong) 2. Linux is unstable IMHO, enabling autosuspend for USB devices is wrong, and there are many links why it is. Or at least if you still don't want to disable, do not suspend after 2 seconds which is definitely to low. https://www.kirsle.net/wiki/PowerTOP-and-USB-Autosuspend https://askubuntu.com/questions/678779/powertop-auto-tune-without-messing-with-usb-and-touchpad https://hamwaves.com/usb.autosuspend/en/index.html
(In reply to David Demelier from comment #4) > The btusb.enable_autosuspend=0 indeed works. Works for what purpose / works to fix which problem? When you add a comment to a bug, or file a new bug please learn to explain your problem with as much detail as possible. What hardware are you using? What bluetooth controller is this hardware using? What is happening which you believe is a problem? What would you expect to happen instead ? What is the new behavior after passing btusb.enable_autosuspend=0 ?
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.18.10-300.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
> Works for what purpose / works to fix which problem? The gamepad does not have any kind of resume action needed to make my buttons works. In short: I don't need to press twice to make the first press awake the controller and the second press the actual code. Again, I encourage you to read the links I've posted, you will have more than one problem by autosuspending all usb devices. This should be let to the user discretion, not by default in the system. I already had the same trouble with a USB keyboard and powertop. I'll give you the USB id once I get my hand on the bluetooth device too.
(In reply to David Demelier from comment #7) > Again, I encourage you to read the links I've posted, you will have more > than one problem by autosuspending all usb devices. Except that we are not autosuspending ALL usb devices. Because problems with e.g. USB keyboards are well known. We are only autosuspending all USB bluetooth-controllers and this is the only open bug about any issues caused by this. > This should be let to > the user discretion, not by default in the system. Setting sane defaults is important to make sure that laptops have decent battery life. > I already had the same trouble with a USB keyboard and powertop. And we are not touching USB keyboards at all so this is not relevant at all. I'm sorry if this sounds a bit harsh, but what is your purpose im filing this bug? Do you want me to help you are do you just want to complain?
> Except that we are not autosuspending ALL usb devices. Because problems with e.g. USB keyboards are well known. We are only autosuspending all USB bluetooth-controllers and this is the only open bug about any issues caused by this. Yes, the Linux desktop market share is about 2%. I think the bluetooth user within these 2% should not exceed 0.2% (very raw guess). So this is probably a blanket statement. > Setting sane defaults is important to make sure that laptops have decent battery life. It isn't a sane default. As explained several times in this bug, it requires to wake up connected devices to make them working. I still don't understand why you still want to save less than 1W per hour in the cost of having a subsystem in trouble as I already explained, people who really want to save power use the system kill switch to disable bluetooth completely (or using rfkill if no button are available). The only way to fix that problem is to revert this auto suspend for bluetooth controllers. Or at least increase the timeout because 2 seconds is absolutely insane. If I don't touch my mouse for 2 seconds I need toshake it several times to wake up the bluetooth subsystem. I love saving 1W per hour and lose time like that. FWIW, this is the bluetooth controller (a USB dongle). But the problem is exactly the same with the original HP builtin bluetooth controller (a old 2.0 chip though). $ lsusb -v [... other devices ...] Bus 008 Device 002: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 1 bDeviceProtocol 1 bMaxPacketSize0 64 idVendor 0x0b05 ASUSTek Computer, Inc. idProduct 0x17cb Broadcom BCM20702A0 Bluetooth bcdDevice 1.12 iManufacturer 1 Broadcom Corp iProduct 2 BCM20702A0 iSerial 3 5CF37087B77A bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00da bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 3 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0019 1x 25 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0019 1x 25 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 4 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0021 1x 33 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0021 1x 33 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 5 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 254 Application Specific Interface bInterfaceSubClass 1 Device Firmware Update bInterfaceProtocol 1 iInterface 0 Device Firmware Upgrade Interface Descriptor: bLength 9 bDescriptorType 33 bmAttributes 5 Will Not Detach Manifestation Tolerant Upload Unsupported Download Supported wDetachTimeout 5000 milliseconds wTransferSize 64 bytes bcdDFUVersion 1.10 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)
Can you please provide the output of "dmesg" directly after boot?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Hello. I have an Intel onboard Bluetooth and encountered the same issue. This issue does not occur when running off Windows 7. The device I connected to (a Vizio soundbar) shuts off after a few minutes when connecting from Linux; when connected to it from Windows or my Android device, this issue does not occur. By disabling btusb autosuspend, the issue is resolved.
Hi, I acquired a new ThinkCentre m920 tiny that comes with a combo wifi / Bluetooth 5.0 chipset. As you may guess, I'm experiencing a new trouble thanks to this useless autosuspend non-feature. Now if I try to connect a gamepad, it immediately disconnects and start rumbling forever, GNOME sees it as disconnected and I have to disable autosuspend to fix the issue. Is there any chance someone else that is not stubborn like Hans de Goede will understand that this feature cause more harm than good? I mean, literally saving 0.01% power consumption to break all bluetooth users. People who don't use bluetooth disable bluetooth completely. Please revert this “feature”. Just FIW: $ sudo lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 045e:0800 Microsoft Corp. Bus 001 Device 002: ID 152d:2339 JMicron Technology Corp. / JMicron USA Technology Corp. JM20339 SATA Bridge Bus 001 Device 004: ID 8087:0aaa Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub $ sudo lspci 00:00.0 Host bridge: Intel Corporation 8th Gen Core 4-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S] (rev 08) 00:02.0 VGA compatible controller: Intel Corporation 8th Gen Core Processor Gaussian Mixture Model 00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10) 00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10) 00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10) 00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10) 00:16.3 Serial controller: Intel Corporation Cannon Lake PCH Active Management Technology - SOL (rev 10) 00:17.0 SATA controller: Intel Corporation Cannon Lake PCH SATA AHCI Controller (rev 10) 00:1f.0 ISA bridge: Intel Corporation Q370 Chipset LPC/eSPI Controller (rev 10) 00:1f.3 Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10) 00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller (rev 10) 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10) [bluetooth]# show Controller 5C:87:9C:A9:92:F4 (public) Name: tomate Alias: tomate Class: 0x001c0104 Powered: yes Discoverable: no Pairable: yes UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb) UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb) UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb) UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb) UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0532 Discovering: no
(In reply to namasteneko from comment #13) > Hello. > > I have an Intel onboard Bluetooth and encountered the same issue. This issue > does not occur when running off Windows 7. The device I connected to (a > Vizio soundbar) shuts off after a few minutes when connecting from Linux; > when connected to it from Windows or my Android device, this issue does not > occur. > > By disabling btusb autosuspend, the issue is resolved. Are you playing audio to the soundbar when this happens?
(In reply to David Demelier from comment #14) > Hi, > > I acquired a new ThinkCentre m920 tiny that comes with a combo wifi / > Bluetooth 5.0 chipset. > > As you may guess, I'm experiencing a new trouble thanks to this useless > autosuspend non-feature. Now if I try to connect a gamepad, it immediately > disconnects and start rumbling forever, GNOME sees it as disconnected and I > have to disable autosuspend to fix the issue. > > Is there any chance someone else that is not stubborn like Hans de Goede > will understand that this feature cause more harm than good? I mean, > literally saving 0.01% power consumption to break all bluetooth users. I'm guessing that no-one else is going to respond to this, so you will have to do with me. But no worries I'm generally know to be a quite reasonable person. > People who don't use bluetooth disable bluetooth completely. And that is where we disagree, people who never use bluetooth will hopefully disable it for some extra saving. People who occasionally use a bluetooth mouse or headset will keep it on. I think it is reasonable for those people to expect bluetooth support not to needlessly burn through extra power when no bluetooth devices are active. Now lets talk some numbers. Last time anyone tried to estimate the amount of Fedora users, the number was around 1 million users. And here we have 3 of a million users who are having a problem with bluetooth combined with autosuspend of USB BT dongles. I realize that not everyone who has an issue will file a bug. But in my experience if a problem is really wide spread we will see a lot more complaints. Also note that ChromeOS also enables autosuspend for BT devices by default, that is another group of millions of users, I personally would like to think that the ChromeOS team at google knows what it is doing here. As for the powersaving when a modern laptop is idle with the screen on it uses aprox. 4-5 watts of power. On a typical laptop config BT is the only USB devices which does not autosuspend when we would do as you request. That keeps the XHCI controller awake which burns through aprox. 0.4W of power, IOW to fix a corner case very few people are using you want us to increase the base-level power-consumption of all laptops running Fedora by 10%, reducing the battery life for light tasks like office work or reading websites by close to 10%. I hope you can see that it is not reasonable to regress the power-consumption of all Fedora laptop users by 10% just to fix a corner case. Know with that out of the way, lets look at the actual problem, both the original reporter and you are using a gamepad, combined with an Intel bluetooth receiver, and in your specific case your gamepad has forcefeedback. I guess it would not be unreasonable to disable autosuspend while a gamepad is connected. But code-wise that is sorta hard, the next best thing would be to disable autosuspend while a HID device is connected, that would possibly also make mice/keyboards more responsive. I will try to write a patch to disable autosuspend while a HID device is connected.
(In reply to Hans de Goede from comment #16) > I will try to write a patch to disable autosuspend while a HID device is connected. Ok, so that is not as easy as I expected that it would be and some quick tests have shown that this also is undesriable, because even when a HID device is connected, we still end up auto-suspended quite often, which is good from a power-management pov. I have learned 2 things: 1) On my desktop with a: 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle, and a bluetooth keyboard, the first keypress after the USB dongle has autosuspended arrives on the desktop just fine, so this is not a generic problem which all HID devices have. 2) The code for Intel BT receivers connected over an UART rather then over USB: drivers/bluetooth/hci_intel.c, which is written by _Intel_ itself also uses autosuspend, with an even more aggressive timeout of 1 second. So all in all this points to an issue with either Intel BT receivers + HID devices in general, Intel BT receivers + some specific HID devices / gamepads. The 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle type devices can be bought on e.g. aliexpress for a couple of dollars perhaps you can get one and give things a try with such a dongle? It will probably be a bit tricky to disable the Intel BT though... Anyways it is Saturday now and I really should not be working in the weekend. I will try to reproduce this on a laptop with Intel BT on Monday, I even have a BT gamepad to try this with.
Ok, so I've run a whole bunch of tests, but I am afraid that I cannot reproduce this problem. I've connected a BT keyboard+touchpad, a BT mouse and a clone BT PS3 controller/gamepad to 2 different laptops with Intel bluetooth. The keyboard / mouse work fine and after waiting 2 seconds and confirming that the device has autosuspended, pressing a key / button will register, no key / button presses are last after the autosuspend, and there is no noticeable delay. The behavior with the clone BT PS3 controller/gamepad is different, in that case once it is connected the USB device never autosuspends (and no button presses ever get lost). The same behavior is also seen for all 3 devices when connected to my desktop machine with a "Cambridge Silicon Radio, Ltd Bluetooth Dongle". I guess that in both your cases when the gamepad is connected autosuspend still kicks in. but lets verify that. Please do "lsusb -t" in the output of that should be 2 lines referring to a device using the btusb device, e.g. on my desktop these 2 lines are: |__ Port 12: Dev 13, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 12: Dev 13, If 0, Class=Wireless, Driver=btusb, 12M Notice the "Port 12" part, we need this to watch the autosuspend, e.g. on my desktop to observe the autosuspend status I do: watch -n .2 cat /sys/bus/usb/devices/1-12/power/runtime_status Please adjust the "-12" part accordingly, note this assumes that no hubs are in between the xhci controller and the BT receiver, but that is a reasonable assumption. If you have no bluetooth devices connected and you are not disabling autosuspend, then the output of the watch command should be: suspended Note watch will reread the file and display the new value every .2 seconds. If you know connect your BT gamepad, then the status should become "active". Please check if it stays active all the time, or if it goes back to "suspended" after not touching anything on the gamepad for 2 seconds. Please let me know the outcome of this check. Also can you please let me know which brand and model gamepad you are using? Please run the following command with the gamepad connected: ls /sys/bus/hid/devices And copy and paste the output here, this will give me the vendor and product ids of your gamepad. Also please run: "lspci -nn" and copy and paste the output here, that will let me know the exact model of your wifi/bt card.
I've been having a similar problem with an Intel Bluetooth controller (not a dongle). The occurrence is random and unpredictable. A reboot is required to recover. Interestingly, after a restart (without power down), there is a hang-up in the start-up cause by the very same device, and also error -110. An actual power cycling is required to recover from that. I'm going to try the btusb.enable_autosuspend=0 kernel option to see if that helps. I tried overriding power/control with a udev file, to no effect. Here are is the dmesg output filtered for the particular device showing the problem: [ 2.627510] usb 1-9: new full-speed USB device number 3 using xhci_hcd [ 2.756898] usb 1-9: New USB device found, idVendor=8087, idProduct=0a2a, bcdDevice= 0.01 [ 2.758200] usb 1-9: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 5114.423575] usb 1-9: Failed to suspend device, error -110
It appears this bug was missed in the EOL closure for F28 on 2019-05-28. If this bug still exists on supported versions, please reopen and update the version. If you cannot update the version, please needinfo the assignee.