2

Bluetooth is a mess in linux. After hours of trying to make bluetooth even turn on, I found out that adding this to the grub fixed the issue to where now it's at least turning on albeit not pairing with any devices.

I went and reconfigured my GRUB legacy in /etc/default/grub and added

GRUB_CMDLINE_LINUX_DEFAULT=btusb.enable_autosuspend=n

But can someone tell me what this actually did and why it worked?

My guess is it's telling bluetooth to not suspend automatically but why would bluetooth do that in the first place when turning on my arch device?

I am using Arch linux on a dell with Intel centrum 1000 N

1 Answer 1

0

First, let's sort out which Bluetooth adaptor you really have. Given the networking specifications of the Intel Centrino WirelessN 1000 adaptor say it doesn't support Bluetooth and it's a PCIe Half Mini Card, and that the btusb params referenced above are influencing your settings, you should look through the output of lsusb -tv to find which USB Bluetooth adaptor is installed in your Dell. You should verify that you're not using any of the fake Barrot 8041A02 clones, which are known have various issues with suspend and resume regardless of how btusb.enable_autosuspend is set.

In the latest stable kernel (v5.12 at the time of writing), the btusb.enable_autosuspend boolean kernel parameter affects if usb_enable_autosuspend will be called when probing the btusb device.

As documented in Power Management for USB kernel docs:

Drivers can enable autosuspend for their devices by calling:

usb_enable_autosuspend(struct usb_device *udev);

in their probe() routine, if they know that the device is capable of suspending and resuming correctly. This is exactly equivalent to writing auto to the device’s power/control attribute. Likewise, drivers can disable autosuspend by calling:

usb_disable_autosuspend(struct usb_device *udev);

This is exactly the same as writing on to the power/control attribute.

Sometimes a driver needs to make sure that remote wakeup is enabled during autosuspend. For example, there’s not much point autosuspending a keyboard if the user can’t cause the keyboard to do a remote wakeup by typing on it. If the driver sets intf->needs_remote_wakeup to 1, the kernel won’t autosuspend the device if remote wakeup isn’t available. (If the device is already autosuspended, though, setting this flag won’t cause the kernel to autoresume it. Normally a driver would set this flag in its probe method, at which time the device is guaranteed not to be autosuspended.)

Without more any further details about your Dell and given the above docs, I can only assume that either:

  1. You have a USB Bluetooth device that is powered on long enough to be discoverable, but was autosuspended before you completed the pairing process from another device.
  2. You have successfully paired, but your adaptor has gone to sleep and your HID keyboard/mouse can't wake it up again.

You should check the output of grep . /sys/bus/usb/devices/*/power/wakeup against the output of lsusb -tv to confirm that /sys/bus/usb/devices/${Bus}-${Port}/power/wakeup is enabled for your Bluetooth adaptor. You can enable wakeup on all USB devices with the following command in order to test without having to adjust kernel boot parameters and reboot:

echo enabled | sudo tee -a /sys/bus/usb/devices/*/power/wakeup

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy