| Wizzup | YAY | 00:14 |
|---|---|---|
| Wizzup | # uname -a | 00:14 |
| Wizzup | Linux (none) 5.15.2-00597-g68be8fac7cbd #48 SMP PREEMPT Sat Dec 11 00:14:05 CET 2021 armv7l GNU/Linux | 00:14 |
| Wizzup | # grep ^core_pwrdm /sys/kernel/debug/pm_debug/count | cut -d',' -f2,3 | 00:15 |
| Wizzup | OFF:20,RET:10 | 00:15 |
| Wizzup | uvos: it might make sense to check if OMAP4_THERMAL makes on the d4 too | 00:16 |
| Wizzup | makes a difference* | 00:19 |
| Wizzup | ok | 00:42 |
| Wizzup | I think that's all I can do wrt idle right now - there's a reproducible test case wrt mmc that causes panics when the system idles, and on 5.15.y we can now hit off mode with init=/bin/bash and idle at 27mW | 00:43 |
| Wizzup | when I boot to maemo leste rescue mode I can actually hit RET sometimes, but not yet OFF | 00:43 |
| Wizzup | tmlind: ^^ :) | 00:43 |
| Wizzup | uvos: yeah the razr has a nice screen | 00:48 |
| Wizzup | ok, I think I can make tsc2005 behave | 02:58 |
| Wizzup | but that really will happen after sleep :) | 02:58 |
| Wizzup | I just need to make sure on suspend the irq is disabled, and on resume it is enabled, and that they are balanced | 03:01 |
| * Wizzup zzzz | 03:01 | |
| freemangordon | ugh, triple-buffering that I implemented is incorrect :( | 09:32 |
| freemangordon | I wonder if I can get armsoc dri2 code and implant it in omap driver | 09:32 |
| Wizzup | freemangordon: what is incorrect about it? | 12:37 |
| Wizzup | tmlind: I know it's weekend and all so no rush, but if you have some time could you comment on my tsc2005 patches? With those applied, tsc2005 does not keep the device awake unless the fd is opened (it's fine after probe, and after fd release) | 12:40 |
| Wizzup | I suspect the next step is making it auto idle like you did with the droid4 ts atmel_mxt driver | 12:40 |
| freemangordon | Wizzup: not sure I can explain, but it is wrong | 12:57 |
| freemangordon | and I guess tearing is because of that, low FPS too | 12:57 |
| freemangordon | it seems I have implemented double-buffering with 3 buffers :) | 13:00 |
| Wizzup | freemangordon: aha | 13:14 |
| uvos | freemangordon: so you wait on the wrong buffer to be free? | 13:20 |
| freemangordon | or rather - do not mark buffer as free when it should be | 13:28 |
| freemangordon | or somesuch, I am not exactly sure what's wrong | 13:28 |
| Wizzup | hm looks like CONFIG_TIMER_STATS would be useful but they removed it from kernel | 16:35 |
| Wizzup | tracers are supposed to replace it? | 16:35 |
| uvos | Wizzup: i mean yeah | 16:50 |
| uvos | you can use the tracer to monitor the timer functions and see what callbacks they call | 16:50 |
| Wizzup | It's frustrating to just see delayed_work_timer_fn at the top always in powertop | 16:50 |
| uvos | so its techicly possible to get this information but this seams way way harder than | 16:51 |
| uvos | what CONFIG_TIMER_STATS seams to have been | 16:51 |
| Wizzup | it looks like CONFIG_TIMER_STATS would actually break it down per kernel thread and userspace process | 16:51 |
| uvos | yeah | 16:51 |
| Wizzup | but it broke container namespace whatever | 16:51 |
| Wizzup | blergh... | 16:51 |
| Wizzup | the commit that removes it also doesn't really say how to do it lol | 16:51 |
| Wizzup | 'traces replace it' | 16:51 |
| Wizzup | ok | 16:51 |
| Wizzup | btw I think I fixed the sgx-ddk-um upgrade path again | 16:52 |
| uvos | btw sgx still blocks idle all the time on my d4 | 16:52 |
| uvos | no idea why yet | 16:52 |
| uvos | only rmmod helps | 16:52 |
| Wizzup | this is leste? | 16:52 |
| uvos | yeah | 16:52 |
| uvos | its only this one d4 | 16:52 |
| Wizzup | maybe try to upgrade to latest kernel and such | 16:52 |
| uvos | really strange | 16:52 |
| Wizzup | hmm interesting | 16:52 |
| uvos | i have | 16:52 |
| Wizzup | I also have some droids that use more power than they should even when not turned on | 16:53 |
| Wizzup | (on lab psu) | 16:53 |
| uvos | ok | 16:53 |
| Wizzup | I had one, now I have two that do that | 16:53 |
| uvos | but its fine with sgx not loaded | 16:53 |
| Wizzup | but idk if that's sgx | 16:53 |
| uvos | so i doubt its that | 16:53 |
| Wizzup | mhm, weird | 16:53 |
| Wizzup | yeah | 16:53 |
| uvos | i should try if it follows the sdcard | 16:54 |
| Wizzup | yes | 16:54 |
| Wizzup | freemangordon: btw I can't get the n900 to behave even with CMA size of 64MB | 16:58 |
| Wizzup | so there might be something else going on | 16:59 |
| freemangordon | Wizzup: hmm? | 17:00 |
| freemangordon | what do you mean? | 17:00 |
| Wizzup | X11 segfaults quite quickly | 17:00 |
| freemangordon | segfaults like? | 17:00 |
| Wizzup | let me check you an error, sec | 17:01 |
| freemangordon | cannot allocate BOs? | 17:01 |
| Wizzup | it's still booting, sec | 17:03 |
| Wizzup | I can usually get it to crash by just starting one or two apps and clicking on a menu | 17:03 |
| Wizzup | [ 177.206359] cma: cma_alloc: reserved: alloc failed, req-size: 375 pages, ret: -16 | 17:04 |
| Wizzup | [ 177.206359] cma: cma_alloc: reserved: alloc failed, req-size: 375 pages, ret: -16 | 17:04 |
| Wizzup | (EE) | 17:05 |
| Wizzup | (EE) Backtrace: | 17:05 |
| Wizzup | (EE) | 17:05 |
| Wizzup | (EE) Segmentation fault at address 0x10 | 17:05 |
| Wizzup | so it looks like something doesn't check if cma alloc is ok or something | 17:05 |
| freemangordon | hmm: | 17:05 |
| freemangordon | OS error code 16: Device or resource busy | 17:05 |
| freemangordon | weird | 17:05 |
| Wizzup | I don't know what causes that exactly, but it happens within 30s of using the device for me | 17:06 |
| freemangordon | Wizzup: it seems omapdrm doesn't handle EBUSY from cam allocator | 17:06 |
| freemangordon | *CMA | 17:06 |
| freemangordon | Wizzup: is that with 3-buffer enabled? | 17:06 |
| freemangordon | Wizzup: could you try to disable zram? and enable swap on eMMC? | 17:07 |
| Wizzup | I don't have that set | 17:07 |
| Wizzup | 3-buffer | 17:08 |
| Wizzup | either yes or no | 17:08 |
| Wizzup | just not in config | 17:08 |
| freemangordon | Wizzup: it is 'on' by default | 17:08 |
| Wizzup | ok | 17:08 |
| freemangordon | if you have that code ofc | 17:08 |
| Wizzup | I'll just turn off swap alltogether I guess | 17:08 |
| Wizzup | not sure @ code | 17:08 |
| Wizzup | iirc we are lacking at least one commit | 17:08 |
| freemangordon | ok, then it is not 3-buffer | 17:08 |
| freemangordon | anyway, one of the things I will do when I fix tearing/fps is to teach omapdrm to export non-CMA allocated memory as well | 17:09 |
| Wizzup | I'm going to look at moving the experimental ddx + 5.15 kernel to -devel btw | 17:09 |
| Wizzup | freemangordon: ok | 17:09 |
| freemangordon | then we will not need CMA, but ordinary DMA mem | 17:10 |
| Wizzup | I think we will not make n900 use the new ddx yet, there are a few other instable factors there anyway | 17:10 |
| Wizzup | freemangordon: great | 17:10 |
| freemangordon | yeah, makes sense | 17:10 |
| freemangordon | uvos: do you have any idea how dri2 buffer management is supposed to work? | 17:10 |
| uvos | freemangordon: no i dont | 17:30 |
| Wizzup | uvos: wonder if this still applies and is of some use http://www.360doc.com/content/14/0223/12/10366845_354967422.shtml | 17:32 |
| uvos | freemangordon: all isent big change from 2 -> 3 was that in 2 glx allocates buffers in the server while in 3 the clients allocate buffers,this subtaly breaks glx and i had to fight this in some sci applications, no idea how this works in egl or any real details | 17:32 |
| Wizzup | it uses omap3 as example | 17:32 |
| freemangordon | uvos: yes, I know the diff between 2 and 3, the point is that i don't know dri2 buffer lifecycle | 17:33 |
| uvos | yeah sorry | 17:33 |
| freemangordon | I'll try to find something over the inet | 17:33 |
| uvos | i know less here then you most likely | 17:33 |
| freemangordon | yeah | 17:34 |
| uvos | but i gues the buffer lifecylce has to be controlled by x | 17:34 |
| freemangordon | could be | 17:34 |
| uvos | it really has to | 17:34 |
| freemangordon | but I need to find some docs on the matter | 17:34 |
| uvos | since for glx the surface is managed by x | 17:34 |
| uvos | and must have its lifetime | 17:34 |
| Wizzup | uvos: fwiw this seems useful https://embeddedbits.org/tracing-the-linux-kernel-with-ftrace/ | 17:34 |
| uvos | er the windows lifetime | 17:34 |
| uvos | (in glx you just give the surface id to x and you can then draw onto the surface, even if your not the process that created the surface) | 17:36 |
| uvos | ie x mangaes life | 17:36 |
| uvos | clearly | 17:36 |
| uvos | Wizzup: right | 17:36 |
| uvos | Wizzup: just tracin the right functions should work | 17:37 |
| uvos | but i mean | 17:37 |
| uvos | this is lots of work and requires you to know how the kernel timer subsystem works exactly | 17:37 |
| Wizzup | I mean it has some stuff for wakeups, maybe the gui tools can visualise where they come from | 17:37 |
| Wizzup | uvos: yes, at least to know how to tracing subsystem works | 17:37 |
| Wizzup | https://static.lwn.net/images/conf/rtlws11/papers/proc/p02.pdf | 17:40 |
| Wizzup | parazyd: | 19:17 |
| Wizzup | pine*) skip_arm_defice_root="yes" | 19:17 |
| Wizzup | this can't be right | 19:17 |
| Wizzup | defice? | 19:17 |
| uvos | um why has image building been faling sine october? | 22:53 |
| uvos | parazyd: ^^^ | 22:53 |
| Wizzup | uvos: the server that we used for it went down for unknown reasons - not our control | 22:55 |
| Wizzup | so I set up one today at home | 22:56 |
| Wizzup | parazyd was working on fixing it | 22:56 |
| Wizzup | but stopped short of adding the amprolla host key | 22:56 |
| Wizzup | which was the last thing to do I think | 22:56 |
| Wizzup | so they'll work again soon | 22:56 |
| Wizzup | also when returns I'm first in line since I want him to add droid3 to arm-sdk | 22:56 |
| Wizzup | I already added it to image builder | 22:56 |
| Wizzup | :P | 22:56 |
| Wizzup | the ssi error predates v5.11 | 23:12 |
| Wizzup | *sigh* | 23:12 |
| uvos | btw just updating to experimental dosent work | 23:21 |
| uvos | the old -sgx-omap4 packages conflict the mesa libgl and friends | 23:22 |
| Wizzup | uvos: what do you run exactly? | 23:23 |
| uvos | apt upgrade | 23:24 |
| Wizzup | that can never work | 23:24 |
| Wizzup | apt upgrade will never allow a package to be removed | 23:24 |
| uvos | ok | 23:24 |
| Wizzup | you must use apt dist-upgrade | 23:24 |
| Wizzup | or apt full-upgrade | 23:24 |
| uvos | ok | 23:24 |
| Wizzup | unfortunately | 23:24 |
| Wizzup | the one thing I can do is make stub packages for the old pvr-omap4 packages that are just there doing nothing | 23:24 |
| uvos | ok | 23:25 |
| Wizzup | but I don't think apt dist-upgrade too much of an ask tbh | 23:25 |
| uvos | also tklock is infuriatingly lsow | 23:25 |
| uvos | apt is a bit wierd | 23:25 |
| uvos | but its ok | 23:25 |
| Wizzup | yeah, I wanted to make apt upgrade work but I looked it up and it can't work | 23:26 |
| uvos | oh grat | 23:26 |
| uvos | now lifeguard shutdown my system during the upgrade | 23:26 |
| Wizzup | https://superuser.com/questions/1554163/what-is-the-difference-between-apt-dist-upgrade-and-apt-upgrade | 23:26 |
| Wizzup | >apt upgrade will upgrade all packages that can be upgraded without the need to install additional packages or remove any conflicting installed packages. Basically it will apply all package upgrades that do not include changed dependencies. | 23:26 |
| Wizzup | uvos: huh why did it do that? | 23:26 |
| uvos | because the old dsme had a bug that caused deamons to crash when reloaded to fast | 23:26 |
| Wizzup | ah | 23:27 |
| uvos | and then dmse helpfully distroys the system by shuting down during apt upgrade | 23:27 |
| uvos | we need new images | 23:27 |
| Wizzup | 5.7.y is very unhappy in drm, so this bisect for the modem will be *fun* | 23:27 |
| Wizzup | uvos: yes, I've done my part, parazyd can finish it soon I hope | 23:28 |
| uvos | Wizzup: btw | 23:32 |
| uvos | it would also be very usefull | 23:32 |
| uvos | if we acctually packaged the version of rwmem that the droid4-powermanagement script uses | 23:32 |
| uvos | as it stands | 23:32 |
| uvos | the blockers dont work | 23:32 |
| Wizzup | modem works on v5.7.y at least | 23:33 |
| uvos | because there is no rwmem | 23:33 |
| Wizzup | hm | 23:33 |
| Wizzup | doesn | 23:33 |
| Wizzup | 't busybox have that? | 23:33 |
| uvos | it dose | 23:33 |
| Wizzup | but not in debian | 23:33 |
| uvos | but the script dosent sue busybox's rwmem | 23:33 |
| Wizzup | so what do we depend on? | 23:33 |
| uvos | we have to package something | 23:33 |
| uvos | and with the version of rwmem i have it reports everything blocking all the time | 23:34 |
| uvos | because the output is formated slightly different | 23:34 |
| uvos | we should just package whatever version of rwmem tmlind used... | 23:34 |
| uvos | ok i finished upgrading the october image to experimental | 23:35 |
| uvos | lets see if it wokrs | 23:35 |
| Wizzup | ok | 23:35 |
| Wizzup | please suggest what to use wrt rwmem and I'll do it | 23:35 |
| uvos | Wizzup: idk i use this https://github.com/tomba/rwmem | 23:36 |
| uvos | but it has slightly different output as allready stated | 23:37 |
| uvos | ofc this isent a real problem the script is easly ajusted for this rwmem | 23:37 |
| uvos | but we just need to package _some_ rwmem | 23:37 |
| Wizzup | preferrably something in the repos if it exists | 23:38 |
| uvos | afaik nothing exists | 23:38 |
| uvos | https://github.com/maemo-leste/droid4-pm/pull/2/files | 23:39 |
| uvos | here is how the script needs changing btw | 23:39 |
| Wizzup | do you mean -f4? | 23:39 |
| Wizzup | also what rwmem does tony use then if the one from tomba doesn't have the same output | 23:40 |
| uvos | yeah well we also want to remove the ts warning | 23:40 |
| uvos | no idea | 23:40 |
| uvos | upgrade worked | 23:40 |
| uvos | lets move this to devel | 23:40 |
| Wizzup | :) | 23:40 |
| uvos | or stable | 23:40 |
| Wizzup | I don't think stable is a good idea just yet | 23:41 |
| Wizzup | I do see some xorg crashes still | 23:41 |
| Wizzup | but not many | 23:41 |
| uvos | xorg crashes more often on stable | 23:41 |
| Wizzup | heh | 23:41 |
| uvos | open a gtk3 context menu | 23:41 |
| Wizzup | in any case letting things cook for a week or two in -devel hurts noone | 23:41 |
| uvos | its like 10% chance of crash | 23:41 |
| uvos | or rotate him | 23:41 |
| Wizzup | hmmm | 23:41 |
| uvos | 100% chance of crash | 23:41 |
| uvos | if you start with protrait | 23:41 |
| Wizzup | still, let's do -devel first | 23:41 |
| uvos | ok | 23:41 |
| Wizzup | it's also not ready for the n900 yet | 23:42 |
| uvos | the more concerning thing | 23:42 |
| uvos | is the hang in wlcore | 23:42 |
| Wizzup | are we sure it's wlcore? | 23:42 |
| uvos | yes | 23:42 |
| uvos | i can repoduce it | 23:42 |
| Wizzup | also I haven't seen many resets in the last week or so | 23:42 |
| Wizzup | uvos: ah | 23:42 |
| uvos | by weaking the wlan signal | 23:42 |
| Wizzup | uvos: maybe it's related to the (potential) mmc we're seeing on the n900 with off mode enabled | 23:42 |
| uvos | it happens when the wlan signal is weak and it (almost) looses the connection | 23:42 |
| Wizzup | as in, are we sure it's new in 5.15? | 23:42 |
| uvos | its new yeah | 23:42 |
| uvos | in something after 5.11 | 23:43 |
| Wizzup | well, you might be able to bisect if you can reproduce it | 23:43 |
| Wizzup | yeah I know what I'm asking :P | 23:43 |
| uvos | i can repoduce it | 23:43 |
| uvos | but it takes quite long | 23:43 |
| Wizzup | I can relate :P | 23:43 |
| uvos | i have to move the device in and out of the microwave multiple times | 23:43 |
| Wizzup | lol | 23:43 |
| uvos | the best way to tirgger it is actually movein around on campus | 23:44 |
| uvos | or in an aldi | 23:44 |
| uvos | (anywhere with spotty public wifi it wants to connect to) | 23:44 |
| Wizzup | I'll have to try find an aldi then :-p | 23:45 |
| Wizzup | still something after 5.11 might be only ~13 attempts | 23:47 |
| Wizzup | it'll probably take 8 hours | 23:47 |
| Wizzup | could it be some patch we carry on top of 5.11? | 23:47 |
| Wizzup | that is missing from 5.15? | 23:47 |
| uvos | Wizzup: i would not know what that would be | 23:48 |
| uvos | afaik we dont carry any stability patches | 23:48 |
| uvos | besides my devel 5.15 kernel started by merging my stuff on top of 5.11 on 15 | 23:48 |
| Wizzup | I mean we carry quite some patches no? | 23:48 |
| uvos | and both that and the leste kernel exibit the crash | 23:48 |
| Wizzup | ok | 23:49 |
| uvos | right but any patch we carry on 5.11 is on 5.15 too at least in my tree | 23:49 |
| uvos | (since i just merged | 23:49 |
| uvos | ) | 23:49 |
| Wizzup | ok | 23:49 |
| uvos | ok so on my fresh image freshly upgraded | 23:49 |
| uvos | debugfs is not mounted | 23:49 |
| Wizzup | right, this is a problem as well, and parazyd was looking into using /etc/fstab.d | 23:51 |
| Wizzup | I don't know what the status is | 23:51 |
| Wizzup | uvos: pls create an issue for rwmem packaging if you can | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!