| uvos | Wizzup: sure | 00:30 |
|---|---|---|
| uvos | so someone needs to try out/ set up charge-mode on pp | 00:30 |
| uvos | and emergency shell runlevel with fbkeyboard | 00:31 |
| uvos | also investigation on display brightness linearity | 00:31 |
| uvos | ie possibly setup https://github.com/maemo-leste/mce/blob/483c527164bc17898d400d9cd65d7b9408c3b30e/config/mce.ini#L327 for pp | 00:31 |
| Wizzup | hi ho | 00:31 |
| Wizzup | ok | 00:31 |
| uvos | also see if we need battery guard on pp and what https://github.com/maemo-leste/mce/blob/483c527164bc17898d400d9cd65d7b9408c3b30e/config/mce.ini#L301 to use | 00:31 |
| Wizzup | I wonder if we should try to get the new xorg as well | 00:31 |
| Wizzup | it might fix the modesetting problems | 00:31 |
| uvos | what modesetting ploblems do we have? | 00:32 |
| Wizzup | on the pinephone? | 00:32 |
| uvos | we have problems with glamor not modesetting no? | 00:32 |
| Wizzup | we have crashes, graphical glitches/damage update problems | 00:32 |
| Wizzup | well, there's a lot of glamor fixes too | 00:32 |
| uvos | also those would probubly be solved | 00:32 |
| uvos | if we where to use the gles path instead of the ogl one | 00:32 |
| Wizzup | (I counted about 80+ mentions of glamor in the changelog) | 00:32 |
| Wizzup | are you sure? I'm pretty sure we tried that in the past to no avail | 00:33 |
| Wizzup | we can try again of course | 00:33 |
| uvos | im not sure ofc | 00:33 |
| Wizzup | :p | 00:33 |
| uvos | i dont think you can make glamor choose gles | 00:33 |
| uvos | when ogl is available | 00:33 |
| uvos | other than a patch | 00:33 |
| Wizzup | I saw that new X has a check where if gl > 2.1 it will use gles or something | 00:33 |
| uvos | no i think it uses egl then | 00:34 |
| Wizzup | ah, no, that's < 2.1 | 00:34 |
| uvos | but maybe im miss remembering | 00:34 |
| Wizzup | ah, could be | 00:34 |
| Wizzup | no you're probably right | 00:34 |
| uvos | yeah it tries gles if gl is <2.1 | 00:34 |
| uvos | problem is pp ends up in ogl path | 00:34 |
| uvos | and ogl is known to be iffy on it | 00:34 |
| Wizzup | still there are a lot of fixes for glamor | 00:35 |
| uvos | yeah sure | 00:35 |
| Wizzup | uvos: do you know how to force it into gles path? | 00:35 |
| uvos | you have to patch the places where it calls epoxy | 00:35 |
| uvos | i did this before for my desktop to try the gles path on radeon | 00:35 |
| uvos | i can dig it up tomorrow | 00:35 |
| uvos | its just a oneliner ofc | 00:36 |
| Wizzup | ok | 00:36 |
| freemangordon | Wizzup: yes, I was able to build it, but I had to patch here and there | 07:49 |
| freemangordon | dsc_: BTW, if you are still bored, maybe you may want to look into SGX tearing issue. | 09:03 |
| Wizzup | ok re: xorg | 09:06 |
| Wizzup | it might be valuable to have it | 09:07 |
| freemangordon | yeah | 09:08 |
| freemangordon | but iirc it requires newer libwayland (or something) version | 09:09 |
| Wizzup | maybe we can just not build the wayland stuff, we don't need it | 09:09 |
| freemangordon | yeah | 09:09 |
| freemangordon | Xwayland that is | 09:09 |
| Wizzup | but maybe if uvos' idea about forcing gles glamor with lima works, we don't need to now | 09:09 |
| freemangordon | by forcing libepoxy to resolve to gles? | 09:09 |
| dsc_ | https://plak.infrapuin.nl/selif/5bmf43ow.jpg | 09:11 |
| dsc_ | scrolling is 30fps, pretty good | 09:12 |
| dsc_ | freemangordon: SGX tearing? | 09:13 |
| Wizzup | freemangordon: yes | 09:13 |
| dsc_ | I do see some tearing right now with my application but not sure if this is what you are refering to | 09:13 |
| dsc_ | i might be on an older kernel | 09:13 |
| dsc_ | was planning to spend the day looking at hamsterfiler, fixing SGX sounds scary, I only operate in userspace :P! | 09:14 |
| * Wizzup bbiab 45 mins or so | 09:15 | |
| freemangordon | dsc_: ah ok (only userspace) | 09:17 |
| dsc_ | only been using linux since a few months, I came from Flash development, barely know what a computer is - ill stick to user interfaces :PpPpP | 09:17 |
| freemangordon | ok, ok, got it :) | 09:17 |
| dsc_ | xD | 09:17 |
| Wizzup | uvos: freemangordon: heads up, I think the kernel in -experimental doesn't boot atm, investigating | 11:04 |
| Wizzup | ok it was related to thumb2 I think | 11:46 |
| Wizzup | that's silly | 11:46 |
| buZz | hehe, maybe soc only has thumb1 ? | 11:57 |
| bencoh | err, which SoC? | 11:58 |
| bencoh | thumb2 has been supported for ... ages :) | 11:58 |
| bencoh | (well, apart from erratas here and there) | 11:58 |
| buZz | hehe | 11:58 |
| Wizzup | droid4/droid3 | 11:59 |
| Wizzup | not sure what's up, but going to revert since I just want a kernel that works for everything :) | 11:59 |
| buZz | :) | 11:59 |
| buZz | i'm still sad that the docks dreamer found didnt exist :( | 11:59 |
| buZz | they are so rare to find on ebay without insane shipping :P | 12:00 |
| buZz | 5 usd dock , 30 usd shipping , ffs | 12:00 |
| buZz | :D | 12:00 |
| Wizzup | I wish the lapdock that I bought worked ;) | 12:00 |
| buZz | hmhm | 12:01 |
| buZz | my own lapdock needs a ton of work to get the keyboard to work without 10kg of pressure on the keys | 12:01 |
| buZz | :D | 12:01 |
| Wizzup | I could be that the power supply that I got with it is broken | 12:01 |
| buZz | afaik its just 12v DC? | 12:01 |
| Wizzup | could be, didn't investigate too much | 12:03 |
| dsc_ | i ported hamsterfiler from qt4 to qt5 | 12:45 |
| dsc_ | replaced qmake with cmake | 12:45 |
| dsc_ | https://i.imgur.com/AmEvE0p.png | 12:45 |
| Wizzup | cool! | 12:46 |
| Wizzup | maybe you can add it to extras https://github.com/maemo-leste-extras | 12:46 |
| dsc_ | oki | 12:46 |
| Wizzup | https://github.com/maemo-leste-extras/bugtracker | 12:46 |
| dsc_ | Wizzup: do you know if `hildon_mime_open_file(...);` is currently working? i.e: I try to open .txt but perhaps no mime handler yet | 12:50 |
| dsc_ | it uses dbus for that | 12:50 |
| dsc_ | any file extensions you know of that work in terms of mime handlers? | 12:51 |
| dsc_ | thumbnail generation seems to work :) https://i.imgur.com/B8c38fc.png | 12:56 |
| Wizzup | dsc_: no, is there a handler for it | 13:07 |
| Wizzup | uvos: do you have that glamor patch? | 13:07 |
| dsc_ | Wizzup: Do you know of a file extension that *does* have a mime handler? | 13:15 |
| dsc_ | for example I have Dorian installed, but clicking on `.pdf` files does not yield dorian | 13:16 |
| dsc_ | just making sure it is not hamsterfiler's fault | 13:17 |
| Wizzup | dsc_: pdf | 13:20 |
| Wizzup | should launch the pdf viewer | 13:21 |
| Wizzup | but I have not done much with mime | 13:21 |
| Wizzup | maybe ask freemangordon or uvos | 13:21 |
| uvos | Wizzup: cant look right now | 13:26 |
| uvos | Wizzup: dsc_: any and all maemo applications have broken mimes | 13:26 |
| uvos | install some desktop application | 13:26 |
| uvos | those work | 13:27 |
| uvos | so iirc on freemantle hildon-mime had a global mime database that it held iself and was only extensable via its own custom apis | 13:28 |
| uvos | while the xdg-mime system just uses the mime entries in .desktop files to generate a database | 13:28 |
| uvos | as hildon-mime is non functional anything that uses it is broken atm | 13:29 |
| dsc_ | ok | 13:29 |
| uvos | also we probubly want to rid ourselves of this so that desktop applications can launch maemo ones and vice versa | 13:29 |
| uvos | hildon mime shal then be just a compatibily wrapper that uses the xdg stuff behind the scenes | 13:30 |
| dsc_ | right | 13:30 |
| uvos | but yes this is totaly broken atm | 13:30 |
| dsc_ | so hamsterfiler uses this hildon-mime thing with dbus | 13:31 |
| dsc_ | like you said | 13:31 |
| dsc_ | I can port that to xdg | 13:31 |
| uvos | maybe just port to xdg | 13:31 |
| uvos | yeah | 13:31 |
| Wizzup | let's check with fmg | 13:31 |
| dsc_ | but uhh | 13:31 |
| Wizzup | not just remove it | 13:31 |
| dsc_ | for example where is `xdg-open` ? :P | 13:31 |
| dsc_ | or `xdg-mime` | 13:32 |
| uvos | freemangordon is usualy against changing anything api related - but please do add xdg support at least as an ifdef | 13:32 |
| uvos | that way hamsterfiler could be used on phosh etc too | 13:32 |
| dsc_ | nvm, I think I can just use Qt5's QMimeDatabase | 13:32 |
| uvos | right that also wraps xdg | 13:32 |
| dsc_ | ok :) | 13:32 |
| uvos | btw since we where launching the pdf viewer above | 13:39 |
| uvos | this is even more broken | 13:40 |
| uvos | since the pdf viewer dosent allow one to open a pdf via its commandline at all | 13:40 |
| uvos | you have to use the pdf viewers persistant dbus interface | 13:40 |
| uvos | meaning the pdf viewer is impossible to use in a proper mime | 13:40 |
| uvos | you can only use the pdf viewer to open a file by implenting its own custom interface | 13:41 |
| Wizzup | or it will just handle mime properly later on | 13:41 |
| uvos | hildon-mime dose this (and for lots of other applications too) | 13:41 |
| Wizzup | when it's ported to newer xpdf | 13:41 |
| Wizzup | I don't see the point of porting a hildon capable file manager and then stripping out the hildon parts :P | 13:41 |
| Wizzup | but maybe the mime stuff is super trivial, idk | 13:41 |
| dsc_ | uvos: previously ive solved this by having applications opening an unix socket and when a 2nd instance is spawned it can detect it is already running (and communicate a "file open" to the 1st instance) | 13:42 |
| dsc_ | dbus probably the better way to do that yeah | 13:43 |
| dsc_ | albeit dbus not available on windows, so using unix sockets in Qt5 is nice, because on Windows it uses named pipes | 13:43 |
| dsc_ | which keeps the application crossplatform | 13:43 |
| Wizzup | hildon has some of this solved already | 13:44 |
| Wizzup | probably that's why it has this mime stuff | 13:45 |
| Wizzup | we just need to make that work | 13:45 |
| dsc_ | ill hold on porting to xdg for now | 13:45 |
| Wizzup | yeah, better to make sure the hildon mime stuff works as well | 13:45 |
| dsc_ | unsure why hildon had to reinvent that wheel though | 13:46 |
| uvos | they reinvented most wheels | 13:47 |
| Wizzup | they invented them before it became a standard* ;-) | 13:49 |
| uvos | not in this case | 13:49 |
| uvos | anyhow | 13:49 |
| uvos | i just rememberd something | 13:50 |
| uvos | so hildon mime has these categorys xdg dosent have | 13:50 |
| uvos | and i seam to remember fmg implementing a heuristic to pars xdg mimes into the database | 13:50 |
| uvos | so acutally the hildon-mime xdg interop might be there allready | 13:50 |
| uvos | maybe try installin the thing | 13:50 |
| mighty17[m] | uvos: btw omapconf doesnt compile on android | 13:51 |
| uvos | or rather xdg has other categories | 13:51 |
| uvos | it has the same kind of categories but they are semanticly different | 13:52 |
| uvos | mighty17[m]: yes it dose :P | 13:52 |
| uvos | also not sure why you would want it on android | 13:52 |
| uvos | it works | 13:52 |
| uvos | but is mostly non functional because of missing defconfig flags | 13:53 |
| uvos | unless you go and compile your own debuging android kernel ofc | 13:53 |
| mighty17[m] | uvos: comparing registers | 13:54 |
| uvos | use rwmem | 13:54 |
| mighty17[m] | ah right | 13:54 |
| uvos | omapconf is way overkill | 13:54 |
| mighty17[m] | even rwmem does not | 13:54 |
| uvos | both of these compile fine for me | 13:54 |
| mighty17[m] | lemme try a clean build | 13:56 |
| mighty17[m] | my bad, uvos, it builds now, thanks! | 14:00 |
| mighty17[m] | time to check TIMER10's location | 14:01 |
| lel | sanderfoobar opened an issue: https://github.com/maemo-leste-extras/bugtracker/issues/26 ([REQ] HamsterFiler) | 14:28 |
| lel | parazyd created a repository: https://github.com/maemo-leste-extras/hamsterfiler | 15:13 |
| lel | parazyd closed an issue: https://github.com/maemo-leste-extras/bugtracker/issues/26 ([REQ] HamsterFiler) | 15:16 |
| lel | parazyd created a repository: https://github.com/maemo-leste-extras/oricutron | 15:16 |
| lel | parazyd closed an issue: https://github.com/maemo-leste-extras/bugtracker/issues/24 ([REQ] oricutron) | 15:17 |
| lel | parazyd created a repository: https://github.com/maemo-leste-extras/lagrange | 15:18 |
| lel | parazyd closed an issue: https://github.com/maemo-leste-extras/bugtracker/issues/23 ([REQ] lagrange) | 15:18 |
| lel | sanderfoobar opened an issue: https://github.com/maemo-leste-extras/hamsterfiler/issues/1 ((possibly) port to XDG) | 15:44 |
| Wizzup | uvos: btw my droid3 upower reports like 400mAh for the battery, even with a new polarcell, I guess I need to check out the calibration? | 15:59 |
| Wizzup | freemangordon: uvos: ok kernel in -experimental should be OK again | 16:01 |
| uvos | Wizzup: what dose it report for current_now? | 16:11 |
| uvos | or avg | 16:11 |
| uvos | is that sane? | 16:11 |
| Wizzup | the pm script reports sane things I think | 16:12 |
| Wizzup | let me check | 16:12 |
| Wizzup | d=2021-12-09|t=16:13:20|i=OFF:0,RET:4766|p=149|c=NA|b=none | 16:14 |
| Wizzup | looks sane to me | 16:14 |
| uvos | check if data_get_avg_curr_ua is different in solana kernel maybe | 16:15 |
| uvos | sometimes the callibration also gos haywire and reports low way to early | 16:15 |
| Wizzup | this is a bionic sd card that I transferred | 16:15 |
| Wizzup | so maybe I should nuke any calibration data | 16:15 |
| uvos | no | 16:15 |
| uvos | that cant cause it | 16:15 |
| uvos | charge the device take a note of charge_counter | 16:16 |
| uvos | discarge it untill the battery voltage is 3.5 v or so | 16:16 |
| uvos | the diff charge_counter should be the capacity -15% or so | 16:16 |
| uvos | if that checks out and current is correct and you cant find a difference in above funciton | 16:17 |
| uvos | i dont see how it could be wrong and the battery is just bad | 16:17 |
| Wizzup | it's a brand new polarcell | 16:18 |
| Wizzup | and it lasts over a day on it using about 150mW | 16:18 |
| Wizzup | so I don't think it can be only 400mAh | 16:19 |
| uvos | dmesg | grep cpcap_battery cpcap_battery.0: calibration done:? | 16:21 |
| uvos | maybe also check 0x0a1c with cpcaprw in android | 16:24 |
| uvos | should be about the same value as in dmesg | 16:24 |
| uvos | but really | 16:24 |
| uvos | i dont see how this could be different on d3, iirc the columb counter procedure is in the common cpcap code thats used on all devices | 16:25 |
| Wizzup | [ 11.060516] cpcap_battery cpcap_battery.0: Coulomb counter calibration done | 16:34 |
| Wizzup | [ 11.368774] cpcap_battery cpcap_battery.0: calibration done: 0x0000 | 16:34 |
| uvos | ok | 16:40 |
| uvos | yeah that cant be right | 16:40 |
| uvos | hmm | 16:40 |
| Wizzup | it's not a big deal atm | 16:41 |
| Wizzup | just something I noticed | 16:41 |
| uvos | maybe check the value in android | 16:42 |
| uvos | speculating here, motorola dosent appear to use the counter at all - they use a mutch more complex setup where they have discarge curves for eatch battery | 16:43 |
| uvos | maybe this is because on early cpcap revisions the counter was broken | 16:43 |
| bencoh | many fuelgauge don't rely on the coulomb counter only - some don't use it at all, even in modern implementations | 16:44 |
| uvos | ok | 16:45 |
| uvos | maybe they just dident feal like using it what do i know | 16:45 |
| bencoh | (in my opinion it's kinda broken, but for some of their parts, Samsung insists on saying they rely on voltage only) | 16:45 |
| bencoh | -s | 16:45 |
| Wizzup | so 5.8 does still hit off but it hangs very quickly when panel is probed | 21:12 |
| Wizzup | same for 5.8.y (stable), it's not particularly useful for debugging where the off mode regression happened between 5.7 and 5.9 | 21:15 |
| Wizzup | ok, with a specific method I can still hit ~42mW (same as 5.7) | 21:17 |
| sicelo | this is without any modules load? (42mW) | 21:19 |
| Wizzup | yes | 21:19 |
| Wizzup | so whatever caused off mode to never be hit was introduced between 5.8 and 5.9 I think | 21:20 |
| sicelo | you couldn't hit OFF with anything >5.9 ? | 21:21 |
| Wizzup | right, not without changing parts of the kernel | 21:21 |
| Wizzup | I am going to try 5.9.y again just to verify | 21:21 |
| Wizzup | I am keeping a log here mostly https://github.com/maemo-leste/bugtracker/issues/545 | 21:21 |
| Wizzup | probably best to start at bottom and read up | 21:21 |
| Wizzup | I could really use some help if you have spare cycles btw | 21:22 |
| sicelo | not yet :-( | 21:23 |
| sicelo | in a week or two i might finally begin to have some time | 21:24 |
| Wizzup | in any case the off mode idling is not stable in 5.8 (seems serial related) | 21:25 |
| Wizzup | but that is a separate problem | 21:25 |
| Wizzup | tmlind: right so I can confirm the OFF mode no longer being hit is introduced between 5.8 and 5.9 | 21:29 |
| uvos | since off mode not being hit on 5.9+ is simply because sched is to buisy to find the time, maybe whatever is increasing the events also caused the slight power increase d4 has seen since about 5.8 too | 21:33 |
| Wizzup | could be, let's see if I can find it | 21:33 |
| Wizzup | there's a bunch of clock rework in git log v5.8..v5.9 | 21:34 |
| Wizzup | or rather I looked at git log v5.8..v5.9 arch/arm/mach-omap* | 21:34 |
| uvos | that might not be wide enough something could have very well changed in the scheduler | 21:35 |
| Wizzup | I will do a bisect, so that won't matter | 21:35 |
| uvos | oh i thought you ment you only want to biscect arch/arm/match-omap | 21:36 |
| Wizzup | nah just looking at the log | 21:36 |
| uvos | thats an option | 21:36 |
| uvos | ok | 21:36 |
| Wizzup | unfortunately on plain v5.9 my idle script doesn't work | 21:38 |
| Wizzup | the one that just reads the pm data | 21:38 |
| Wizzup | (from debugfs) | 21:38 |
| Wizzup | it just hangs | 21:38 |
| Wizzup | :( | 21:38 |
| uvos | just read the ret/off count by hand then | 21:38 |
| Wizzup | I bet that will hang too | 21:39 |
| Wizzup | but let's see | 21:39 |
| Wizzup | interesting, that works | 21:40 |
| Wizzup | grep ^core_pwrdm /sys/kernel/debug/pm_debug/count | cut -d',' -f2,3 | 21:40 |
| Wizzup | another thing that was nice with 5.8: it stayed in OFF/RET much longer | 21:42 |
| Wizzup | so the numbers are lower, but also the power usage was lower | 21:42 |
| Wizzup | RET increases much faster on v5.9 | 21:42 |
| Wizzup | I hope I won't have to come up with fixes for stuff, and rather just point out where it goes wrong :( | 21:43 |
| Wizzup | uvos: do you know if there are plans to make kernel idle again while having kernel console not detached? | 21:45 |
| Wizzup | I thought it was a temporary thing (i.e. while serial is being reworked) | 21:45 |
| Wizzup | not having kernel console while testing idle stuff is awkward | 21:46 |
| Wizzup | wow this one commit I was at before in the bisect (g47ec5303d73e) idles extremely well | 21:52 |
| Wizzup | it basically never leaves the OFF state until I interact with it | 21:53 |
| uvos | Wizzup: no idea | 22:03 |
| Wizzup | btw I reported 42mW but really it's 28mW or so | 22:04 |
| Wizzup | (there's the serial device using power) | 22:04 |
| uvos | dont worry you report all kinds of contradictory numbers :P | 22:04 |
| Wizzup | that's life | 22:04 |
| uvos | yeah :) | 22:04 |
| Wizzup | :p | 22:04 |
| Wizzup | did you the conversations with your sphone rtcom logger btw? | 22:04 |
| Wizzup | I wonder if it even picks it up | 22:05 |
| uvos | no | 22:05 |
| Wizzup | ok | 22:05 |
| uvos | sphone for sure dosent pick up any that converations creates | 22:05 |
| uvos | (it explicitly filters for just its own) | 22:05 |
| Wizzup | conversations doesn't add anything atm | 22:05 |
| uvos | ok | 22:05 |
| Wizzup | it just is a frontend to el-v1.db | 22:05 |
| uvos | ok yeah i havent looked at any of this stuff | 22:06 |
| Wizzup | ok | 22:06 |
| Wizzup | it's in -devel so it could be just ~3 mins of work | 22:06 |
| Wizzup | I'd appreciate it if check if it picks up on the sphone stuff | 22:06 |
| Wizzup | if you can check* | 22:06 |
| uvos | ok | 22:06 |
| uvos | yeah i can ofc | 22:06 |
| uvos | it dose indeed pick something up | 22:10 |
| uvos | but only one conversation thread (this one is compleat) that i created with sphone-commtest | 22:10 |
| uvos | the ones that are real ones that i have from ofono are missing | 22:11 |
| uvos | creating another one in comtest also works | 22:13 |
| uvos | wierd | 22:13 |
| uvos | all sphone events get saved by the same module ofc store-rtcom | 22:13 |
| Wizzup | hm | 22:14 |
| Wizzup | uvos: here's a question... | 22:24 |
| Wizzup | I am doing a git bisect and on one commit it's *hardly* ever hitting off mode, but it hit it once | 22:25 |
| Wizzup | but way less than before | 22:25 |
| Wizzup | I guess I'd mark that as bad, yeah? | 22:25 |
| uvos | yeah off mode is not broken the kernel is just to busy | 22:25 |
| uvos | so you would expect it to hit it occasionally | 22:25 |
| uvos | over long time scales | 22:25 |
| Wizzup | yeah so marking it as bad sounds fine | 22:26 |
| uvos | Wizzup: dsc_: the problem with conversations is it picks up event type 6 only | 22:36 |
| uvos | Wizzup: dsc_: event_type 13 goes unoticed | 22:36 |
| uvos | 6 is message 13 is sms | 22:36 |
| Wizzup | ah, what is 13, chat? | 22:37 |
| uvos | 13 is sms | 22:37 |
| uvos | 6 is chat message | 22:37 |
| Wizzup | ah | 22:37 |
| Wizzup | that's weird -- I see all my SMSes from my n900 | 22:37 |
| uvos | maybe i made a mistake sec | 22:37 |
| Wizzup | it uses rtcom, maybe rtcom filters based on service registered ids or something | 22:37 |
| uvos | or they dont use the sms prop | 22:38 |
| uvos | i dont know why its needed | 22:38 |
| * Wizzup hopes the off mode regression really is not something too hard | 22:38 | |
| Wizzup | it idles really nicely... | 22:38 |
| uvos | yeah sphone uses RTCOM_EL_SERVICE_SMS for ofono | 22:39 |
| uvos | this resolves to id 13 | 22:39 |
| uvos | https://github.com/maemo-leste/sphone/blob/e5ad31827650099a3cd85ea9a2400cb76633dae9/src/modules/store-rtcom.c#L74 | 22:40 |
| Wizzup | # grep ^core_pwrdm /sys/kernel/debug/pm_debug/count | cut -d',' -f2, | 22:44 |
| Wizzup | OFF:1,RET:507 | 22:44 |
| Wizzup | heh | 22:44 |
| Wizzup | I'll count that as bad | 22:44 |
| Wizzup | Bisecting: 1 revision left to test after this (roughly 1 step) | 23:38 |
| dreamer | hah. fingers crossed :) | 23:39 |
| Wizzup | uvos: tmlind: | 23:57 |
| Wizzup | $ git bisect bad | 23:57 |
| Wizzup | facdaa917c4d5a376d09d25865f5a863f906234a is the first bad commit | 23:57 |
| Wizzup | commit facdaa917c4d5a376d09d25865f5a863f906234a | 23:57 |
| Wizzup | Author: Nitin Gupta <nigupta@nvidia.com> | 23:57 |
| Wizzup | Date: Tue Aug 11 18:31:00 2020 -0700 | 23:57 |
| Wizzup | mm: proactive compaction | 23:57 |
| Wizzup | ^^ this causes off mode to never be hit | 23:57 |
| Wizzup | (or almost never) | 23:57 |
| uvos | yeah | 23:58 |
| uvos | that makes sense | 23:58 |
| uvos | we should just turn memory compaction off | 23:58 |
| uvos | To periodically check per-node score, we reuse per-node kcompactd threads, | 23:58 |
| uvos | which are woken up every 500 milliseconds to check the same. | 23:58 |
| uvos | this makes me think we should maybe look at the tuneing parameters forlinux kernels that are used on modern android phones | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
