TOHKBD2 problems with Firmware 2.1.1.23 - 2.1.1.26 (Early Access)

[ummon29]

Having the TOHKBD2 (or any other Other Half) attached during bootup results in an Jolla1 without working WLAN or mobile connection. If the TOHKBD2 is attached after the booting everything (including the TOHKBD2) is working as expected. Without much of an investigation on my side, the most plausible explanation I have found is that a systemd update causes trouble with the module loading order during bootup.

There are some reports on together.jolla.com and talk.maemo.org. This one for example: https://together.jolla.com/question/164495/21123-o-mobile-connection-nor-wlan-on-j1/

Best regards and thanks for all your Work

[spiiroin]

The fix could use more extensive testing, but at least the phone seems to boot up without issues and the systemd-udev-settle.service failure is gone.

[OlegGirko]

I've encountered this problem as well. There is no update containing #68 in Jolla Store, and I didn't know that I have to manually add OBS repo to get further updates.

So, I had to investigate and found the following.

The problem can also be worked around by increasing timeout in systemd-udev-settle.service (by specifying -t 300 args to udevadm and by changing TimeoutSec parameter 310). This makes udevd to proceed further after about 200 seconds, but it complains that toh-core.0 takes too long. And this adds extra 200 seconds to startup time, obviously. Journal for tohkbd2.service shows that it starts after the timeout. This is an indication that there is some kind of dependency loop that is not detected by systemd because it doesn't know that systemd-udev-settle.service waits for harbour-tohkbd2.service.

No networking problem is caused by connman.service to dependent recursively on droid-hal-init.service (that doesn't start at all) and then on systemd-udev-settle.service (that doesn't start because its ExecStart command fails). Not starting droid-hal-init.service causes many other problems (like no bluetooth adapter detected).

I think, this confirms that systemd wants droid-hal-init.service to finish before harbour-tohkbd2.service:

[root@Sailfish nemo]# systemctl --no-pager -l list-dependencies --recursive --before droid-hal-init.service
droid-hal-init.service
● ├─bluetooth.service
● ├─ftd.service
● ├─ofono.service
● ├─sensord.service
● ├─basic.target
● │ ├─alien-service-manager.service
● │ ├─alien-settings.service
● │ ├─aliendalvik.service
● │ ├─autologin@100000.service
● │ ├─bluetooth.service
● │ ├─connman-vpn.service
● │ ├─connman.service
● │ ├─display.service
● │ ├─fastdormancy.service
● │ ├─ftd.service
● │ ├─harbour-tohkbd2.service
● │ ├─init-actdead-cpu.service
● │ ├─init-done.service
● │ ├─jolla-devicelock-encpartition.service
● │ ├─limit-cpu.service
● │ ├─mount-sd@mmcblk1.service
● │ ├─odnpd.service
● │ ├─ofono.service
● │ ├─oneshot-root-late.service
● │ ├─oneshot-root.service
● │ ├─policies-setup.service
● │ ├─rescue-password-off.service
● │ ├─runlevel-actdead-done.service
● │ ├─runlevel-user-done.service
● │ ├─sailfish-hciwait.service
● │ ├─sensorfwd.service
● │ ├─sshd.service
● │ ├─start-user-session.service
● │ ├─systemd-ask-password-wall.service
● │ ├─systemd-hostnamed.service
● │ ├─systemd-logind.service
● │ ├─systemd-user-sessions.service
● │ ├─tohd.service
● │ ├─udisks2.service
● │ ├─user@100000.service
● │ ├─wayland.service
● │ ├─wpa_supplicant.service
● │ ├─actdead-pre.target
● │ │ └─actdead.target
● │ ├─factory-test.target
● │ └─multi-user.target
● │   └─graphical.target
● └─network.target
●   ├─aliendalvik.service
●   └─multi-user.target
●     └─graphical.target

Hence, it waits because droid-hal-init.service has:

Wants=systemd-udev-settle.service
After=local-fs.target systemd-udev-settle.service

Please note Wants directive that means that droid-hal-init.service doesn't start after systemd-udev-settle.service fails, but it doesn't invalidate the whole transaction, and harbour-tohkbd2.service starts eventually, but it's too late.

Of course, my knowledge of systemd unit dependencies is limited, so I'm not absolutely sure if my analysis is completely right. But if it's right, fix in #68 is the right one because it breaks this dependency loop and allows delayed start of harbour-tohkbd2.service without timing out udev rule that makes systemd-udev-settle.service to time out and fail.

Finally, I'd like to suggest that it would be better if updated version of harbour-ambience-tohkbd2 was published in Jolla Store to make those who installed it from there to have fixed version automatically.

[kimmoli]

Release 0.5.26 in harbour contains #68

[OlegGirko]

Looks like I have a problem with Jolla Store on my phone as well. I was recovering it from botched upgrade, so it may still have issues unrelated to this one.