| piggz | mal: spiiroin_: got debugging added to lipsticj and eglfs plugin, so can see how long it takes from button to lipstick getting message https://hastebin.com/silecanadi.yaml | 08:11 |
|---|---|---|
| piggz | now just to wait for it to do fail! | 08:11 |
| piggz | mal: spiiroin_: this one is 2.5 seconds from power to screen ... didnt get a panic led, but close https://hastebin.com/balekijige.yaml | 10:20 |
| piggz | interesting is the 1 second gap inside lipstick, lines 16 and 43 | 10:20 |
| piggz | this one did trigger the led, and lost 1.5 seconds inside lipstick https://hastebin.com/fexuxutaji.yaml | 10:30 |
| piggz | ill 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 dbus | 10:39 |
| T42 | <elros34> bluetooth off/on and wlan there could be ton of messages there | 10: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 this | 10:52 |
| piggz | ok, 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 https://hastebin.com/ejupawukim.yaml | 11:55 |
| piggz | in the middle is a weird lipstick - technology is null message, not sure its relevant | 11: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 |
| piggz | spiiroin_: im open to suggestions :) | 12:07 |
| piggz | though, a quick simple fix would also be appreciated :D | 12: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 delay | 12:10 |
| piggz | spiiroin_: connman is now disabled ... screen came up quickly ... ill test over the next 30-60 mins# | 12:12 |
| piggz | spiiroin_: normally at this point it would be slow, and its coming up faster than usual, so could be that | 12:13 |
| piggz | spiiroin_: https://hastebin.com/makohusoto.php less than a second | 12: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 |
| piggz | spiiroin_: no, it is fully asleep | 12:20 |
| piggz | if i show the full log, you get... | 12:20 |
| piggz | INFO: TF-A resuming on CPU 0 | 12:20 |
| piggz | and if i enable console messages, should also get the cpu sleep messages | 12:21 |
| piggz | so, i think this connman issue is good | 12:21 |
| piggz | spiiroin_: full sleep/resume cycle https://hastebin.com/unewufokox.yaml | 12:22 |
| piggz | and | 12:23 |
| piggz | [root@PinePhone ~]# mcetool --get-suspend-stats | 12:23 |
| piggz | uptime: 10477.868 | 12:23 |
| piggz | suspend_time: 9092.939 | 12:23 |
| spiiroin_ | I get ~ 150 ms display wakeup time. Nice. | 12:24 |
| piggz | spiiroin_: so .... connman .... :) | 12:25 |
| piggz | would it be useful to add dbus-monitor into the mix? system or session bus? | 12:27 |
| mal | piggz: did this have some of those config changes? | 12:27 |
| piggz | mal: yeah, though, i dont have usb connected atm, so it wouldnt be reacting to usb | 12:28 |
| piggz | the only config change for connman is the config file that doesnt ignore usb | 12:29 |
| mal | piggz: which device is this? | 12:30 |
| piggz | mal: pinephone | 12:32 |
| mal | piggz: so old not pro? | 12:32 |
| mal | piggz: you have small difference in pine vs pro connman configs | 12:33 |
| piggz | mal: correct. not pro | 13:15 |
| piggz | mal: DontBringDownAtStartup ? | 13:19 |
| *** ggabriel is now known as Guest446 | 13:19 | |
| piggz | mal: its still starting up fast, so def connman related | 13:20 |
| mal | piggz: just wondering what that option does and could it cause some odd issues | 13:23 |
| mal | piggz: maybe try changing it on non-pro device to see how it behaves then | 13:23 |
| piggz | mal: changed it, started connman ... startup was slow | 13:24 |
| piggz | not 110 seconds, but much slower than 1s | 13:24 |
| mal | so what is connman doing to block things | 13:24 |
| piggz | mal: bluetooth stuff it seems https://hastebin.com/fagehesici.yaml | 13:27 |
| mal | strange | 13:28 |
| piggz | does connman do much with BT ? | 13:28 |
| piggz | we dont to BT PAN do we? | 13:29 |
| piggz | spiiroin: https://hastebin.com/fagehesici.yaml << connman bluetooth messages maybe? | 13:32 |
| mal | piggz: I wonder why you have different main.conf compared to other devices, I mean not just the usb rndis changes but otherwise | 13:36 |
| piggz | mal: what else is different? | 13:36 |
| piggz | dylan made those changes years ago | 13:37 |
| piggz | so could be some unnescessary stuff | 13:37 |
| mal | piggz: https://pastebin.com/Ui3p6Pd8 from x10 III | 13:37 |
| piggz | mal: probably back then it was quite the same, but not kept up to date with changes in the the main conf | 13:37 |
| spiiroin | piggz: adding "--profile" option for dbus-monitor makes more compact output, but yeah: connman and wpa supplicant things happening | 13:38 |
| piggz | mal: trying that config with usb changes | 13:39 |
| piggz | if i can get it to wake up :D | 13:40 |
| spiiroin | I'm not sure, but it could be something like: wlan scanning happens simultaneously with display wakeup? | 13:40 |
| piggz | spiiroin: https://hastebin.com/xopiluzori.yaml there is a lot of bluetooth GetProperties in there! | 13:44 |
| T42 | <elros34> "bluetooth.target: Unit not needed anymore. Stopping". then lets load bluetooth again | 13:49 |
| piggz | mal: also that ^^ is with this config https://hastebin.com/satoyojoju.ini | 13:49 |
| piggz | @elros34 so, the bt service is stopping/starting each wake right | 13:51 |
| piggz | i wonder how to ahndle that | 13:51 |
| T42 | <elros34> that how it looks like, you have even some firmware loading rtl8723cs_xx_config less than 1secund later | 13:54 |
| piggz | asking kernel dev if there is any kernel params/options to configure how bt behaves | 13:55 |
| T42 | <elros34> still this Getproperties flood probably could be improved, why not wait for change instead polling via dbus | 13:58 |
| piggz | @elros34 tempted to rebuild connman with --disable-bluetooth :D | 14:16 |
| T42 | <elros34> or remove RTL firmware:) | 14:19 |
| piggz | i do wonder what connman needs BT support for | 14:22 |
| piggz | spiiroin: interesting .... just having a loooooong hang.... | 14:32 |
| piggz | lots of | 14: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 |
| piggz | so, even with bt disabled in connman, it still does that flood | 14:39 |
| T42 | <elros34> so what ask connman about these properties: busctl? | 14:43 |
| mal | piggz: what dbus message is not being replied to? | 14:48 |
| piggz | mal: take a look ... its a long log! https://privatebin.net/?d8f33b9829daf5f3#6pse2pguQsrVu9RJ1Qtn7AvVBuy8rFqnjyTjhsSsevGj | 14:56 |
| T42 | <elros34> so what is 1.41 and 1.164 in busctl output? | 14:57 |
| T42 | <elros34> or 1.62 because i change over time | 14:58 |
| T42 | <elros34> isn't that lipstick which asks about the same all the time? | 14:58 |
| piggz | ill 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 logs | 15:01 |
| piggz | its def got itself in a state at the moment! | 15:02 |
| piggz | but 1.41 and 1.164 are still present in the logs | 15:03 |
| piggz | :1.164 connman.service - | 15:04 |
| piggz | :1.41 2828 connectionagent defaultuser | 15:04 |
| piggz | :1.41 user@100000.service - - | 15:04 |
| piggz | stopping that service helped, but there is still a long delay between 1.162 and 1.164 with the blutooth GetProperty messages | 15:09 |
| piggz | :1.162 7422 booster [silica defaultuser | 15:10 |
| piggz | :1.162 session-1.scope 1 | 15:10 |
| piggz | and thats not useful | 15:10 |
| T42 | <elros34> maybe it's simple as some qml part of lipstick querying bluetooth status | 15:18 |
| piggz | about 10000 times? :D | 15: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 |
| spiiroin | piggz: 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 |
| spiiroin | mal: do you remember ^ | 15:37 |
| mal | spiiroin: can't remember, need to think | 15:55 |
| spiiroin | mal: it was in jolla-common-configurations, max raised from 128 default to 512 - which seems to be in use in piggz's case above | 16:43 |
| spiiroin | surfaced due to some wifi & connection manager things during bootup / user change. but maybe something in pp wlan behavior tickles something similar | 16:45 |
| spiiroin | piggz: limit ought to be in /usr/share/dbus-1/system.d/dbus-sailfish-busconfig.conf if you want to experiment with higher values | 16:48 |
| spiiroin | (it most likely is not just about max pending calls, but the original 128 value was way too small) | 16:49 |
| piggz | spiiroin: still ... the huge amount of messages sill causes delays ... even if its not for 100 seconds | 16:49 |
| spiiroin | part 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 is | 16:52 |
| spiiroin | using limit that is too big to be used for real can perhaps be helpful for debugging as different kinds of problems rise to top | 16:56 |
| *** attah_ is now known as attah | 21:07 | |
| *** kimmoli_ is now known as kimmoli | 21:10 | |
| *** attah_ is now known as attah | 22:00 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!