Bug 485927 - bluetooth mouse gets "forgotten"
bluetooth mouse gets "forgotten"
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
10
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-17 09:50 EST by David Smith
Modified: 2009-12-18 02:56 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:56:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
t43 log (7.16 KB, text/plain)
2009-05-15 11:02 EDT, David Smith
no flags Details
t61 log (6.99 KB, text/plain)
2009-05-15 11:03 EDT, David Smith
no flags Details

  None (edit)
Description David Smith 2009-02-17 09:50:28 EST
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
Comment 1 David Smith 2009-03-03 15:18:59 EST
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).
Comment 2 Bastien Nocera 2009-04-23 11:46:27 EDT
Sounds like your Bluetooth adapter needs a quirk. Try the work-around mentioned in:
https://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions
Comment 3 David Smith 2009-04-23 12:05:00 EDT
(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?
Comment 4 Bastien Nocera 2009-04-23 12:18:18 EDT
No, that page, the FAQ with the btusb module option work-around.
Comment 5 David Smith 2009-04-24 12:09:35 EDT
(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.
Comment 6 Bastien Nocera 2009-04-24 14:40:20 EDT
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 ***
Comment 7 David Smith 2009-04-24 15:48:11 EDT
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.
Comment 8 Bastien Nocera 2009-04-24 16:15:29 EDT
(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).
Comment 9 David Smith 2009-04-24 16:54:33 EDT
(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.
Comment 10 Bastien Nocera 2009-04-24 22:14:41 EDT
Then it sounds like a problem with the Bluetooth dongle/driver.
Comment 11 Bastien Nocera 2009-04-24 22:15:20 EDT
Please test the work-around mentioned in the FAQ here:
https://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions
Comment 12 David Smith 2009-04-27 09:39:40 EDT
As mentioned in comment #5, I've already tried the "options hci_usb reset=1" work-around and it made no difference.
Comment 13 Bastien Nocera 2009-05-07 21:14:29 EDT
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.
Comment 14 David Smith 2009-05-11 21:07:50 EDT
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.
Comment 15 Bastien Nocera 2009-05-12 07:01:03 EDT
(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?
Comment 16 David Smith 2009-05-15 11:02:21 EDT
Created attachment 344170 [details]
t43 log
Comment 17 David Smith 2009-05-15 11:03:15 EDT
Created attachment 344171 [details]
t61 log
Comment 18 David Smith 2009-05-15 11:05:59 EDT
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
Comment 19 Krzysztof Kotlenga 2009-05-31 04:22:09 EDT
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)
Comment 20 Krzysztof Kotlenga 2009-05-31 04:35:37 EDT
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
Comment 21 Krzysztof Kotlenga 2009-05-31 08:16:06 EDT
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)
Comment 22 Bug Zapper 2009-11-18 06:07:44 EST
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
Comment 23 Bug Zapper 2009-12-18 02:56:38 EST
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.

Note You need to log in before you can comment on or make changes to this bug.