System_Error has quit [Ping timeout: 264 seconds]
System_Error has joined #maemo-leste
mkfx has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daanct12 has quit [Client Quit]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.6.1]
Daanct12 has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #maemo-leste
fmg_d4 has joined #maemo-leste
fmg_d4 has quit [Ping timeout: 252 seconds]
<freemangordon> Wizzup: strip? it is build with -O2
<freemangordon> and no '-g'
Daanct12 has quit [Quit: WeeChat 4.6.1]
Daanct12 has joined #maemo-leste
pabs3 has quit [Read error: Connection reset by peer]
pabs3 has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.6.1]
<freemangordon> ok, on a33 with chimaera, the same test program uses 58280 RES
<freemangordon> 76704 RES on n900 and 81632 RES on d4 with daedalus
Daanct12 has joined #maemo-leste
<freemangordon> Wizzup: ok, what I see as a major strace difference chimaera vs daedalus, is that chimaera uses lots of lstat64 calls when looping through theme images, while daedauls uses readlink
System_Error has quit [Ping timeout: 264 seconds]
Daanct12 has quit [Quit: WeeChat 4.6.1]
Daanct12 has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> freemangordon: those readlink lines are also the main diff between strace running with calculator (stock) vs calculator (qt5ct tweak) FYI
<arno11> *on daedalus
<freemangordon> arno11: by saying "diff" do you mean they are absent or that lstat is used instead of readlink?
<arno11> i mean they are absent
<arno11> hmm there are not absent in fact, just a lot more without tweak
<arno11> *hundreds more
System_Error has joined #maemo-leste
<freemangordon> ok, have to run now, but later on will put some traces in gtk/maemo style plugins, to see who does that
<arno11> ok
System_Error has quit [Remote host closed the connection]
arno11 has quit [Ping timeout: 244 seconds]
System_Error has joined #maemo-leste
fmg_d4 has joined #maemo-leste
Twig has joined #maemo-leste
mkfx has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
mkfx has joined #maemo-leste
Pali has joined #maemo-leste
<arno11> Wizzup: able to get ringtone working: the problem was only @idle, screen off. renicing dbus-daemon @-5 (like fremantle) solves the issue
<arno11> but still the sphone crash if you don't click on 'mute ringing' before answering
<arno11> so it seems to be 2 different issues
<Wizzup> seems like a race condition if renice matters
<arno11> hm seems -5 is not enough @100% of time, -8 is fine
<arno11> yeah
<Wizzup> I'm worried that just renicing something solves problems
<Wizzup> We really ought to fix any underlying problems
<Wizzup> surely dbus-daemon isn't soo slow that it cna't deal with a few things in 5-10 seconds
<arno11> ok
<arno11> at least, renice could be useful for sicelo to avoid missed calls :P
arno11 has quit [Ping timeout: 252 seconds]
arno11 has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.6.1]
uvos has joined #maemo-leste
<uvos> arno11: im working on fixing the sphone crash
<uvos> not that this will help you
<uvos> since after the fix sphone will still exit, it just wont assert, since its in an situation it cant recover from
<arno11> ok that's fine
<arno11> btw, any idea why if i click on 'mute ringtone' before answering, it avoids the crash ?
<uvos> sphone crashes because libpulse reports that it lost its connection to the pa server
<uvos> muteing ringtone causes the hifi stream to be idle when the ucm profile gets switched
<uvos> presumably this avoids pa breaking somehow
<uvos> presumably what is happening is that pulseaudio crashes when a voice call is entered while the hifi stream is active
<uvos> pulseaudio crashing then takes down sphone with it
<arno11> ah ok makes sense
<arno11> could it be possible to add a function to mute ringtone when clicking on 'answer' to avoid this kind of situation ?
<uvos> no
<uvos> switching proflile while the steam is active is fully valid
<uvos> theres a bug somewhere that needs to fixed
<Wizzup> yes, as I also stated, pa fails on my d4 regularly in asserts
<Wizzup> I would not be surprised if this is the same on n900
<Wizzup> and this gets logged to /var/log
<arno11> i didn't see any other troubles atm but i didn't try mpv (which is usually a bit buggy on n900)
<arno11> but yeah maybe something a bit different in PA 16, no ?
<Wizzup> looks like the ai crawler have found our git.maemo.org and are crawling the wholdr droid4-linux repo
<Wizzup> so useful
<arno11> oh cool
akossh has joined #maemo-leste
<arno11> wow lot of failures in /var/log @PA
<arno11> *indeed
<arno11> i wonder if our default.pa is correct btw
<Wizzup> what kind of failures
<arno11> [pulseaudio] module.c: Module "module-switch-on-port-available" should be loaded once at most. Refusing to load.
<arno11> *when sphone crashes @ringtone
<Wizzup> that does not seem like a failure
<arno11> sorry was not talking about failures i see, just PA msg @crash
<arno11> i.e @failure:
<Wizzup> so you're saying there is no crash message logged?
<Wizzup> if my PA crashes I see 'assertion failed... aborting'
<Wizzup> or similar
<Wizzup> ser
<arno11> ok, no 'assertion failed' for me, but let me double check
<arno11> indeed, no similar failure on my device
<arno11> at least in syslog, maybe visible elsewhere ?
<arno11> ah i remember..yeah i see similar failure in sphone logs
<arno11> 'assertion...failed at../src/pulse/thread-mainloop.c:166, function pa_threaded_mainloop_stop(), Aborting
<Wizzup> I think it's user.log but not sure on top of my head
_fab has quit [Quit: _fab]
_fab has joined #maemo-leste
<sicelo> Wizzup: hoping your battery woes are over?
<Wizzup> looks like it so far
<sicelo> lovely :-)
arno11 has quit [Quit: leaving]
<Wizzup> quite insane how many /16's I had to block to get rid of the overly aggressive crawlers
<sicelo> yes those are a real nightmare
Juesto has joined #maemo-leste
Juest has quit [Ping timeout: 265 seconds]
Juesto is now known as Juest
mkfx has left #maemo-leste [Disconnected: Replaced by new connection]
mkfx has joined #maemo-leste
<freemangordon> Wizzup: seems realpath() implementation in glibc has changed
<freemangordon> this is called several times by sapwood engine for each image
<freemangordon> however, to me it seems we have an issue with fs on n900
<freemangordon> that code should not take that much time, even for 1000 files
<Wizzup> yeah, I doubt that this is the problem
<Wizzup> @ realpath
<Wizzup> maybe we can revisit some tunables that we may have set in the past in sysctl - I don't think we do that any more, right
<freemangordon> like what?
tvall has quit [Read error: Connection reset by peer]
<freemangordon> also, I may implement some filename caching in sapwood, but not sure what side effects it may have
<freemangordon> I wonder if we have some kernel issue, or dunno
<Wizzup> freemangordon: don't know, I just remembered arno tried some things, but if this is a fs regression somehow it'd be kernel side
<Wizzup> but that should be the same on chimaera
<freemangordon> having swap on emmc should not slow down the system
<Wizzup> it could be we have slightly more ram pressure and suddenly vfs is not ok? no idea
<freemangordon> or that, yeah
<freemangordon> anyway, calling that code 1000 times should not take 3 seconds, even on n900
<freemangordon> (1000 being some arbitrary value)
tvall has joined #maemo-leste
<freemangordon> ok, the real value is 409
<freemangordon> Wizzup: how to install the new upower?
<sicelo> just apt update
<sicelo> in fact, dpkg -l upower ... what does yours return?
<freemangordon> upower 1:0.99.11.1-1+m7
<freemangordon> so, this one has epoch
<freemangordon> I don;t think we have upower in the repos
arno11 has joined #maemo-leste
<arno11> Wizzup: i doublechecked, no more custom sysctl stuff or similar in daedalus and chimaera-devel. still some weird stuff only in stock chimaera
<freemangordon> how to check on the device?
<arno11> you mean for sysctl or upower ?
<freemangordon> sysctl
<arno11> check in /etc/sysctl.d
<arno11> for n900 perf something
<arno11> the file should be empty
<freemangordon> there is only a symlink
<arno11> yeah so that's 'fine'
<freemangordon> mhm
<arno11> brb
<freemangordon> Wizzup: btw, noatime has huge impact on n900
<arno11> on daedalus ? i use it and don't feel too much diff
<arno11> but maybe depending of sdcard
<freemangordon> mine is fast, on theory
<freemangordon> *in theory
<arno11> ok
<arno11> what kind of improvement you see btw ?
<arno11> (just curious, to test)
<freemangordon> ssh console session becomes way more responsive
<arno11> ah ok, interesting (i don't use it most of the time)
apac has joined #maemo-leste
arno11 has quit [Ping timeout: 265 seconds]
arno11 has joined #maemo-leste
<sicelo> Wizzup: another leste-config MR ... to update the hwclock once ntpdate has updated system clock - https://git.maemo.org/leste/leste-config/pulls/61
<sicelo> been driving me mad for some time
<freemangordon> what the "-rw-r--r-- 1 root root 102598896 Jan 3 2023 /usr/lib/arm-linux-gnueabihf/libLLVM-15.so.1" ?!?
<uvos> whats wierd about that?
<uvos> you suprised llvm is big? or that you have an old version installed?
<freemangordon> big
<sicelo> freemangordon: upower - weird, it's definitely here, https://maedevu.maemo.org/leste/pool/main/u/upower/ ... but indeed i can't find with `apt-cache policy upower`
<uvos> freemangordon: llvm is kinda amazingly small given what it supports
<freemangordon> uvos: ok, won't argue, it is just that 100MB so seems kind of oversized to me :)
<uvos> i suspect we could make it smaller by limiting the targets we compile in, theres like 50 gpu isa backends in there that are known to be pretty large
<uvos> we obv dont need to compile shaders for random desktop gpus..
<freemangordon> anyway, I don;t think it is related to the issue we see on n900
<uvos> sure only a small part of that should end up in ram on n900
<freemangordon> there is some general slowness, it feels like device runs on 125 MHz all the time
<freemangordon> but that's not the case, for sure
<uvos> i presume the other obvious case is also not present
<freemangordon> it seems that QT (or general) memory usage has increased
<uvos> (too mutch memory pressure)
<freemangordon> yeah, perhaps we hit that
<freemangordon> as my test program startup time varies between 3s and 10s
<arno11> hmm, on my device, i don't see too much diff in term of memory usage, neither general slowness
<uvos> you run with stuff turned off no?
<arno11> only for qt
<uvos> ok
<uvos> like if your desperate for ram you could drop conversations/tp/vcm and re enable sphones messageing, at the cost of ritch messaging support ofc.
<uvos> but that should save quite the chunk
<arno11> conversation + vcm etc don't use too much ram honestly
<arno11> and new converstions_slim is nice
<freemangordon> using maemo-launcher strips 1 second off startup time of the test app
<freemangordon> so it start in 2700ms
<arno11> freemangordon: i'm a bit surprised your device seems slow. i mean my daedalus seems smoother and faster (apart qt) thand fremantle
<arno11> *than
Twig has quit [Remote host closed the connection]
<freemangordon> well, maybe I access it mostly over ssh
<freemangordon> and wifi latency seems big
<arno11> ah ok
<arno11> btw i doubt ram or swap usage is a problem. at least not more than chimaera (see tg-desktop working)
<arno11> and at least with sd card swap
<Wizzup> freemangordon: I think we have upower withotu epoch now
<freemangordon> Wizzup: where? https://paste.debian.net/1371784/
<freemangordon> do I miss a repo?
<sicelo> ah, i see ... you don't have -devel enabled
<sicelo> i also didn't until just now .. the correct upower does show up now
<freemangordon> oh, I didn't know there is daedalus-devel repo :)
apac has quit [Ping timeout: 276 seconds]
akossh has quit [Quit: Leaving.]
fmg_d4 has quit [Quit: fmg_d4]
Pali has quit [Quit: Pali]
arno11 has quit [Quit: leaving]
uvos has quit [Quit: Konversation terminated!]
mkfx has left #maemo-leste [#maemo-leste]
Anasko has joined #maemo-leste
vectis_ has quit [Read error: Connection reset by peer]
vectis_ has joined #maemo-leste