I can confirm this problem in it's entirety, the mouse was working fine with the last 2.6.31 kernel and not with kernel-PAE-2.6.32.9-67.fc12.i686.

The mouse is a bluetooth Logitech MX900.

I'd like to chime in to say I've got the same behavior with my Dell Wireless Bluetooth 350 built-in BT adapter on a Latitude D410 running F12 2.6.32.9-PAE paired to a Microsoft Bluetooth Notebook Mouse 5000 which worked perfectly before on all the previous kernels in the 2.6.31.x line.  Still works, but is laggy after its been idle for more than a few seconds and is spamming my /var/log/messages file with messages like 

Mar  8 14:30:24 Latitude-D410 kernel: btusb_bulk_complete: hci0 urb f1bc0f80 failed to resubmit (1)

every time the mouse appears to go idle.  Otherwise, pairing works, trust works, and tracking once you get over the initial lag goes away works as usual.

Oh and just to add, I think bugs 562502 and 570184 are possibly related to this one...just a thought.

The bug is still present in kernel-PAE-2.6.32.9-70.fc12.i686

This bug make the bluetooth mouse completely unusable because of the small lag at each start of movement.

All of you have device with ID 0a5c:2145 ? I tried reproduce on 0a5c:2110 without a luck :(

What a minute ... I have these "failed to resubmit" errors in dmesg, but there is no lag, hmmm.

Ok, I have the lag as described in Comment 0 - lag is only when mouse is idle for some time. I don't think is this something like "mouse completely unusable" like described in Comment 4. Jean, perhaps you have different bug?

No, i have the same bug. My mouse seems to sleep at a really short interval (2 seconds of no use), so basically, every time I move the mouse, the lag is there and I miss where I wanted to click. If I always move my mouse (ex : in Gimp), the mouse is fine.

I check to try to change my mouse idle time but I haven't found anything yet.

I have:

Bus 003 Device 002: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

And while the lag is quite annoying, it isn't exactly unusable for me (maybe its because my mouse sleeps after closer to like 5 or so seconds and doesn't disconnect the bluetooth link entirely for upwards of 15-20 minutes).

But I work with this laptop in this configuration while at work, roughly 8 hours a day, 5 days a week, so my messages log file is spammed to death with those "failed to submit" errors.

Just to get an idea, if I watch the /var/log/messages file...if I move the mouse and wait a few seconds, this happens in one quick spurt (using tail -f /var/log/messages):

Mar 12 08:51:39 Latitude-D410 kernel: btusb_intr_complete: hci0 urb f450f980 failed to resubmit (1)
Mar 12 08:51:39 Latitude-D410 kernel: btusb_bulk_complete: hci0 urb f1ce9f00 failed to resubmit (1)
Mar 12 08:51:39 Latitude-D410 kernel: btusb_bulk_complete: hci0 urb f1ce9a00 failed to resubmit (1)

This happens everytime I don't move the mouse for a few seconds...I haven't tried using my Bluetooth adapter with anything else in a long while so I don't know how else it would react with any other device.  My current phone's bluetooth is crippled beyond belief so I can't do much with it.  All I have is a really old bluetooth ear piece I use with the phone, I might be able to pair it with the laptop and see how it works with this kernel and see if this bug also affects it to get a better picture of what's going on.  Thanks!

*** Bug 570184 has been marked as a duplicate of this bug. ***

Created attachment 399662 [details]
lsusb -v for Dell Wireless 350 Bluetooth adapter

I have attached the trimmed output of lsusb -v for the Bluetooth adapter built into my Dell Latitude D410.

The problem is that we enable USB autosuspend for btusb. I think autosuspend should be disabled by default for this device.

You can connfigure autosuspend using sysfs:

[root@green ~]# readlink -f /sys/class/bluetooth/hci0
/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/bluetooth/hci0
[root@green ~]# cd `readlink -f /sys/class/bluetooth/hci0`
[root@green hci0]# cd ../../../power/

