GNOME Bugzilla – Bug 782532
Allow users to escape broken rfkill state
Last modified: 2019-03-20 11:42:42 UTC
Due to bugs (which are being dealt with) users might end up in the following rfkill state which will persist unless the computer is re-installed. $ rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 121: hci0: Bluetooth Soft blocked: yes Hard blocked: no This is bad, as GNOME considers bluetooth to be on but it is unable to actually turn it on (BluetoothAirplaneMode is Off). When the user tries to fix this by turning off/on bluetooth they will still be stuck in the same state as systemd-rfkill restores it when hci0 re-appears. I see two possible workarounds right now: * Detect the case that systemd-rfkill does a stupid restore and unblock again * Allow the user to "Enable" bluetooth a second time in the control center (bug #764696 is related); main issue is that the switch would go back to "Off" for a short time when enabling.
There's already an escape hatch for that case in the rfkill plugin, see https://bugzilla.gnome.org/show_bug.cgi?id=741675 If you want to fix this long term, you should add support for the rfkill subsystem to umockdev[1], and create reproducers. [1]: https://github.com/martinpitt/umockdev/issues/51
Well, then there unfortunately is a bug in the implementation of the feature. So yeah, commit 5f29c37e was supposed to fix it, but seems like that didn't work out.
So, for the long term I already have a proper fix for systemd-rfkill pending upstream which should prevent this issue from cropping up in the future. Properly testing this seems a bit more involved to me. I haven't actually tried to use umockdev at this point as it was trivial to test locally (on any Lenovo laptop). But it seems a bit more involved to do a realistic "full system" test which includes systemd to properly reproduce this bug. Unless of course we would simulate the sytemd-rfkill behaviour as part of umockdev. Well, looks like the timeout is simply too short: 1494941492.738074: idx 0 type 2 op 2 soft 0 hard 0 1494941493.215962: idx 14 type 2 op 0 soft 0 hard 0 1494941493.263219: idx 14 type 2 op 2 soft 1 hard 0 or: 1494941564.350097: idx 0 type 2 op 2 soft 0 hard 0 1494941564.830240: idx 15 type 2 op 0 soft 0 hard 0 1494941564.879854: idx 15 type 2 op 2 soft 1 hard 0 so 525ms and 529ms.
Created attachment 351973 [details] [review] rfkill: Allow more time for bluetooth devices to initialize In some corner cases systemd-rfkill may immediately turn of a bluetooth device that is being added (due to a platform rfkill being unblocked). Unfortunately the timeout of 500ms is not sufficient of some machines so increase it to 1s. An example of such a case: 1494941564.350097: idx 0 type 2 op 2 soft 0 hard 0 1494941564.830240: idx 15 type 2 op 0 soft 0 hard 0 1494941564.879854: idx 15 type 2 op 2 soft 1 hard 0 Which is almost 530ms between the platform device being unblocked and systemd-rfkill blocking the newly appeared rfkill switch.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/332.