# Bluetooth not working after suspend [WORKAROUND]

## selig

I have just upgraded to 2.6.39 and am seeing a strange behaviour with my Bluetooth (USB) adapter. It is on a Toshiba Satellite U400-18M.

After I suspend to RAM and resume the computer, bluetooth is not working. I am using KDE and the bluetooth icon in KDE is simply not present after resuming.

I did /etc/init.d/bluetooth restart but that did not help. However, I tried it a second time and then bluetooth started working again! The behaviour is consistent, I tried suspending the machine a couple of times and it takes two bluetooth service restarts until it starts working after resume. I guess that something changed in 2.6.39 (I had been using 2.6.38 before that) that causes this behaviour but I really do not know what...

Thanks for any ideas!Last edited by selig on Tue Aug 16, 2011 12:00 pm; edited 1 time in total

----------

## billium

I had problems with bluetooth that started with kernel 2.6.39 but disappeared with kernel 3, though not the same symptom as you describe.

----------

## vr13

 *selig wrote:*   

> I have just upgraded to 2.6.39 and am seeing a strange behaviour with my Bluetooth (USB) adapter. It is on a Toshiba Satellite U400-18M.
> 
> After I suspend to RAM and resume the computer, bluetooth is not working. I am using KDE and the bluetooth icon in KDE is simply not present after resuming.
> 
> I did /etc/init.d/bluetooth restart but that did not help. However, I tried it a second time and then bluetooth started working again! The behaviour is consistent, I tried suspending the machine a couple of times and it takes two bluetooth service restarts until it starts working after resume. I guess that something changed in 2.6.39 (I had been using 2.6.38 before that) that causes this behaviour but I really do not know what...

 

reproduced on hp compaq nw9440 notebook with similar symptoms. also works fine with 2.6.38 kernel. seems the .39 kernel does not power up usb controller (dmesg citation at resume from suspend time):

 *Quote:*   

> usb 2-1: USB disconnect, device number 7
> 
> btusb_intr_complete: hci0 urb ffff8800b4b05e40 failed to resubmit (19)
> 
> btusb_bulk_complete: hci0 urb ffff8800b4b05b40 failed to resubmit (19)
> ...

 

ERRNO -19 stands for ENODEV; this diagnostic comes from drivers/bluetooth/btusb.c when submitting appropriate urb

----------

## vr13

apparently i found a workaround pushing custom quirk powering up bluetooth at resume-from-suspend time (/etc/pm/sleep.d/98bluetooth), at least now it works for me:

```
#!/bin/sh

. "${PM_FUNCTIONS}"

case "$1" in

   hibernate|suspend)

      ;;

   thaw|resume)

      echo on > /sys/bus/usb/devices/2-1/power/control

      # replay kernel event to make sure bluetoothd catched it

      udevadm trigger --subsystem-match=bluetooth --action=add

      ;;

   *) exit $NA

      ;;

esac
```

this might be not a kernel issue, probably something around udev and/or pm-utils

----------

## selig

Thanks a lot! This fixed it for me too. I did not need the "power" line, just the udevadm trigger.

----------

## selig

Hmm actually I need to include a delay in the script, otherwise it gets called too soon and does not help. So maybe the device gets woken up later in the new kernel version?

----------

## vr13

i've also got back to the same problem. seems it tends to appear after number of suspend/resume cycles

also tried to switch to 3.0.x - no changes whilst the 2.6.38 kernel behaves properly. among other things i played a bit with is new versions of udev (171-r1) and bluez (4.96-r1): that brought no news though

----------

