Wednesday, 2022-11-30

piggzmal: spiiroin_: got debugging added to lipsticj and eglfs plugin, so can see how long it takes from button to lipstick getting message
piggznow just to wait for it to do fail!08:11
piggzmal: spiiroin_: this one is 2.5 seconds from power to screen ... didnt get a panic led, but close
piggzinteresting is the 1 second gap inside lipstick, lines 16 and 4310:20
piggzthis one did trigger the led, and lost 1.5 seconds inside lipstick
piggzill add some more debug to void LipstickCompositor::setUpdatesEnabled(bool enabled) but, it looks like the request is queued for later....10:32
T42<elros34> maybe check also what happens in dbus10:39
T42<elros34> bluetooth off/on and wlan there could be ton of messages there10:41
piggz@elros34 there could ... however, once its in lipstick, its all in-process ... it just happens that the route it takes invovles waiting on the event loop, or ... some dbus signals from QMce ... so, i need more debugging!10:49
T42<elros34> I think there was QDBUS_DEBUG=1 but it wont be easy to debug all of this10:52
piggzok, this one is better ... this was a huuuuge delay ... and it shows the delay between mce and lipstick was approx 110 seconds to receive the dbus message
piggzin the middle is a weird lipstick - technology is null message, not sure its relevant11:56
spiiroin_piggz: whoa. 110 secs. if you'd have "devel flavor" mce, it would already have core dumped lipstick (>30 secs iirc)12:05
spiiroin_I wonder if there could be some synchronous dbus activity / stte going on in lipstick? (that would block incoming message handling)12:06
piggzspiiroin_: im open to suggestions :)12:07
piggzthough, a quick simple fix would also be appreciated :D12:07
spiiroin_no quick fix but. there was/is some chance that something triggers avalanche of connman related dbus ipc. running dbus monitor / disabling wlan / stopping connman could give clues about whether something like that contributes to this display power up delay12:10
piggzspiiroin_: connman is now disabled ... screen came up quickly ... ill test over the next 30-60 mins#12:12
piggzspiiroin_: normally at this point it would be slow, and its coming up faster than usual, so could be that12:13
piggzspiiroin_: less than a second12:14
spiiroin_something like 400-800 ms would be normal. this is faster than that. makes me wonder: suspend/autosleep is not used?12:19
piggzspiiroin_: no, it is fully asleep12:20
piggzif i show the full log, you get...12:20
piggzINFO:    TF-A resuming on CPU 012:20
piggzand if i enable console messages, should also get the cpu sleep messages12:21
piggzso, i think this connman issue is good12:21
piggzspiiroin_: full sleep/resume cycle
piggz[root@PinePhone ~]# mcetool --get-suspend-stats12:23
piggzuptime:       10477.86812:23
piggzsuspend_time: 9092.93912:23
spiiroin_I get ~ 150 ms display wakeup time. Nice.12:24
piggzspiiroin_: so .... connman .... :)12:25
piggzwould it be useful to add dbus-monitor into the mix? system or session bus?12:27
malpiggz: did this have some of those config changes?12:27
piggzmal: yeah, though, i dont have usb connected atm, so it wouldnt be reacting to usb12:28
piggzthe only config change for connman is the config file that doesnt ignore usb12:29
malpiggz: which device is this?12:30
piggzmal: pinephone12:32
malpiggz: so old not pro?12:32
malpiggz: you have small difference in pine vs pro connman configs12:33
piggzmal: correct. not pro13:15
piggzmal: DontBringDownAtStartup ?13:19
*** ggabriel is now known as Guest44613:19
piggzmal: its still starting up fast, so def connman related13:20
malpiggz: just wondering what that option does and could it cause some odd issues13:23
malpiggz: maybe try changing it on non-pro device to see how it behaves then13:23
piggzmal: changed it, started connman ... startup was slow13:24
piggznot 110 seconds, but much slower than 1s13:24
malso what is connman doing to block things13:24
piggzmal: bluetooth stuff it seems
piggzdoes connman do much with BT ?13:28
piggzwe dont to BT PAN do we?13:29
piggzspiiroin: << connman bluetooth messages maybe?13:32
malpiggz: I wonder why you have different main.conf compared to other devices, I mean not just the usb rndis changes but otherwise13:36
piggzmal: what else is different?13:36
piggzdylan made those changes years ago13:37
piggzso could be some unnescessary stuff13:37
malpiggz: from x10 III13:37
piggzmal: probably back then it was quite the same, but not kept up to date with changes in the the main conf13:37
spiiroinpiggz: adding "--profile" option for dbus-monitor makes more compact output, but yeah: connman and wpa supplicant things happening13:38
piggzmal: trying that config with usb changes13:39
piggzif i can get it to wake up :D13:40
spiiroinI'm not sure, but it could be something like: wlan scanning happens simultaneously with display wakeup?13:40
piggzspiiroin: there is a lot of bluetooth GetProperties in there!13:44
T42<elros34> " Unit not needed anymore. Stopping". then lets load bluetooth again13:49
piggzmal: also that ^^ is with this config
piggz@elros34 so, the bt service is stopping/starting each wake right13:51
piggzi wonder how to ahndle that13:51
T42<elros34> that how it looks like, you have even some firmware loading  rtl8723cs_xx_config less than 1secund later13:54
piggzasking kernel dev if there is any kernel params/options to configure how bt behaves13:55
T42<elros34> still this Getproperties flood probably could be improved, why not wait for change instead polling via dbus13:58
piggz@elros34 tempted to rebuild connman with --disable-bluetooth :D14:16
T42<elros34> or remove RTL firmware:)14:19
piggzi do wonder what connman needs BT support for14:22
piggzspiiroin: interesting .... just having a loooooong hang....14:32
piggzlots of14:32
piggz[ 2830.668553] dbus-daemon[2079]: dbus-daemon[2079]: [system] The maximum number of pending replies for ":1.62" (uid=100000 pid=2880 comm="/usr/bin/lipstick -plugin evdevtablet:/dev/input/e") has been reached (max_replies_per_connection=512)14:32
piggzso, even with bt disabled in connman, it still does that flood14:39
T42<elros34> so what ask connman about these properties: busctl?14:43
malpiggz: what dbus message is not being replied to?14:48
piggzmal: take a look ... its a long log!
T42<elros34> so what is 1.41 and 1.164 in busctl output?14:57
T42<elros34> or 1.62 because i change over time14:58
T42<elros34> isn't that lipstick which asks about the same all the time?14:58
piggzill tell u as soon as i get a command prompt!15:00
T42<elros34> I think it's dynamic so better to do this during getting logs15:01
piggzits def got itself in a state at the moment!15:02
piggzbut 1.41 and 1.164 are still present in the logs15:03
piggz:1.164        connman.service           -15:04
piggz:1.41                                       2828 connectionagent defaultuser15:04
piggz  :1.41         user@100000.service       -          -15:04
piggzstopping that service helped, but there is still a long delay between 1.162 and 1.164 with the blutooth GetProperty messages15:09
piggz:1.162                                      7422 booster [silica defaultuser15:10
piggz  :1.162        session-1.scope           115:10
piggzand thats not useful15:10
T42<elros34> maybe it's simple as some qml part of lipstick querying bluetooth status15:18
piggzabout 10000 times? :D15:26
T42<elros34> there is bug which cause infinite calls with busy qml when you dismiss notification with actions so yeah why not:)15:27
spiiroinpiggz: we had to increase that max pending calls limit at some point in time - now, where was it done and is it in use in community ports too?15:36
spiiroinmal: do you remember ^15:37
malspiiroin: can't remember, need to think15:55
spiiroinmal: it was in jolla-common-configurations, max raised from 128 default to 512 - which seems to be in use in piggz's case above16:43
spiiroinsurfaced due to some wifi & connection manager things during bootup / user change. but maybe something in pp wlan behavior tickles something similar16:45
spiiroinpiggz: limit ought to be in /usr/share/dbus-1/system.d/dbus-sailfish-busconfig.conf if you want to experiment with higher values16:48
spiiroin(it most likely is not just about max pending calls, but the original 128 value was way too small)16:49
piggzspiiroin: still ... the huge amount of messages sill causes delays ... even if its not for 100 seconds16:49
spiiroinpart of the problem is that IIRC daemon just discards method call messages when limit is exceeded -> can lead to ipc timeouts, and retries, and retries of retries -> situation can linger, traffic can explode, and it becomes difficult to see what the actual problem is16:52
spiiroinusing limit that is too big to be used for real can perhaps be helpful for debugging as different kinds of problems rise to top16:56
*** attah_ is now known as attah21:07
*** kimmoli_ is now known as kimmoli21:10
*** attah_ is now known as attah22:00

Generated by 2.17.1 by Marius Gedminas - find it at!