Description of problem: With F10, I use a Logitech bluetooth mouse with my T43 laptop (with built-in bluetooth adapter). I can use the gnome-bluetooth applet to connect to the mouse, but if I turn the mouse off and back on again it fails to reconnect. It seems to be "forgotten". The same thing happens if I suspend/resume or reboot the laptop. To get the mouse to work again, I have to use the applet to delete the mouse, then pair up again. Version-Release number of selected component (if applicable): bluez-4.22-2.fc10.i386 bluez-alsa-4.22-2.fc10.i386 bluez-cups-4.22-2.fc10.i386 bluez-gnome-1.8-11.fc10.i386 bluez-libs-4.22-2.fc10.i386 gnome-bluetooth-0.11.0-5.fc10.i386 gnome-bluetooth-libs-0.11.0-5.fc10.i386 How reproducible: Every time. Steps to Reproduce: As listed above. Actual results: Mouse fails to reconnect. Expected results: Mouse reconnects. Additional info: Note that the same mouse worked correctly with the same laptop under F8 & F9. Also note that I upgraded this laptop to F10 (not a fresh install). Here is what I see in /var/log/messages when initially pairing up the mouse with the laptop: Feb 17 08:41:01 localhost bluetoothd[2201]: Discovery session 0x220fd40 with :1.301 activated Feb 17 08:41:19 localhost bluetoothd[2201]: Registered interface org.bluez.Input on path /org/bluez/2201/hci0/dev_00_07_61_6C_2B_D9 Feb 17 08:41:19 localhost kernel: input: Bluetooth Travel Mouse as /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/bluetooth/hci0/hci0:6/input13
On a Lenovo T61 laptop with a fresh install of F10, I do not see this problem. I paired the same mouse with the laptop, and mouse reconnects when turned off and back on again (with no user intervention).
Sounds like your Bluetooth adapter needs a quirk. Try the work-around mentioned in: https://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions
(In reply to comment #2) > Sounds like your Bluetooth adapter needs a quirk. Try the work-around mentioned > in: > https://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions That wiki page doesn't mention quirks as far as I can see. Perhaps you meant a different page?
No, that page, the FAQ with the btusb module option work-around.
(In reply to comment #4) > No, that page, the FAQ with the btusb module option work-around. For some reason the that section of the wiki page displays sometimes for me and not others. Odd. I added the "options hci_usb reset=1" line to /etc/modprobe.conf and rebooted. I paired the mouse, ensured it worked, then turned the mouse off and back on. The mouse did not reconnect.
We found the bug in bluez, and it's been there for a while. The "work-around" is to turn off the device before rebooting, and, yes, I know it sucks... *** This bug has been marked as a duplicate of bug 468600 ***
I'm not sure this is a duplicate of bug 468600. First off, this mouse and laptop combination worked under F9. So, depending on your definition of "a while", this could be a different bug. Second while this mouse and laptop combination does exhibit the problem in bug 468600 (having to delete and re-add the bluetooth device after a reboot), I have the additional problem of booting the system, deleting and re-adding the bluetooth mouse, then turning the mouse off and back on and having to delete and re-add the bluetooth mouse again. This problem requires no reboot, just turning the device off and on again. This is quite annoying - to conserve the batteries in the mouse I turn it off if I'm going to be away to run an errand for instance. Having to delete and re-add it is annoying.
(In reply to comment #7) > I'm not sure this is a duplicate of bug 468600. > > First off, this mouse and laptop combination worked under F9. So, depending on > your definition of "a while", this could be a different bug. Since bluez 4.x, that means nearly a year, and since F10. > Second while this mouse and laptop combination does exhibit the problem in bug > 468600 (having to delete and re-add the bluetooth device after a reboot), I > have the additional problem of booting the system, deleting and re-adding the > bluetooth mouse, then turning the mouse off and back on and having to delete > and re-add the bluetooth mouse again. This problem requires no reboot, just > turning the device off and on again. If the mouse doesn't try to reconnect _at all_ then it's a problem with the mouse. But if you turned off Bluetooth, it would have the same effect. > This is quite annoying - to conserve the batteries in the mouse I turn it off > if I'm going to be away to run an errand for instance. Having to delete and > re-add it is annoying. In that case, it sounds like broken hardware (or the mouse is paired to multiple computers, in which case you'll be able to force a connection using the gnome-bluetooth applet).
(In reply to comment #8) > If the mouse doesn't try to reconnect _at all_ then it's a problem with the > mouse. But if you turned off Bluetooth, it would have the same effect. On a T43 running F9, turning the mouse on, pairing up, off, and on again works. Under F10, it fails. On a T61 running F10, turning the mouse on, pairing up, off, and on again works fine. Based on that, I'd say the mouse is working correctly.
Then it sounds like a problem with the Bluetooth dongle/driver.
Please test the work-around mentioned in the FAQ here: https://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions
As mentioned in comment #5, I've already tried the "options hci_usb reset=1" work-around and it made no difference.
Could you please test this build? http://koji.fedoraproject.org/koji/taskinfo?taskID=1342509 It should install fine on F10. The code changes don't allow us to fix this for F10 itself, but the package should work on F10.
I've tried the bluez-4.37-3 packages. Unfortunately, they made no difference. I paired the mouse with the system, verified the mouse worked, then turned the mouse off and then back on again. The system did not reconnect to the mouse.
(In reply to comment #14) > I've tried the bluez-4.37-3 packages. Unfortunately, they made no difference. > I paired the mouse with the system, verified the mouse worked, then turned the > mouse off and then back on again. The system did not reconnect to the mouse. I just want to clarify that it is _not_ the system's job to reconnect to the mouse. The mouse is supposed to reconnect to the computer. Could you please run "bluetoothd -d -n" by hand (as root) and reproduce the problem, and pass on the logs?
Created attachment 344170 [details] t43 log
Created attachment 344171 [details] t61 log
I've attached 2 log files - one from a t43 where the mouse does not reconnect, one from a t61 where the mouse does reconnect. On the t43, when I turned the mouse back on, nothing appears in the log. On the t61, here is the output when the mouse gets reconnected: bluetoothd[28352]: adapter_get_device(00:07:61:6C:2B:D9) bluetoothd[28352]: Incoming connection on PSM 17 bluetoothd[28352]: Incoming connection on PSM 19
I can confirm this bug. Same hardware, but not Fedora. Bluez 4.40, btusb 0.5 from git (which, BTW, does reset=1 by default since 2.6.29) dmesg: btusb_intr_complete: hci0 urb f6a266c0 failed to resubmit (19) btusb_bulk_complete: hci0 urb f6a26740 failed to resubmit (19) btusb_bulk_complete: hci0 urb f6a26cc0 failed to resubmit (19) btusb_send_frame: hci0 urb f60267c0 submission failed [...] hci_cmd_task: hci0 command tx timeout When I move the mouse: bluetoothd[21097]: adapter_get_device(00:07:61:A5:E9:8E) bluetoothd[21097]: adapter_get_device(00:07:61:A5:E9:8E) bluetoothd[21097]: adapter_get_device(00:07:61:A5:E9:8E) (loop) udev monitor: KERNEL[1243756954.652455] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/bluetooth/hci0/hci0:7 (bluetooth) UDEV [1243756954.655578] add /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/bluetooth/hci0/hci0:7 (bluetooth) KERNEL[1243756955.799840] remove /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/bluetooth/hci0/hci0:7 (bluetooth) UDEV [1243756955.801889] remove /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/bluetooth/hci0/hci0:7 (bluetooth) (loop) So the mouse DOES try to reconnect. If I try to connect from gnome-bluetooth 'Connect' menu item: bluetoothd[21097]: adapter_get_device(00:07:61:A5:E9:8E) bluetoothd[21097]: Host is down (112)
Maybe this will help too... root@foo ~ l2ping 00:07:61:A5:E9:8E Can't connect: Host is down Now wiggle the mouse: root@foo ~ l2ping 00:07:61:A5:E9:8E Ping: 00:07:61:A5:E9:8E from 00:16:CF:EE:0B:66 (data size 44) ... 0 bytes from 00:07:61:A5:E9:8E id 0 time 36.44ms Send failed: Software caused connection abort
It looks like a pretty good research has been made: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/343727/comments/29 Also reading through https://bugs.launchpad.net/ubuntu/+source/bluez/?field.searchtext=mouse may help you acknowledge that something is wrong. (Sorry for flooding this bug a bit)
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.