vendor.dataqti keeps crashing
-
Hi all,
Trying to use my 'Surya' Poco X3 as a glorified power sipping SBC (for automotive telematics being the end goal) though it hasn't left my lab desk yet...
Since a few days (dunno when it started, but less then 4 days ago, wasn't keeping an eye on it)
These keep popping up in dmesg, and it seems this triggers enough cpu/irq switches that power use tripled from a steady 300mW to 900mW (unless that's a side affect of a power profile issue since I also see healthd: Unknown power supply type 'Batt_Verify' )
[Sun May 25 20:34:53 2025] init: Service 'vendor.dataqti' (pid 7108) exited with status 255 [Sun May 25 20:34:53 2025] init: Sending signal 9 to service 'vendor.dataqti' (pid 7108) process group... [Sun May 25 20:34:53 2025] libprocessgroup: Successfully killed process cgroup uid 1001 pid 7108 in 0ms [Sun May 25 20:34:53 2025] init: updatable process 'vendor.dataqti' exited 4 times in 4 minutes [Sun May 25 20:34:53 2025] init: Unable to set property 'ro.init.updatable_crashing_process_name' to 'vendor.dataqti' from uid:0 gid:0 pid:1: Read-only property was already set [Sun May 25 20:34:53 2025] init: Unable to set property 'ro.init.updatable_crashing' to '1' from uid:0 gid:0 pid:1: Read-only property was already set [Sun May 25 20:34:53 2025] init: starting service 'vendor.dataqti'... [Sun May 25 20:34:53 2025] init: Created socket '/dev/socket/qti_dpm_uds_file', mode 660, user 1001, group 1001For context: wifi is kept on hotspot via nmcli (called if needed via nodered running on the phone), and there's an openvpn client always on (so I can ssh back to it freely). but I don't see this being a cause anyways, it ran quiet and reliably for days... while I know qti is part of Qualcomm's suite of tools, I don't really know what QTI does besides crashing every few seconds
/system/vendor/bin/qti is used in /system/vendor/etc/init/dataqti.rc in turn called from various 'start vendor.dataqti' in /system/vendor/bin/init.class_main.sh
The continous crashes if not triggering power draw, does trigger lots of noise... but doesn't affect network performance
Can anyone help me in debugging this ? I'm not good at all these Android layered shenanigans and dunno how to tinker with it's rc.init system
Thanks
-
Hmmm
strace seems to give something:
# strace -p $(pgrep -f "/system/vendor/bin/qti") ... a few lines later ... openat(AT_FDCWD, "/dev/rmnet_ctrl", O_RDWR) = -1 ENOENT (No such file or directory) getuid() = 1001 writev(5, [{iov_base="\0\264-\271\0054h\217hr7", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:758] qti"..., iov_len=117}], 4) = 142 getuid() = 1001 writev(6, [{iov_base="l\225\0\351\3\264-", iov_len=7}, {iov_base="\0\264-\271\0054h\217hr7", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:758] qti"..., iov_len=117}], 5) = 149 nanosleep({tv_sec=1, tv_nsec=0}, 0x7feb611ed0) = 0 openat(AT_FDCWD, "/dev/rmnet_ctrl", O_RDWR) = -1 ENOENT (No such file or directory) getuid() = 1001 writev(5, [{iov_base="\0\264-\272\0054h\305\221\48", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:758] qti"..., iov_len=117}], 4) = 142 getuid() = 1001 writev(6, [{iov_base="l\225\0\351\3\264-", iov_len=7}, {iov_base="\0\264-\272\0054h\305\221\48", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:758] qti"..., iov_len=117}], 5) = 149 nanosleep({tv_sec=1, tv_nsec=0}, 0x7feb611ed0) = 0 openat(AT_FDCWD, "/dev/rmnet_ctrl", O_RDWR) = -1 ENOENT (No such file or directory) getuid() = 1001 writev(5, [{iov_base="\0\264-\273\0054h\316\2\2208", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:758] qti"..., iov_len=117}], 4) = 142 getuid() = 1001 writev(6, [{iov_base="l\225\0\351\3\264-", iov_len=7}, {iov_base="\0\264-\273\0054h\316\2\2208", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:758] qti"..., iov_len=117}], 5) = 149 nanosleep({tv_sec=1, tv_nsec=0}, 0x7feb611ed0) = 0 getuid() = 1001 writev(5, [{iov_base="\0\264-\274\0054h\324y\3558", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:775] qti"..., iov_len=124}], 4) = 149 getuid() = 1001 writev(6, [{iov_base="l\234\0\351\3\264-", iov_len=7}, {iov_base="\0\264-\274\0054h\324y\3558", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:775] qti"..., iov_len=124}], 5) = 156 getuid() = 1001 writev(5, [{iov_base="\0\264-\274\0054h\316\232\2079", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:832] qti"..., iov_len=125}], 4) = 150 getuid() = 1001 writev(6, [{iov_base="l\235\0\351\3\264-", iov_len=7}, {iov_base="\0\264-\274\0054h\316\232\2079", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_rmnet_peripheral.c:832] qti"..., iov_len=125}], 5) = 157 getuid() = 1001 writev(5, [{iov_base="\0\264-\274\0054h\2\t\3609", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_main.c:720] main():Failed t"..., iov_len=70}], 4) = 95 getuid() = 1001 writev(6, [{iov_base="lf\0\351\3\264-", iov_len=7}, {iov_base="\0\264-\274\0054h\2\t\3609", iov_len=11}, {iov_base="\6", iov_len=1}, {iov_base="QTI_SDM_INFO\0", iov_len=13}, {iov_base="[qti_main.c:720] main():Failed t"..., iov_len=70}], 5) = 102 mprotect(0x7fa8a56000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x7fa8a56000, 4096, PROT_READ) = 0 mprotect(0x7fa8a56000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x7fa8a56000, 4096, PROT_READ) = 0 mprotect(0x7fa8a56000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x7fa8a56000, 4096, PROT_READ) = 0 munmap(0x7fa8a56000, 4096) = 0 exit_group(-1) = ? +++ exited with 255 +++I think I read about a missing /dev/rmnet_ctrl somewhere causing issues
-
@jaxx To lower power draw you can change the governor to powersave, see this.
About the crashing qti service, since the device works properly without it working, I believe it should be safe to disable it (don't have a qualcomm device to test this). I thought UT 20.04 and onwards uses exclusively systemd and not init.rc?
-
Hi (again
)Oddly, changing governor didn't help (nor did disabling most cores)
I did comment out the start vendor.dataqti from the script and rebooted and it didn't help
the base system is systemd, but it launches the "fake" android (imported from the the original android image) via lxd and tons of bindings between the two spaces ... the android side has it's own historic management system ...
anyways, I'm trying out postmarketOS, much cleaner systemwise imho, I don't even care the cameras don't work actually (and a modern kernel, but a different approach than piggybacking on android images) just gotta find out why the devices stalls sometimes and LTE doesn't work
-
@jaxx
About dataqti service, take a look at :
https://gitlab.com/ubports/porting/community-ports/android10/xiaomi-poco-x3/xiaomi-surya/-/merge_requests/21About powersaving, please see :
https://codeberg.org/EricHeintzmann/UbuntuTouch/issues/24Any help will be welcome
