[3.4.0 onwards] Bluetooth turning on doesn't work

With 4.2 on Xperia X the issue still persists.
Sometimes killing hciattach helps, otherwise only restarting bluetooth-rfkill-event.service once or even twice makes Bluetooth connectable again.

you got lucky, it seems :wink:

1 Like

Well, if any of you would like to contribute to or improve anything wrt either the patchmanager patch, or the PR against sailfish-utilities you’re welcome to do so.

I don’t have a great many devices to test and as we have seen there’s a lot of guesswork involved .

What’s missing here is hints for low level debugging. I’d be eager to comb through logs if only I knew how to get some.

Sometimes BT won’t work even though there’s no hciattach process running. Then the said service restart is necessary. But my observations are not done in a systematic way.

This problem persists in the Xperia X. It’s a pain to be sure.

IMHO, Jolla should simply include a complete BT kill/restart as part of the tools, like there is for networking

/rant

BT is and always has been flakey, and not just on SFOS. Connectivity and interoperability have been the defining characteristic of BT since its invention and apparently this isn’t going to change any time soon

Just as I typed in above that it had improved…

Yesterday I had to restart my 10-II (due to other issues). I was not able to turn on bluetooth. I restarted the phone. Twice. Still no go. I shut down the phone (as I seem to remember that it sometimes need a full shutdown instead of restart) and STILL nothing. I had to manually run ‘systemctl restart bluetooth.service’ and then I was finally able to get it back on :angry:

In my case, the main problem with turning off bluetooth was, that the hciattach process could not be closed by bluetooth-rfkill-event.

Okt 31 11:34:34 Sailfish bluetooth_rfkill_event[654]: free_hci(bluetooth_rfkill_event.c:906): killing hciattach failed

If the process hciattach was ended manually after switching off the bluetooth (kill -15 hciattach), the reactivation of bluetooth worked without any problems.

The reason why the hciattach process cannot be closed by bluetooth-rfkill-event is likely following:
The bluetooth_rfkill_event uses the command ‘killall --wait hciattach’ to end the hciattach process.
Because of the switch to BusyBox, the killall command from BusyBox is used instead of the killall command from the psmisc-tools package.
However, the BusyBox ‘killall’ command does not support the ‘–wait’ option, so it generates an error and will not be executed.

As a workaround, I installed the psmisc-tools package.

devel-su pkcon remove busybox-symlinks-psmisc

The hciattach process is now correctly terminated by bluetooth-rfkill-event

Okt 31 17:28:38 Sailfish bluetooth_rfkill_event[10297]: free_hci(bluetooth_rfkill_event.c:906): killing hciattach succeeded

Switching Bluetooth on and off now works properly again.

Tested on Xperia X (F5121) Sailfish 4.2.0.21 (Verla)

12 Likes

Thanks for your investigations @senders. That looks interesting to me. I’ll point it to one of our chief engineers.

6 Likes

After update to 4.3.0.12 on my XperiaX F5122 Bluetooth is now completely broken and will not activate at all.

It was flakey before as many have noted.

This functionality has now reached unusable, which is a bummer, because I just flew half way around the world unable to use my BT headphones and hear my music

I don’t know how to bump this … I can’t believe that this problem get successively worse with each version

That didn’t help me … still no BT whatsoever

systemctl restart bluetooth-rfkill-event.service

This worked in this instance … now I’ll try to connect to something

I use the command shared by @peterleinchen a few months ago (basically restarting both services). I need sometimes to run it 2 or 3 times but it always ends up working:

devel-su restart bluetooth bluetooth-rfkill-event

+1 on Xperia X Compact SFOS 4.3.0.12 BT re-enabling still broken :frowning: Maybe 4.4 gonna fix this annoying issue.

We should have held a birthday party for this ticket. It is already one year + 3 releases old

4 Likes

@DrDweeb, @Sthocs, @Xeno_PL: Does the workaround @senders posted above solve the issue for you? It did for me (Xperia X).

@deloptes: Yes we should’ve have brought some :birthday: to give it @senders for finding a solution. and a :cake: to @jovirkku for keeping this on his radar
:wink:

Thanks senders! You’ve made my Bluetooth connected day(s)!

2 Likes

Great that you pointed to the sanders analyses and solution - does it work on the 4.3? Because on the 4.3. it happens randomly that it does not work.
I mean from my perspective the issue is still not solved and there are other issues related to BT, where I opened other bug reports.
This is why I was so pissed that the software banned me, so I will not say anything bad … but only that I am very pissed. It happens that I have to remove pairing and pair again right after I start the car. This is frustrating and regression compared to previous versions.

I demand a sense for quality from Jolla. PLEASE!

And thank you all guys !

I am no expert to check it thoroughly but I think Jolla is working on it: see https://github.com/mer-hybris/bluetooth-rfkill-event/pull/8

it has been merged and is likely being tested. Not clear if it is coming along next update and if it solves the issue for all.

No @rozgwi, I don’t use BT that much anymore so I can wait for Jolla’s fix, but thanks for testing yourself! And congrats Jolla for actually making us so trendy :smiley:: Why I'm thrilled that wired headphones are 'trendy' again

Thank you for the liberal enema and confirming that I have been always trendy, however the jack on the Xperia X is very sensitive and does knuckle all the time which makes volume go up and down. The jack on the 10 II is better, but also knuckles although the phone is few months old and I almost did not use it.
Ah and before you tell something. I tried different jacks, excluding golden ones :confused:

Also I would never wear something wireless close to my brain (remember 1in distance according FCC AFAIR). But for the car BT is the best choice.

Thank you also for the link. I could at least test this and adopt it if it works until it goes into the main branch

It seems, that’s the culprit, after BT is disabled, hciattach process stays on. Killing it manually allow BT to start properly next time and successfully connect to the other devices.
So yep, workaround works

1 Like

At my phone, bluetooth is behaving as normal after enabling flight mode, if there has been no bluetooth device connected to it during enabling the flight mode.

if a device is connected duri g enabling the flight mode, I cannot turn BT on again after enabling the flight mode and a restart of the phone is needed.

So my workaround is:
Switch of my BT headphones, than switch on flight mode, switch on BT again and switch on the headphones again. No problems with this sequence so far.

But of course it is a workaround and should not be an intended behaviour :slight_smile: