Bluetooth is not fully re-initialized when rfkill switch is toggled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| bluez (Ubuntu) |
Medium
|
Jesse Sung | ||
| Precise |
Medium
|
Jesse Sung | ||
| gnome-bluetooth (Ubuntu) |
Medium
|
Mathieu Trudel-Lapierre | ||
| Precise |
Medium
|
Mathieu Trudel-Lapierre |
Bug Description
Summary: RFKill switch can disable the bluetooth, but switching it back on doesn't bring the bluetooth all the way up. The bluetooth service must be restarted for it to come back online fully.
Steps:
1. Check Bluetooth status
2. Use wireless switch to disable Bluetooth
3. Use wireless switch to enable Bluetooth
Expected results: In Step 1, BT should be enabled by default, In Step2 BT sould be disabled. In Step 3, BT should be enabled.
Actual results: In Step 3, the Bluetooth adapter is not fully online. The inidicator says that the bluetooth is up, but, one cannot pair devices, transfer files, etc, until the bluetooth service is restarted.
James M. Leddy (jm-leddy) wrote : | #1 |
James M. Leddy (jm-leddy) wrote : | #2 |
output of bluetoothd -nd . rfkill switch started on, was turned off, then on again. Please let me know if there are other diagnostic steps that you would like to help move this along.
James M. Leddy (jm-leddy) wrote : | #3 |
Initial analysis :
Init:
bluetoothd[1982]: src/main.c:main() Entering main loop
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
Flip switch off:
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: HCI dev 0 down
Flip switch on:
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: HCI dev 0 registered
bluetoothd[1982]: plugins/
bluetoothd[1982]: Listening for HCI events on hci0
bluetoothd[1982]: plugins/
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: HCI dev 0 up
Some other event I don't know what is, may be cleanup:
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/adapter.
bluetoothd[1982]: src/sdpd-
What I find interesting is that idx 0,1 are not re-enabled when the switch is flicked back on, only some time later, if I'm reading the output of rfkill_event() correctly.
tags: | added: blocks-hwcert-enablement |
tags: |
added: rls-p-tracking removed: blocks-hwcert-enablement |
tags: | added: blocks-hwcert-enablement |
James M. Leddy (jm-leddy) wrote : | #4 |
On second thought, the last event is not cleanup, since it is recognizing the switch as _on_ for idx{0,1}. It looks like the device might have to be initialized first before it sends the signal that the rfkill switch has been turned on. Here is more complete what's going on before that:
bluetoothd[1982]: Adapter /org/bluez/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: src/adapter.
bluetoothd[1982]: plugins/
bluetoothd[1982]: src/adapter.
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: plugins/
bluetoothd[1982]: src/adapter.
bluetoothd[1982]: src/adapter.
bluetoothd[1982]: plugins/
bluetoothd[1982]: src/adapter.
bluetoothd[1982]: src/rfkill.
bluetoothd[1982]: src/rfkill.
James M. Leddy (jm-leddy) wrote : | #5 |
The only noticeable differences in output between initialization and the re-enablement of device via rfkill.
1) aforementioned idx{0,1} are blocked until initialization is done
2) bluetoothd[1982]: src/rfkill.
bluetoothd[
Occur only in re-enablement
3) child process fork/exiting takes a lot longer when re-enabling as opposed to init.
Changed in bluez (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in bluez (Ubuntu): | |
assignee: | nobody → Mathieu Trudel-Lapierre (mathieu-tl) |
tags: |
added: rls-mgr-p-tracking removed: rls-p-tracking |
This seems to work pretty well for me right now if you omit the issue of the bluetooth applet not properly seeing the new enabled state after rfkill has been toggled (it never comes back with the full menu unless you change a config in the wizard or turn it off/on again via the menu). Bluetooth functions properly though, I was able to send and receive files successfully.
Changed in bluez (Ubuntu): | |
status: | Confirmed → Incomplete |
Changed in gnome-bluetooth (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → Mathieu Trudel-Lapierre (mathieu-tl) |
Changed in bluez (Ubuntu): | |
assignee: | Mathieu Trudel-Lapierre (mathieu-tl) → nobody |
tags: |
added: rls-p-tracking removed: rls-mgr-p-tracking |
Anthony or James, please confirm: this was for a Dell device right? It's the only place so far I've been able to reproduce this kind of behavior. Seems to be because the killswitch actually removes the bluetooth device altogether.
Anthony Wong (anthonywong) wrote : | #8 |
Yes, this is a Dell device. And will killswitch is enabled, device no longer shows in lsusb.
Jesse Sung (wenchien) wrote : | #9 |
This patch is not mandatory for this issue, but it fixes an error message when RFKILL switch is turned off:
bluetoothd[5416]: sap/manager.
bluetoothd[5416]: sap-dummy interface org.bluez.
bluetoothd[5416]: Sap driver initialization failed.
bluetoothd[5416]: sap-server: Operation not permitted (1)
Jesse Sung (wenchien) wrote : | #10 |
This patch is for
bluetoothd[5416]: audio/manager.
bluetoothd[5416]: rfcomm_bind: Address already in use (98)
bluetoothd[5416]: audio-gateway: Operation not permitted (1)
Jesse Sung (wenchien) wrote : | #11 |
On certain devices, module would be powered off after RFKILL enabled. When RFKILL is disabled again, update_menu_items() would be called with has_powered_adapter set to TRUE, but the bluetooth_
Explicity emit an update-menu signal when killswitch state changed fix this.
Jesse Sung (wenchien) wrote : | #12 |
Patched bluez and gnome-bluetooth packages can be found at
http://
Please give them a try to see if this issue is gone, and also make sure that they do not break anything on other platforms. :)
Thank you.
Changed in bluez (Ubuntu Precise): | |
assignee: | nobody → Jesse Sung (wenchien) |
status: | Incomplete → In Progress |
The attachment "patch for bluez (optional)" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.
[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]
tags: | added: patch |
Well, patch https:/
Also, g_io_channel_
Do you need sponsoring for these patches?
tags: |
added: patch-needswork removed: patch |
tags: | removed: rls-p-tracking |
Jesse Sung (wenchien) wrote : | #15 |
Hi Mathieu,
Sorry, didn't notice that it's deprecated. An updated patch is attached.
And yes, please sponsor these patches, thank you. :)
Changed in bluez (Ubuntu Precise): | |
importance: | Medium → Low |
importance: | Low → Medium |
In progress :) I'll upload this in a few minutes once I can successfully test this.
It's nice to see we got the same patch for the gnome-bluetooth part of the fix independently.
Launchpad Janitor (janitor) wrote : | #17 |
This bug was fixed in the package bluez - 4.98-2ubuntu7
---------------
bluez (4.98-2ubuntu7) precise; urgency=low
* debian/
interface on exit. Thanks to Jesse Sung for the patch.
* debian/
HFP is properly closed on exit. Thanks to Jesse Sung for the patch.
(LP: #907818)
-- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Mar 2012 15:27:57 -0400
Changed in bluez (Ubuntu Precise): | |
status: | In Progress → Fix Released |
Launchpad Janitor (janitor) wrote : | #18 |
This bug was fixed in the package gnome-bluetooth - 3.2.2-0ubuntu4
---------------
gnome-bluetooth (3.2.2-0ubuntu4) precise; urgency=low
* debian/
properly when the killswitch state is changed. Specifically, notify for the
applet to show the full menu, so that it can be displayed again when coming
back from BLOCKED state. This fixes an issue specific to Dell systems where
the devices are removed then re-added when the rfkill state is toggled.
(LP: #907818)
-- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Mar 2012 16:56:46 -0400
Changed in gnome-bluetooth (Ubuntu Precise): | |
status: | Confirmed → Fix Released |
Workaround
==========
61-rfkill- nm-disable- enable. rules ======= ======= =====
=======
#the rfkill device number for wifi is inconsistent between platforms * is used nm_disable_ enable_ end" nm_disable_ enable_ end" STATE}= ="1" ENV{RFKILL_ TYPE}== "wlan" RUN+="nm- disable- enable" rfkill_ nm_disable_ enable_ end"
KERNEL!="rfkill*", GOTO="rfkill_
ACTION!="change", GOTO="rfkill_
#only switch once on wlan event to avoid doubling in the case of bluetooth event, related to rfkill switch
ENV{RFKILL_
LABEL="
nm-disable-enable
===============
#!/bin/sh
service bluetooth restart