@ikoz

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

@ikoz

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

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

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 1001

For 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

@ikoz

Hi,

Thanks for the reply...

Unfortunately , test_gps doesn't work at all ("**** GPS interface not found Bye!*" ), tried that yesterday, no wrapping around it would give anything... looks like that comes from the hybris stack for old android stuff that accessed GPS hardware directly...

Since I believe the hardware to be already locked/in use by the the software stack, I probably need to simulate the same approach (Qt > QtPosition or Dbus sessions ?)

I'll try working with QtPositioning somehow since GPSToolkit uses it

USB: yeah, i'll check again later, ideally, I just need a way to inject juice and have a single usb, dunno

Network:
Yeah, honestly, if it can be Hotspot AP + Station at the same time, all done in UI to keep my dirty fingers away of the network management, that'd be great, or even by splitting the radio chains, 2.4GHs AP, 5GHz Client if needed
I know the hardware can do it (because It did work before installing UBt)
But it's less of an emergency

Hi all !

I'm kinda new to the Ubuntu Touch fury and got it installed on a Poco X3 NFC i got on the cheap. a tad quirky but surprisingly nice.

My goal, tbh, wasn't even have it as a daily, but replacing a small RockPi SBC I have running in my car that is underpowered, despite chewing over >1W.

This averages 0.3W idle, with GPS+Wifi+LTE ... I don't need any GPIOs (but seems i'd have to live without OTG USB, unsure about that yet)

I got Supervisor, Mosquitto, node.js installed, and it starts node-red on boot (ressources are mostly under the phablet user to keep / read-only)

One of my issues is accessing GPS data (sure enough, first fix takes ages, but that's something else)

I am totally at lost about the whole lomiri stack, dbus is already hard enough (I deal with hundreds of linux servers all day) This is almost "hey son, can you fix my printer" territory

I can eavesdrop on the system dbus if I start GPS toolkit on the UI side:

# dbus-monitor --system
...
method call time=1747474346.025144 sender=:1.14 -> destination=:1.133 serial=117 path=/sessions/1; interface=com.lomiri.location.Service.Session; member=UpdatePosition
   double YY.096
   double X.83785
   boolean true
   double 74.9379
   boolean true
   double 10.5377
   boolean false
   int64 1747474346017862807
method call time=1747474346.028468 sender=:1.14 -> destination=:1.133 serial=118 path=/sessions/1; interface=com.lomiri.location.Service.Session; member=UpdateVelocity
   double 0
   int64 1747474346019894752
...

But I'd like to get things running using a python3 or node.js script, in the background.

import pydbus

# Connect to the system bus
bus = pydbus.SystemBus()

# Access the location service
location_service = bus.get('com.lomiri.location.Service')
#location_service = bus.get('com.lomiri.location.Service','/com/lomiri/location')

# Get the location
location = location_service.GetLocation()

print(f"Latitude: {location['latitude']}")
print(f"Longitude: {location['longitude']}")
print(f"Altitude: {location['altitude']}")

unfortunatly, that object doesn't export any interfaces (or GI is lacking stuff, dunno)

Ideally, i'd write i very light python3 daemon that would just update topics on the local mqtt so I can play with the data under node-red.

Thanks for any pointers in the right direction

JaXX./.

Sidequestions:
Would a USB-C hub be recognized ? (lsusb showed nothing) (damn, the thing draws 0.8W on it's own gotta find something else)
Under android, it was able to have an active hotspot (with clients) while being connected to home wifi, I'll explore that soon but if anyone had a clue on how to reproduce the same use-case, it'd be great (the idea would be having other wireless sensors connecting to the phone, but the phone using home wifi when available instead of being stuck on LTE)