to disable it do

[root@green power]# echo on > level 

or change autosuspend time to other value (in seconds)

[root@green power]# echo 20 > autosuspend 
[root@green power]# echo auto > level

Created attachment 399667 [details]
lsusb -v for BestBuy brand mini Bluetooth adapter in my desktop

I also have some Best Buy brand (RocketFish or something) connected to my desktop at home running F12 x86_64 that while I do not use, did start to mention that "failed to resubmit" errors early on in the dmesg output then nothing (presumably because I don't currently use it as I gave away the bluetooth keyboard and mouse I once used with it).

Matthew,

Can we fix that mouse lag with autosuspend enabled ? If not, I think we should not enable autosuspend by default for btusb.

Hm. Yes, this is a problem. We may need to work out a way to be smarter about this - autosuspend is enough of a power saving that we don't want to disable it entirely on btusb, but it does need to interact better with input devices.

Thanks Stanislaw, that seems to fix it for me. With "on" in level, the mouse does not seems to go into sleep anymore and does not lag. However, I don't know the effect it will have on the battery of both the laptop and the mouse. We will see.

Just for your information, in autosuspend, I have the value of 2 seconds by default, so the mouse sleeps often. Maybe I will just try to augment this value to something that will best fit my mouse use.

Thank you!

Is there an easier way to specify the time-out delay to something higher than whatever the default is at boot time maybe?  And can we get rid of the errors in the log?  I mean, I'm all for power savings, as long as it can be configured and it doesn't cause errors.

(In reply to comment #13)
> [root@green power]# echo on > level 

Thanks, that works around the problem for me.

The bug is still present in kernel-PAE-2.6.32.11-99.fc12.i686 but the workaround continue to fix that problem.

(In reply to comment #13)
> The problem is that we enable USB autosuspend for btusb. I think autosuspend
> should be disabled by default for this device.
> 
> You can connfigure autosuspend using sysfs:
> 
> [root@green ~]# readlink -f /sys/class/bluetooth/hci0
> /sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/bluetooth/hci0
> [root@green ~]# cd `readlink -f /sys/class/bluetooth/hci0`
> [root@green hci0]# cd ../../../power/
> 
> to disable it do
> 
> [root@green power]# echo on > level 
> 


This is also worked for me, what is the best way to do this on startup?

Thank you, Stanislaw Gruszka ! Your workaround work for me too !! :)
I'm write little bash script bt-tune-autosuspend.sh:
#!/bin/bash
cd `readlink -f /sys/class/bluetooth/hci0`
cd ../../../power/
echo on > level 

and put call to this script into rc.local

That's work for me :)

I hope in the future, the kernel developers will make the management interface is closer to the man. And take away error messages in the system log. And developers Gnome and KDE did the convenient interface control these parameters.

One more datapoint:
On my Dell D610 with Dell 350 Bluetooth adapter, my Logitech Bluetooth Travel Mouse is unusable without disabling autosuspend. It nearly always fails to pair, and the one time I *did* get it to work, it failed again within minutes and would not reconnect. Meanwhile, the log fills with:
 
Apr 26 19:18:12 XXX kernel: btusb_intr_complete: hci0 urb ef8b5380 failed to resubmit (1)
Apr 26 19:18:12 XXX kernel: btusb_bulk_complete: hci0 urb ef8b5a80 failed to resubmit (1)
Apr 26 19:18:12 XXX kernel: btusb_bulk_complete: hci0 urb ef8b5680 failed to resubmit (1)
Apr 26 19:18:21 XXX kernel: btusb_intr_complete: hci0 urb f2a52180 failed to resubmit (1)

As soon as I disable autosuspend for the Bluetooth adapter, the mouse works perfectly.

These are my devices:
413c:8103 Dell Computer Corp. Wireless 350 Bluetooth
OUI Company: Logitech SA
Device Name: Bluetooth Travel Mouse

*** Bug 576762 has been marked as a duplicate of this bug. ***

This is also a problem in F13 RC.

It gets worse.  When the system wakes up from a "sleep" (suspend to memory) state, the kernel puts the Bluetooth adapter back into the autosuspend state and the mouse becomes unusable.  I presume the same thing would happen when coming out of hibernate.  Anyone know where I can put a script that will get executed when the system wakes up?

In case it helps, here is an excerpt from my system log.  This is with a bluetooth adaptor from Anycom on an HP laptop.  Stanislaw's workaround worked for me.  Without the workaround the mouse would be gone for several seconds every time it went idle.

May 26 22:26:31 psi kernel: btusb_intr_complete: hci0 urb ffff88009c3dcc00 failed to resubmit (1)
May 26 22:26:31 psi kernel: btusb_bulk_complete: hci0 urb ffff88009c3dcd80 failed to resubmit (1)
May 26 22:26:31 psi kernel: btusb_bulk_complete: hci0 urb ffff88009c3dc480 failed to resubmit (1)
May 26 22:26:34 psi kernel: btusb_intr_complete: hci0 urb ffff8800795f1840 failed to resubmit (1)
May 26 22:26:34 psi kernel: btusb_bulk_complete: hci0 urb ffff8800795f1d80 failed to resubmit (1)
May 26 22:26:34 psi kernel: btusb_bulk_complete: hci0 urb ffff8800795f1f00 failed to resubmit (1)
May 26 22:26:46 psi kernel: btusb_intr_complete: hci0 urb ffff8800b15466c0 failed to resubmit (1)
May 26 22:26:46 psi kernel: btusb_bulk_complete: hci0 urb ffff8800b1546d80 failed to resubmit (1)
May 26 22:26:46 psi kernel: btusb_bulk_complete: hci0 urb ffff8800b1546cc0 failed to resubmit (1)
May 26 22:26:49 psi kernel: btusb_intr_complete: hci0 urb ffff8800795f5480 failed to resubmit (1)
May 26 22:26:49 psi kernel: btusb_bulk_complete: hci0 urb ffff8800795f5b40 failed to resubmit (1)
May 26 22:26:49 psi kernel: btusb_bulk_complete: hci0 urb ffff8800795f59c0 failed to resubmit (1)
May 26 22:27:49 psi kernel: btusb_intr_complete: hci0 urb ffff88007968fb40 failed to resubmit (1)
May 26 22:27:49 psi kernel: btusb_bulk_complete: hci0 urb ffff88007968fa80 failed to resubmit (1)
May 26 22:27:49 psi kernel: btusb_bulk_complete: hci0 urb ffff88007968f3c0 failed to resubmit (1)
May 26 22:28:48 psi kernel: btusb_intr_complete: hci0 urb ffff8800794990c0 failed to resubmit (1)
May 26 22:28:48 psi kernel: btusb_bulk_complete: hci0 urb ffff880079499240 failed to resubmit (1)
May 26 22:28:48 psi kernel: btusb_bulk_complete: hci0 urb ffff880079499cc0 failed to resubmit (1)
May 26 22:28:48 psi kernel: hub 1-4.4:1.0: port 1 disabled by hub (EMI?), re-enabling...
May 26 22:28:48 psi bluetoothd[4687]: HCI dev 0 down
May 26 22:28:48 psi bluetoothd[4687]: Adapter /org/bluez/4680/hci0 has been disabled
May 26 22:28:48 psi bluetoothd[4687]: Stopping security manager 0
May 26 22:28:48 psi kernel: usb 1-4.4.1: USB disconnect, address 16
May 26 22:28:48 psi kernel: usb 1-4.4.1.1: USB disconnect, address 17
May 26 22:28:48 psi bluetoothd[4687]: HCI dev 0 unregistered
May 26 22:28:48 psi bluetoothd[4687]: Unregister path: /org/bluez/4680/hci0
May 26 22:28:48 psi dbus-daemon: [system] Rejected send message, 2 matched rules; type="error", sender=":1.34" (uid=500 pid=2094 comm="bluetooth-applet) interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" requested_reply=0 destination=":1.66" (uid=0 pid=4680 comm="/usr/sbin/bluetoothd))
May 26 22:28:49 psi kernel: usb 1-4.4.1: new full speed USB device using ehci_hcd and address 19
May 26 22:28:49 psi kernel: usb 1-4.4.1: New USB device found, idVendor=0a5c, idProduct=4500
May 26 22:28:49 psi kernel: usb 1-4.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 26 22:28:49 psi kernel: usb 1-4.4.1: Product: BCM2045B2
May 26 22:28:49 psi kernel: usb 1-4.4.1: Manufacturer: Broadcom
May 26 22:28:49 psi kernel: hub 1-4.4.1:1.0: USB hub found
May 26 22:28:49 psi kernel: hub 1-4.4.1:1.0: 3 ports detected
May 26 22:28:49 psi kernel: usb 1-4.4.1.1: new full speed USB device using ehci_hcd and address 20
May 26 22:28:49 psi bluetoothd[4687]: HCI dev 0 registered
May 26 22:28:49 psi kernel: usb 1-4.4.1.1: New USB device found, idVendor=0a5c, idProduct=2111
May 26 22:28:49 psi kernel: usb 1-4.4.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 26 22:28:49 psi kernel: usb 1-4.4.1.1: Product: ANYCOM Bluetooth USB-250 UHE
May 26 22:28:49 psi kernel: usb 1-4.4.1.1: Manufacturer: Broadcom Corp
May 26 22:28:49 psi bluetoothd[4687]: HCI dev 0 up
May 26 22:28:49 psi bluetoothd[4687]: Starting security manager 0
May 26 22:28:49 psi kernel: hub 1-4.4.1:1.0: unable to enumerate USB device on port 2
May 26 22:28:49 psi bluetoothd[4687]: Parsing /etc/bluetooth/serial.conf failed: No such file or directory
May 26 22:28:49 psi bluetoothd[4687]: probe failed with driver input-headset for device /org/bluez/4680/hci0/dev_00_17_4B_3B_5F_F1
May 26 22:28:49 psi bluetoothd[4687]: Adapter /org/bluez/4680/hci0 has been enabled
May 26 22:28:52 psi kernel: btusb_intr_complete: hci0 urb ffff88009cf979c0 failed to resubmit (1)
May 26 22:28:52 psi kernel: btusb_bulk_complete: hci0 urb ffff88009cf97e40 failed to resubmit (1)
May 26 22:28:52 psi kernel: btusb_bulk_complete: hci0 urb ffff88009cf976c0 failed to resubmit (1)
May 26 22:29:09 psi kernel: input: Si670m Bluetooth Wireless Notebook Mouse as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.4/1-4.4.1/1-4.4.1.1/1-4.4.1.1:1.0/bluetooth/hci0/hci0:11/input51
May 26 22:29:09 psi kernel: generic-bluetooth 0005:047D:1150.002A: input,hidraw0: BLUETOOTH HID v1.29 Mouse [Si670m Bluetooth Wireless Notebook Mouse] on 00:16:38:CA:A4:99

(In reply to comment #26)
> It gets worse.  When the system wakes up from a "sleep" (suspend to memory)
> state, the kernel puts the Bluetooth adapter back into the autosuspend state
> and the mouse becomes unusable.  I presume the same thing would happen when
> coming out of hibernate.  Anyone know where I can put a script that will get
> executed when the system wakes up?    

You can put a hook file in /usr/lib64/pm-utils/sleep.d/ (or just lib on a 32-bit system). I put in a generic 99workarounds, reading


. "${PM_FUNCTIONS}"
case "$1" in
  hibernate|suspend|thaw|resume)
    for wa in /etc/workarounds.d/* ; do
      [ -x "$wa" ] || continue
      . "$wa" "$1"
    done
    ;;
  *) exit $NA
    ;;
esac


and then created the directory /etc/workarounds.d/. In this directory I put 20-btusb-autosuspend.sh, derived from Comment 22:


#!/bin/bash
case "$1" in
  boot|thaw|resume)
    cd `readlink -f /sys/class/bluetooth/hci0`
    cd ../../../power/
    echo on > level 
    ;;
esac


Finally, I tacked


# run workaround scripts
for wa in /etc/workarounds.d/* ; do
  [ -x "$wa" ] || continue
  . "$wa" boot
done


on to the end of /etc/rc.local . This should cover all cases: statup, and resumes from suspend and hibernate. Note both 99workarounds and 20-btusb-autosuspend.sh should have exec permissions.

This bug also causes problems with the "set up new device" dialog of the gnome-bluetooth applet.  It seems that while scanning the bluetooth dongle goes in and out of sleep mode and is seldom awake long enough to even get the name of the remote bluetooth device.  Stanislaw's workaround fixes this.

(In reply to comment #28)
I did the procedure described below and it does everything that its supposed to except that in the case of waking up after suspend some other process comes along and puts "auto" into the level file.  I put some lines to track progress of each function and can verify that the level file contains "on" at completion of "20-btusb-autosuspend.sh" but contains "auto" by the time I can cat its contents from a bash shell.  There is no problem on booting.  

> (In reply to comment #26)
> > It gets worse.  When the system wakes up from a "sleep" (suspend to memory)
> > state, the kernel puts the Bluetooth adapter back into the autosuspend state
> > and the mouse becomes unusable.  I presume the same thing would happen when
> > coming out of hibernate.  Anyone know where I can put a script that will get
> > executed when the system wakes up?    
> 
> You can put a hook file in /usr/lib64/pm-utils/sleep.d/ (or just lib on a
> 32-bit system). I put in a generic 99workarounds, reading
> 
> 
> . "${PM_FUNCTIONS}"
> case "$1" in
>   hibernate|suspend|thaw|resume)
>     for wa in /etc/workarounds.d/* ; do
>       [ -x "$wa" ] || continue
>       . "$wa" "$1"
>     done
>     ;;
>   *) exit $NA
>     ;;
> esac
> 
> 
> and then created the directory /etc/workarounds.d/. In this directory I put
> 20-btusb-autosuspend.sh, derived from Comment 22:
> 
> 
> #!/bin/bash
> case "$1" in
>   boot|thaw|resume)
>     cd `readlink -f /sys/class/bluetooth/hci0`
>     cd ../../../power/
>     echo on > level 
>     ;;
> esac
> 
> 
> Finally, I tacked
> 
> 
> # run workaround scripts
> for wa in /etc/workarounds.d/* ; do
>   [ -x "$wa" ] || continue
>   . "$wa" boot
> done
> 
> 
> on to the end of /etc/rc.local . This should cover all cases: statup, and
> resumes from suspend and hibernate. Note both 99workarounds and
> 20-btusb-autosuspend.sh should have exec permissions.

So bluetooth autosuspend is broken, I guess we can just disable it completely?

It certainly seems broken when HID pairings are involved.  Not sure about other devices.

(In reply to comment #31)
> So bluetooth autosuspend is broken, I guess we can just disable it completely?

I think we should disable auto-suspend for btusb as long as fixes for input and other problems shows us.

This bug seems to be fixed for me as of kernel-PAE-2.6.34.6-47.fc13.i686

This bug has reappeared for me in a recent kernel update.  I am currently running 4.14.16-300.fc27.x86_64, but the mouse lag started happening with an earlier kernel (unfortunately I don't have a record of which one).