| uvos | ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/defrag' | 00:01 |
|---|---|---|
| uvos | heh i accutally do that on my laptop :P | 00:01 |
| uvos | (systemd serivce) | 00:01 |
| Wizzup | I tried the sysctl and it didn't work | 00:03 |
| Wizzup | setting it to 0 | 00:03 |
| Wizzup | disabling the CONFIG_COMPATION now | 00:03 |
| Wizzup | (on top of 5.15) | 00:04 |
| Wizzup | if this works I'll be very happy :) | 00:04 |
| Wizzup | uvos: looks like that alone is not enough on 5.15 | 00:18 |
| uvos | hmm | 00:19 |
| Wizzup | I meant it idles better | 00:19 |
| Wizzup | but it doesn't hit OFF mode | 00:19 |
| Wizzup | but other things probably changed since v5.9 | 00:19 |
| uvos | dose it hit off on 5.9 with it removed? | 00:19 |
| uvos | there must be a btter way to debug kernel timers | 00:19 |
| Wizzup | you mean config right, not commit reverted? | 00:19 |
| uvos | echo never > /sys/kernel/mm/transparent_hugepage/defrag | 00:20 |
| uvos | just that | 00:20 |
| uvos | on your bisect end | 00:20 |
| Wizzup | bash: /sys/kernel/mm/transparent_hugepage/defrag: No such file or directory | 00:20 |
| Wizzup | uvos: looking at the commit, it always does the wakeup, no? | 00:20 |
| uvos | i dont think it should get there at all with defrag disabled | 00:22 |
| * Wizzup going revert commit regardless | 00:22 | |
| uvos | but i dident read anything beyond that commit | 00:22 |
| uvos | maybe also disable hugepages entirely | 00:22 |
| uvos | those are mostly useless on n900 | 00:22 |
| uvos | what are you gonna do? allocated a 64mb page on n900? :P | 00:23 |
| Wizzup | mhm | 00:26 |
| Wizzup | well let me see if I reverted this commit correctly first | 00:26 |
| Wizzup | if it then works, then we can look at using config | 00:26 |
| Wizzup | it hits off only a bit with that commit reverted | 00:29 |
| Wizzup | so I guess next steps is to see what else breaks it | 00:29 |
| uvos | wee | 00:29 |
| uvos | lets best figure out how to trace kernel timers | 00:29 |
| Wizzup | root@(none):/root# ./idle.sh | 00:29 |
| Wizzup | ST_SDRC,ST_OMAPCTRL | 00:29 |
| Wizzup | OFF:1,RET:62 | 00:29 |
| Wizzup | better than zero right | 00:29 |
| uvos | surely there is debug output with what timers are registered | 00:29 |
| uvos | and how often they fire | 00:29 |
| Wizzup | tmlind: might know, I definitely don't | 00:30 |
| Wizzup | iirc he suggested bisecting the problem | 00:30 |
| uvos | if linux cant provide that i suggest porting hildon to nt :P | 00:33 |
| Wizzup | lol | 00:34 |
| Wizzup | I bet that alone might keep it awake or something | 00:34 |
| uvos | Im sure the thought keeps at least fmg awake. | 00:34 |
| Wizzup | lol | 00:36 |
| Wizzup | I think there are probably more power regressions btw | 00:36 |
| Wizzup | 5.15 idles at 0.019A vs 0.011A (yes, that is incl. the 0.004A of my serial) | 00:37 |
| Wizzup | uhh so 72mW vs 42mW | 00:37 |
| Wizzup | some of that is off mode (I suspect 19mW | 00:37 |
| Wizzup | ) | 00:37 |
| Wizzup | but there's another 12mW that went somewhere | 00:37 |
| bencoh | :( | 00:42 |
| Wizzup | let's hope it's just as bisectable | 00:43 |
| Wizzup | first trying v5.9.y with the commit reverted | 00:43 |
| bencoh | alright, enabling /sys/kernel/debug/tracing/events/power/cpu_idle/enable is kinda stupid/useless | 00:45 |
| Wizzup | yeah so 5.9.y with the commit reverted and the config off looks mostly ok | 00:49 |
| Wizzup | will try v5.9 for good measure (5.9.y doesn't idle the panel, but that's solved elsewhere...) | 00:50 |
| Wizzup | yeah plain v5.9 with the commit reverted idles for sure | 00:58 |
| Wizzup | uvos: ok yeah disabling the CONFIG_COMPACTION is enough on top of 5.9 | 01:06 |
| Wizzup | same for v5.10, although the panel not idling the display makes it harder to read.. | 01:20 |
| Wizzup | looks like the other few mw might be drm related, but I think that's for another day | 01:22 |
| Wizzup | yup, that's panel/drm relatd | 01:24 |
| Wizzup | Summary: 1.3 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 0.3% CPU | 02:11 |
| Wizzup | :) | 02:11 |
| enyc | Wizzup: hrrm is that "powertop" showing wakeups/set, or other ways to notice that ? | 04:13 |
| tmlind | Wizzup: nice find! | 07:32 |
| sicelo | 🎉 | 07:37 |
| freemangordon | nice! | 08:01 |
| dsc_ | is there a way to detect leste is running on a droid4? | 10:07 |
| Wizzup | enyc: powertop | 10:36 |
| Wizzup | dsc_: thebquestion probably is why | 10:37 |
| dsc_ | fair enough | 10:43 |
| Wizzup | dsc_: as in you can get the dpi from X | 10:53 |
| Wizzup | it might not give you the right dpi atm, but that is something we can fix without device specific hacks :P | 10:53 |
| dsc_ | yeah nvm ;p | 10:54 |
| Wizzup | tmlind: my mail to ngupta got denied, by "outlook protection", let's hope the ml ones reach him ;) | 10:56 |
| dsc_ | Wizzup: we'll have to start thinking about telepathy stuff soon | 10:58 |
| Wizzup | yes | 10:58 |
| Wizzup | I hope that today I can bisect the modem breakage and the other pm problem | 10:58 |
| Wizzup | and apart from the audio not probing (probably easy fix) that means I could use the n900 for tp-idle | 10:58 |
| Wizzup | there's also someone who wanted to help out with gnu-ring/jami and/or tox part of it | 10:59 |
| uvos | you can not get dpi from x on leste | 11:01 |
| uvos | we break it on purpose force setting 96dpi, otherwise x would report the correct dpi | 11:02 |
| Wizzup | why do we do that again? | 11:02 |
| uvos | but gtk2 is extreamly broken then, because nokia just increased font and element size in the ui istead of scaling it properly | 11:02 |
| Wizzup | right | 11:03 |
| dsc_ | uvos: so I query against el-v1.db via rtcom, filtered by "service_id: 3", which is `rtcom_el_get_service_id(el, "RTCOM_EL_SERVICE_SMS");` | 11:07 |
| uvos | right service 3 event type 14 | 11:07 |
| uvos | er 13 | 11:07 |
| uvos | you have to query agains that service and the event type SMS | 11:07 |
| dsc_ | regarding event_types, my database seems to always have `event_type: 11` when service_id is 3 | 11:08 |
| uvos | interesting | 11:08 |
| dsc_ | which is uhm | 11:08 |
| dsc_ | RTCOM_EL_EVENTTYPE_SMS_MESSAGE | 11:08 |
| uvos | huh thats wierd | 11:09 |
| dsc_ | sqlite> select name from EventTypes where id=11; | 11:09 |
| dsc_ | RTCOM_EL_EVENTTYPE_SMS_MESSAGE | 11:09 |
| uvos | sms saves and querys as RTCOM_EL_EVENTTYPE_SMS_MESSAGE https://github.com/maemo-leste/sphone/blob/e5ad31827650099a3cd85ea9a2400cb76633dae9/src/modules/store-rtcom.c#L74 | 11:09 |
| uvos | and i get id 13 in the database | 11:09 |
| dsc_ | can you try `select name from EventTypes where id=14;` | 11:09 |
| uvos | 14 is nothing | 11:10 |
| uvos | 13 is RTCOM_EL_EVENTTYPE_SMS_MESSAGE | 11:10 |
| dsc_ | ah k yep | 11:10 |
| uvos | as expected | 11:10 |
| dsc_ | ok I know whats going on | 11:11 |
| uvos | 11 is RTCOM_EL_EVENTTYPE_CHAT_LEAVE | 11:11 |
| dsc_ | fault on my side probably | 11:11 |
| uvos | Wizzup: can you give me os_idle_uc_audit_details.txt from sleep 20; omapconf audit os_idle full_log on d4 5.15 with leste booted normaly | 11:15 |
| Wizzup | uvos: sure, wifi on ok? | 11:15 |
| uvos | yeah over ssh is fine | 11:15 |
| uvos | on wifi | 11:15 |
| Wizzup | what are you looking for btw? | 11:16 |
| uvos | my device stopped ideling | 11:16 |
| Wizzup | huh | 11:16 |
| uvos | yeah no idea | 11:16 |
| Wizzup | uvos: https://dpaste.com/ENSJAUWD5 | 11:23 |
| uvos | diff: | GFX | Running | Gated | FAIL | | 11:25 |
| uvos | hmm ists sgx | 11:25 |
| tmlind | Wizzup: yeah ok let's hope his email still works | 11:28 |
| Wizzup | mhm | 11:28 |
| Wizzup | I'm going to see if I can quickly identify why 5.10.y doesn't idle at 0.007A but rather at 0.012A | 11:29 |
| Wizzup | it seems to be related to the panel being probed | 11:29 |
| Wizzup | as in, on v5.9 having panel probed doesn't cause the extra power hit | 11:30 |
| Wizzup | but there were only two small panel changes, so I suspect something else perhaps | 11:30 |
| dsc_ | uvos: when you have time kindly test latest `conversations`, it may have fixed the SMS thingy | 11:30 |
| dsc_ | devel is updated | 11:31 |
| uvos | dsc_: works | 11:34 |
| dsc_ | thanks! | 11:35 |
| uvos | but it dosent pick up the contact names | 11:35 |
| dsc_ | im reading `remote_uid` from table `Events` | 11:35 |
| Wizzup | tmlind: as in, it's not normal for the panel to use more power just when it's probed, right? or do I need to do additional work to idle it properly beyond setting backlight to 0 | 11:36 |
| uvos | right but sphone saves the number there | 11:36 |
| uvos | sphone saves the contact name in local_name so that it dosent have to look up the contacts so often in eds (its slow) | 11:37 |
| uvos | but i dont know if thats correct | 11:37 |
| Wizzup | there is a table in rtcom with remote info | 11:37 |
| Wizzup | so that it doesn't need to go in the event | 11:37 |
| dsc_ | the database I have *sometimes* saves the name into `remote_uid`: https://i.imgur.com/O8YwhdD.png | 11:38 |
| dsc_ | suppose local_name has precedence | 11:38 |
| uvos | the ones with names are just special numbers | 11:38 |
| uvos | or chat contacts that are unsernames | 11:38 |
| uvos | not contact names | 11:38 |
| uvos | sphone saves the remote user name or number in remote_uid | 11:39 |
| uvos | (ie what the backend needs to send a message to this person) | 11:39 |
| dsc_ | kk | 11:39 |
| uvos | and the name the user has saved in contacts for this person as local_name | 11:39 |
| uvos | but saving it in some other table might be better yeah | 11:40 |
| uvos | looks like your freemantle database dosent sue it at all | 11:40 |
| dsc_ | dont think there is another table for that | 11:40 |
| dsc_ | local_name is fine | 11:40 |
| dsc_ | ill fix it | 11:40 |
| uvos | no idea why they need selfhandle since the outgoing incoming prop also exists | 11:40 |
| dsc_ | right | 11:40 |
| Wizzup | afaik the table 'remotes' to be checked here | 11:42 |
| Wizzup | that is what the remote_uid is for? | 11:42 |
| uvos | [11:39] <uvos> sphone saves the remote user name or number in remote_uid | 11:43 |
| uvos | [11:39] <uvos> (ie what the backend needs to send a message to this person) | 11:43 |
| uvos | thats also what it looks to be for | 11:43 |
| dsc_ | oh. | 11:43 |
| uvos | the better question what the heck local_name is for if remotes table exists | 11:43 |
| Wizzup | likely librtcom-el has functions to match remote uids | 11:43 |
| Wizzup | local_name is *yourself* | 11:44 |
| Wizzup | local_uid TEXT, -- plugin local uid ('account' on a plugin/protocol) | 11:44 |
| Wizzup | local_name TEXT, -- seems to own irc nickname, etc <SelfHandle> for telepathy-ring | 11:44 |
| Wizzup | why it is necessary is a good question | 11:45 |
| Wizzup | tmlind: ok it's probably some drm interaction, I'll have to check that later, not sure how to continue atm - v5.10 is broken without stable patches (and also those need at least one commit reverted to work, so bisect might be quite hard) | 11:46 |
| dsc_ | the big question is, does the rtcomlib do a JOIN in order to resolve remote_uid's or not | 11:47 |
| Wizzup | use the source luke :-p | 11:47 |
| Wizzup | brb | 11:47 |
| dsc_ | ok | 11:48 |
| dsc_ | uvos: use the `Remote` table and set `remote_uid` accordingly :P | 11:49 |
| dsc_ | `Remotes`* | 11:49 |
| dsc_ | (if you arent yet) | 11:50 |
| lel | sanderfoobar closed an issue: https://github.com/maemo-leste/conversations/issues/2 (Ensure TextPlain) | 12:00 |
| tmlind | Wizzup: yeah that's time consuming with extra patches carried for bisect | 12:01 |
| uvos | dsc_: wait no | 12:04 |
| uvos | dsc_: its not right | 12:04 |
| uvos | dsc_: now it dosent show commtest threads | 12:04 |
| uvos | those are saved as RTCOM_EL_SERVICE_CHAT RTCOM_EL_EVENTTYPE_CHAT_MESSAGE | 12:05 |
| dsc_ | thats right, I'm only filtering for SMS currently | 12:05 |
| uvos | ok | 12:05 |
| dsc_ | I need to make a navigation bar where you can specify/filter on message types | 12:05 |
| uvos | ok | 12:05 |
| uvos | generally id also like a way to see what backend a thread is on, but im sure you have it planned | 12:06 |
| dsc_ | right | 12:06 |
| dsc_ | ill most likely change the chat window title for that `Conversations (SMS)` | 12:07 |
| dsc_ | `Conversations (IRC)` | 12:07 |
| dsc_ | suggestions welcome though :P | 12:08 |
| Wizzup | dsc_: re: backends, we'll get to that | 13:33 |
| Wizzup | I have some ideas about that too :) | 13:33 |
| Wizzup | tmlind: maybe I can rebase v5.10 and remove the other regressions (or insert the fixes right next to the offending commits) and bisect that rebased branch | 13:40 |
| Wizzup | uvos: btw when/if you have an idea about glamor and gles let me know and I'll try to build xorg-server on the pp | 13:51 |
| Wizzup | if we can alleviate some of the pains it's likely quite worth it | 13:51 |
| Wizzup | freemangordon: also if you recall what patches were needed for newer X / how you built it, please lmk | 13:51 |
| Wizzup | uvos: btw got a droid razr and droid razr maxx in post (shipped with this droid3) | 13:55 |
| Wizzup | not sure if they still work | 13:56 |
| freemangordon | Wizzup: for sure I disabled XWayland | 14:09 |
| Wizzup | but that would just be a configure, so you build it on your own device I guess, not with dpkg-buildpackage ? | 14:12 |
| tmlind | Wizzup: you can carry extra commits with git bisect, forgot the option for that | 14:18 |
| Wizzup | tmlind: ok | 14:20 |
| tmlind | Wizzup: see git bisect --help for hot-fix | 14:23 |
| tmlind | there's a sample script for bisecting with a hot-fix, i'm pretty sure there was some git specific command earlier for that, but i guess it's gone | 14:24 |
| Wizzup | ok | 14:26 |
| Wizzup | someone on the internet suggests this: git cherry-pick --no-commit hot-fix | 14:28 |
| uvos | Wizzup: what version of xt91x exactly? | 14:32 |
| freemangordon | Wizzup: I used debian packaging of 'our' xserver | 14:33 |
| Wizzup | freemangordon: ok, any new xproto required? | 14:33 |
| freemangordon | also, some newer xorg-protocols or somesich | 14:33 |
| freemangordon | yes | 14:33 |
| Wizzup | uvos: uh | 14:33 |
| Wizzup | uvos: where do you want me to check | 14:34 |
| freemangordon | yes, newer xproto | 14:34 |
| freemangordon | actually the latest one | 14:34 |
| Wizzup | tmlind: going for this: | 14:34 |
| Wizzup | git merge-base --is-ancestor 21b2cec61c04bd175f0860d9411a472d5a0e7ba1 HEAD && git cherry-pick f1e1be898042aff9be3e17c6c1e77513b52e4c4d --no-commit | 14:34 |
| Wizzup | git merge-base --is-ancestor fb2c599f056640d289b2147fbe6d9eaee689f1b2 HEAD && git cherry-pick 3992aa31bffa73683089d86b5fad3315e3c17fcd --no-commit | 14:34 |
| freemangordon | october 2021 or something | 14:34 |
| uvos | Wizzup: in android is there is in settings but on all other devices its written on it somewhere too | 14:34 |
| uvos | i think xt910 just has it written on the back | 14:35 |
| Wizzup | ok I haven't booted them just yet | 14:35 |
| uvos | just flip one over :P | 14:36 |
| Wizzup | xt912 and xt912 | 14:37 |
| Wizzup | but one is maxx | 14:37 |
| Wizzup | (yes same numbers) | 14:37 |
| uvos | they are the same yeah | 14:37 |
| uvos | its the same pcb | 14:37 |
| uvos | with just a different battery | 14:37 |
| uvos | rip | 14:37 |
| Wizzup | both non removable :D | 14:37 |
| uvos | yeah | 14:37 |
| uvos | thats the only variant with locked bootloader | 14:37 |
| Wizzup | I think once we've resolved all these n900 pm regressions we need to seriously considering setting up automated testing w/ power monitoring | 14:38 |
| uvos | Wizzup: so i seam to have lost the gles forcing patch, but its just forcing all context creation above here https://github.com/maemo-leste-upstream-forks/xorg-server/blob/maemo/ascii/glamor/glamor_egl.c | 14:43 |
| Wizzup | so just define GLAMOR_GLES2 ? | 14:44 |
| uvos | no | 14:45 |
| uvos | sry | 14:45 |
| uvos | i linked that wrong | 14:45 |
| uvos | because the code is different in older xserver | 14:45 |
| uvos | sec | 14:45 |
| uvos | https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L1021 | 14:45 |
| uvos | just make everything above that fail | 14:45 |
| uvos | that creates a context | 14:45 |
| uvos | (ie comment it out) | 14:45 |
| uvos | ie comment from https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L980 | 14:46 |
| uvos | to https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L1035 | 14:47 |
| uvos | should force gles | 14:47 |
| uvos | alternative approche to just test if gles is better is just to rm libgl.so | 14:47 |
| Wizzup | ok | 14:48 |
| uvos | also note gles glamor has had quite a few bug fixes | 14:48 |
| uvos | that are not in our old version | 14:48 |
| Wizzup | yeah we probably want new X | 14:48 |
| uvos | i dimly remember that gles on radon also only worked on latest master | 14:50 |
| uvos | with some additional prs applied | 14:50 |
| uvos | this one at least https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/401 | 14:51 |
| uvos | i think | 14:51 |
| Wizzup | if someone tells me how to build xproto stuff I can do it in my lxc thing | 14:51 |
| Wizzup | oh shit that's not even merged | 14:51 |
| uvos | yeah and it ainchent | 14:52 |
| uvos | and clearly correct | 14:52 |
| uvos | i dont get these people | 14:52 |
| Wizzup | well I get ignored by them so I'm not even going to bother | 14:52 |
| uvos | right | 14:53 |
| uvos | we might want to add an option to force gles in xorg.conf | 14:53 |
| uvos | but yeah they proububly will ignore it | 14:53 |
| freemangordon | Wizzup: could we discuss xorg tomorrow, I'll provide you glamor patches that are needed, for d4 at least | 14:54 |
| freemangordon | I don;t have time now | 14:54 |
| uvos | im pretty confident that it worked with master and just that patch on mesa | 14:54 |
| uvos | on llvm and on radeonsi | 14:54 |
| Wizzup | yes, tomorrow is fine although I might be afk some of the time then | 14:54 |
| freemangordon | me too, the point was that I cannot do it *now* :) | 14:56 |
| freemangordon | uvos: no reason to not have the patches needed for SGX, agree? | 14:57 |
| uvos | sure but he wants to test lima specificly | 14:57 |
| uvos | the glfinish patches for sgx for instance are just sgx being buggy probuly for instance | 14:58 |
| uvos | and just cause it to be slower | 14:58 |
| Wizzup | uvos: I renamed libGL.so.something and I am not sure if that was a good idea :P | 15:00 |
| Wizzup | let's do that later | 15:01 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/589 (Try new xorg server (with patches) and gles-glamor on pinephone/lima) | 15:03 |
| freemangordon | uvos: I agree about glFinish() patch, but others are different | 15:10 |
| Wizzup | freemangordon: maybe you can comment on the above issue tomorrow | 15:15 |
| Wizzup | tmlind: hm, my testing with the two commits I mentioned earlier reverted shows fee5be18524f961de653fe6103f927c84ebbfd38 as the first bad commit, but I am not sure how to interpret that since it's a merge | 17:05 |
| Wizzup | since it seems to relate to s390 fixes mostly? | 17:05 |
| Wizzup | I suppose that could happen if the behaviour was racy or something | 17:11 |
| uvos | hmm | 17:13 |
| uvos | thats a wierd commit | 17:14 |
| uvos | even if racy that dosent make any sense | 17:14 |
| Wizzup | right | 17:14 |
| uvos | whats this for? | 17:15 |
| uvos | the modem? | 17:15 |
| Wizzup | no, this is the extra power usage from v5.9 to v510 | 17:15 |
| Wizzup | when panel driver is loaded | 17:15 |
| Wizzup | is could just relate to the async probing somehow perhaps, but I have that reverted | 17:15 |
| Wizzup | from my earlier testing v5.9 idles fine at 0.007A whereas v5.10 idles at 0.012A or so | 17:16 |
| Wizzup | (both are in off) | 17:16 |
| Wizzup | rmmod on the panel module makes the problem go away on v5.10 | 17:16 |
| uvos | https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=s390-5.10-6&id=a2bd4097b3ec242f4de4924db463a9c94530e03a | 17:18 |
| uvos | https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=s390-5.10-6 | 17:18 |
| uvos | the commits on that merge | 17:19 |
| uvos | none of these make sense | 17:19 |
| Wizzup | yeah | 17:19 |
| Wizzup | I guess the problem is I probably made a good/bad mistake somewhere or something, and it's just inherently racy perhaps | 17:20 |
| Wizzup | it's definitely real though | 17:20 |
| uvos | yeah | 17:20 |
| uvos | one thing tho | 17:21 |
| uvos | the pannel | 17:21 |
| uvos | its stopped working at some point | 17:21 |
| uvos | there was a initalization race | 17:21 |
| uvos | i think this was around this time | 17:21 |
| Wizzup | yes, sre fixed that I think in this serise | 17:21 |
| Wizzup | that's only one of the two commits that touch the panel | 17:21 |
| Wizzup | but surely even if the panel now worked, it shouldn't use 0.005A more just because it's enabled (not on or anythign) | 17:22 |
| Wizzup | also at least in v5.9 I can turn off the panel without problems by loading the module, but yeah, maybe it's a panel pm thing or something... | 17:22 |
| uvos | the solution to the race was to reset the pannel again right? | 17:22 |
| Wizzup | that's what the commit said yeah | 17:22 |
| uvos | well the race might not be fully solved and the pannel ends up in a different hw state | 17:22 |
| uvos | ok but reseting the pannel should be quite sage | 17:23 |
| uvos | *safe | 17:23 |
| Wizzup | see 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a | 17:23 |
| Wizzup | well that was a waste of then, I'm no closer to a solution :) | 17:24 |
| Wizzup | uvos: selectively reverting 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a does seem to suggest it idles better without... | 17:37 |
| uvos | and keeping 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a and cyceling the pannel on and off | 17:38 |
| uvos | ? | 17:38 |
| Wizzup | how would I do that? | 17:41 |
| uvos | dpms? | 17:41 |
| Wizzup | uh I don't have basically any /dev nodes | 17:41 |
| Wizzup | let alone X or anythign else | 17:41 |
| uvos | we are gonna need dev nodes :P | 17:42 |
| uvos | you can use my program .. but it dident work | 17:42 |
| uvos | acutally | 17:42 |
| uvos | this might be related | 17:42 |
| Wizzup | I think I might give up on this one in a bit for now | 17:42 |
| uvos | since dpms fails in my dpms off program | 17:42 |
| uvos | that suggests something is wrong with it | 17:42 |
| uvos | the pannel driver that is | 17:43 |
| uvos | ok yeah giving up is also an option | 17:43 |
| uvos | its "just" 15mW | 17:44 |
| Wizzup | I meant for now mostly | 17:44 |
| Wizzup | I don't know how to debug this properly, I'll try a few more things: going to 5.15 and remove panel driver and see how that acts | 17:44 |
| Wizzup | and also go back to v5.9 once more and just confirm that indeed it's more stable / better pm | 17:44 |
| Wizzup | maybe sre can give it a look if it's clear the panel module probing has an effect | 17:44 |
| Wizzup | it's also possible that the panel drivers waits for drm and some other interaction for it to fully idle or something | 17:47 |
| uvos | i dont see why it should | 17:47 |
| uvos | except as a bug | 17:47 |
| uvos | but sure | 17:47 |
| Wizzup | yeah, what I mean is that I am testing in one specific way | 17:47 |
| uvos | could be hw bug that causes it to not idle untill the first frame even | 17:47 |
| uvos | or something like that | 17:47 |
| Wizzup | mhm | 17:47 |
| Wizzup | whatever it is, it's not present in v5.9 | 17:47 |
| Wizzup | but if that's because it never actually resets, yeah... | 17:48 |
| Wizzup | as in my test doesn't involve *using* the panel | 17:48 |
| Wizzup | I only probe the module to lower power usage for my tests (turn off screen, basically) | 17:48 |
| Wizzup | I think it might be best to send a mail about this so I don't forget but not investigate further - on 5.15 with my reverts/additions at least off mode it hit sometimes with the panel not probed, but there seems to be another power regression mostly preventing off mode since v5.10 and 5.15 | 17:54 |
| Wizzup | hey with both panel commits from v5.10 reverted it does go back to lower power | 20:03 |
| Wizzup | ok... | 20:03 |
| Wizzup | so it was 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a | 20:12 |
| Wizzup | if I can figure out what makes plain v5.11 not boot (it says it cannot execute init=/bin/bash) then I can could hopefully trace the last off mode problem | 20:14 |
| sicelo | 5.11 used to boot for me, and 5.12 | 20:17 |
| Wizzup | plain v5.11? | 20:19 |
| Wizzup | as in 'git checkout v5.11' ? | 20:19 |
| Wizzup | 5.11.y, v5.11 with stable patches boots form e | 20:19 |
| Wizzup | but that is useless for bisect since the first thing the bisect will do ignore all the stable patches | 20:20 |
| Wizzup | so I need to find the specific commits in 5.11.y and apply them at every bisect step if the offending commit is present during the bisect | 20:20 |
| Wizzup | which is *hands in hair* | 20:20 |
| sicelo | I see. Well it's been a while, so I am no longer too sure which particular 5.11/.12 I was booting | 20:21 |
| Wizzup | it's ok, I think I might have found it | 20:28 |
| Wizzup | I figured I might as well continue while I still the energy and will to work on this stuff | 20:28 |
| Wizzup | ah. | 20:46 |
| uvos | 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a is unlikely to be the real issue here | 20:46 |
| uvos | its just that without it the pannel is in some other state | 20:47 |
| uvos | that it happens to idle in | 20:47 |
| uvos | and after 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a its in power on reset | 20:47 |
| Wizzup | uvos: could be, but I hope that sre can take a look | 20:47 |
| Wizzup | btw v5.11 needs the mmc swap commit (1baa29c660b8b75c1cd06e743d9faca7ee323b1f) | 20:48 |
| sicelo | Yeah @mmc swap | 21:15 |
| Wizzup | tmlind: | 23:49 |
| Wizzup | $ git bisect bad | 23:49 |
| Wizzup | a82820fcd079e38309403f595f005a8cc318a13c is the first bad commit | 23:49 |
| Wizzup | commit a82820fcd079e38309403f595f005a8cc318a13c | 23:49 |
| Wizzup | Author: Adam Ford <aford173@gmail.com> | 23:49 |
| Wizzup | Date: Fri Sep 11 07:31:57 2020 -0500 | 23:49 |
| Wizzup | ARM: omap2plus_defconfig: Enable OMAP3_THERMAL | 23:49 |
| Wizzup | will email | 23:49 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
