| buZz | freemangordon: yeah not sure if make ALL locales is every really needed for anyone | 00:03 |
|---|---|---|
| freemangordon | those are not all, just what we support | 00:04 |
| freemangordon | and usually this is done in the builder, libc upgrades are rare | 00:04 |
| buZz | welp, its a lot :) | 00:05 |
| freemangordon | omg, it booted after the upgrade :) | 00:14 |
| freemangordon | sicelo: which kernel you were seeing usb issues with? | 00:23 |
| freemangordon | on n900 | 00:23 |
| sicelo | 5.19 onwards | 07:33 |
| freemangordon | ah | 07:51 |
| freemangordon | but, don;t we have bigger issue there, like, pvr driver cannot be compiled | 07:52 |
| sicelo | i didn't test pvr :-) | 08:38 |
| sicelo | mmm, but i think migg | 08:40 |
| sicelo | i think mighty17[m] has pvr working on 5.19 | 08:41 |
| freemangordon | chromium is next to unusable on n900 :( | 08:48 |
| freemangordon | also, I was thinking we are hitting off mode there, but I see average power usage ~450 mW in idle, do I miss something? | 08:48 |
| sicelo | we don't hit off mode at all on n900 | 09:00 |
| sicelo | needs investigation. | 09:00 |
| freemangordon | mhm | 09:06 |
| freemangordon | lemme build omapconf there | 09:06 |
| sicelo | won't work :-( | 09:07 |
| sicelo | omapconf is for omap4 | 09:07 |
| freemangordon | omapconf? | 09:07 |
| freemangordon | ah | 09:07 |
| freemangordon | what is am335x | 09:07 |
| freemangordon | isn't that omap3? | 09:08 |
| sicelo | you can check with Wizzup ,but in general it seems using serial is better/easier way to track down off mode issues | 09:08 |
| freemangordon | I dont; have one :) | 09:08 |
| sicelo | yes am335x is omap3 iirc | 09:08 |
| freemangordon | so, omap3 should be support | 09:09 |
| freemangordon | maybe a matter of make flags | 09:09 |
| * freemangordon checks | 09:09 | |
| sicelo | OMAPCONF CURRENTLY SUPPORTS TI OMAP44XX AND OMAP54XX DEVICES. LEGACY TI OMAP PLATFORMS (OMAP[1-2-3]) ARE NOT SUPPORTED. | 09:10 |
| sicelo | from the readme | 09:10 |
| freemangordon | ok, but code says different thing | 09:12 |
| sicelo | oh ... let's hope it runs then :-) | 09:13 |
| freemangordon | hmm, debugfs is not mounted on n900 | 09:15 |
| freemangordon | sicelo: actually sgx is the only one hitting OFF | 09:16 |
| freemangordon | :) | 09:16 |
| sicelo | you already got omapconf on it? | 09:17 |
| freemangordon | no | 09:17 |
| freemangordon | /sys/kernel/debug/pm_debug/count | 09:18 |
| sicelo | right | 09:18 |
| freemangordon | hmm, usbhost_ick is on | 09:20 |
| freemangordon | sicelo: could you pastebin again the usb issue you have? or, it just does not work? | 09:28 |
| sicelo | I don't have device/laptop handy right now, but let me check if there's somewhere i can still find at least part of it | 09:36 |
| sicelo | i don't have it. sorry | 09:38 |
| freemangordon | yep, omapconf refuses to work | 09:41 |
| uvos | there is a rebased pvr driver on kernel 6.0 in the sgx repo | 10:21 |
| uvos | so should compile | 10:21 |
| uvos | am335x is a omap4 with cortex a8, but otherwise more like an omap4 irrc | 10:23 |
| freemangordon | but I am not sure it works, at least by looking at the ML | 10:23 |
| freemangordon | yeah, omapconf does not work | 10:23 |
| uvos | sure if it works is a different question ;) | 10:24 |
| freemangordon | I have looked at the patches sent over the ML and I am not convinced those are the right ones | 10:25 |
| freemangordon | but will look at it when it comes to it | 10:25 |
| uvos | yeah hitting off mode on n900 is only possible with nothing runnning and lots of kernel modules removed | 10:27 |
| uvos | Wizzup has details, he messed with this alot | 10:27 |
| freemangordon | yep, will wait for him to comment | 10:29 |
| freemangordon | uvos: hmm, sphone is using 32104 MB RES memory, on n900 | 10:43 |
| freemangordon | this is the second largest user after hildon-desktop | 10:43 |
| uvos | res is not terribly useful mesurement, since it fails to acount for shm | 10:49 |
| freemangordon | hmm, h-d uses 34MB, on fremantle it use less than 10MB | 10:49 |
| uvos | try with https://github.com/pixelb/ps_mem | 10:49 |
| uvos | anyhow i would expect sphone to be a very hungy user, relatively speaking | 10:49 |
| freemangordon | why? | 10:49 |
| uvos | it keeps manny of its gtk windows in ram at all times | 10:50 |
| freemangordon | oh | 10:50 |
| uvos | im not sure its really nessecary, but the original author did this for responsiveniss on a new call etc | 10:50 |
| uvos | i gues the htc whatever it was was fairly slow spawning new windows | 10:51 |
| uvos | i have seperated all the ui code out from the backend code with the intention of slowly replaceing the windows one by one with qt alternatives, so theres that | 10:52 |
| freemangordon | 7.4 MiB + 2.9 MiB = 10.4 MiBsphone | 10:52 |
| uvos | i mean its not nothing | 10:52 |
| uvos | but its okayish i think | 10:52 |
| freemangordon | 61.9 MiB + 18.6 MiB = 80.5 MiBmaemo-launcher (9) | 10:52 |
| freemangordon | :D | 10:52 |
| uvos | yes i mesured this expieramentaly before | 10:53 |
| freemangordon | I think you must make sphone .launcher in that case | 10:53 |
| freemangordon | it will free at least 9 MB | 10:53 |
| uvos | not really | 10:53 |
| uvos | i mesured launcher reduceing ram by a couple of 100 kb | 10:54 |
| uvos | over all processies | 10:54 |
| uvos | (it moves ram usage around) | 10:54 |
| freemangordon | yes, really, see https://pastebin.com/CHG8PJm4 | 10:54 |
| uvos | im not sure what your trying to show me with that | 10:55 |
| uvos | i know it changes accounting | 10:55 |
| freemangordon | the sum of all .launcher processes RAM usage is 80 MB | 10:56 |
| freemangordon | sphone alone uses 10 | 10:57 |
| uvos | because the other processies dont have lots of pixmaps to thair name | 10:57 |
| freemangordon | if you move it as a launcher, I bet it will free at least 5MB | 10:57 |
| freemangordon | pixmaps are shared | 10:57 |
| freemangordon | in sapwood | 10:57 |
| freemangordon | also, if you run as .launcher, you share pixmaps with other .launcher processes | 10:58 |
| uvos | still distorying windows in sphone reduces ram by a lot | 10:58 |
| uvos | the other processies besides h-d dont have any at that point | 10:58 |
| freemangordon | and this is valid for all theme pixmaps | 10:58 |
| uvos | i messured this with xterm before | 10:58 |
| uvos | total ram usage is almost unchanged with .launcher xterm vs normal xterm | 10:58 |
| freemangordon | ok, lemme open xterm to see how it affects the usage | 10:58 |
| freemangordon | with 5 xterm windows, usage increased from 213.5 MiB to 219.4 MiB | 11:00 |
| freemangordon | lemme run it through maemo-summoner | 11:01 |
| uvos | maemo-summoner is worse | 11:02 |
| freemangordon | 221.2 MiB | 11:02 |
| uvos | than just execing the binary | 11:02 |
| freemangordon | how's that? | 11:02 |
| uvos | idk | 11:02 |
| uvos | but that was the case | 11:02 |
| uvos | (back wen the binary could be execed) | 11:02 |
| freemangordon | you cannot just execute the binary | 11:02 |
| uvos | pre glibc changes | 11:02 |
| freemangordon | ah | 11:02 |
| freemangordon | well, now this is the result ^^^ | 11:03 |
| freemangordon | I don;t see why maemo-summoner will make a difference | 11:03 |
| uvos | as i say some kb per process | 11:03 |
| freemangordon | no | 11:03 |
| freemangordon | lemme repeat for one xterm | 11:03 |
| uvos | it also dosent change btw | 11:03 |
| uvos | so a small application benefits most | 11:04 |
| uvos | percentage wise | 11:04 |
| freemangordon | no xterm -> 215.2 MiB | 11:04 |
| freemangordon | 1 xterm -> 219.0 MiB | 11:04 |
| uvos | yes si | 11:05 |
| uvos | there is allways only one xterm | 11:05 |
| freemangordon | summoner - 219.6 MiB | 11:06 |
| uvos | so the first one using the most is unsuprising | 11:06 |
| freemangordon | sure | 11:06 |
| freemangordon | about 600 KB diff for xterm | 11:06 |
| freemangordon | lemme check for addressbook | 11:06 |
| uvos | its allways around that yeah | 11:07 |
| freemangordon | ok, but for 10 applications this is 6MB | 11:07 |
| uvos | sure | 11:08 |
| uvos | usefullt on n900 | 11:08 |
| freemangordon | mhm | 11:08 |
| uvos | on more moden devices not so mutch | 11:08 |
| freemangordon | right | 11:08 |
| freemangordon | also, we don;t .launch qt symbols | 11:08 |
| freemangordon | if we do, qt apps will benefit a lot | 11:08 |
| uvos | i doubt | 11:08 |
| uvos | same story with launch speed to btw | 11:09 |
| uvos | almost no difference on d4 | 11:09 |
| freemangordon | why, remember, this is c++ where symbol resolution takes ages | 11:09 |
| uvos | except launcher means that libs are allready loaded | 11:09 |
| uvos | (ie warm starts are the same) | 11:09 |
| freemangordon | esp for a huge lib like qt this differs a lot | 11:09 |
| uvos | im not conviced a launcher module for qt can work | 11:10 |
| uvos | without being a mess since qt changes alot with eatch release | 11:10 |
| freemangordon | will see, when and if it comes to it | 11:10 |
| uvos | anyhow if you want to reduce sphones ram use | 11:10 |
| uvos | its more usefull to make it release its resources | 11:11 |
| freemangordon | sure, but the point it that .launch savings come for free | 11:11 |
| freemangordon | *is | 11:11 |
| uvos | not really | 11:11 |
| freemangordon | how so? | 11:11 |
| uvos | since it needs to sill work without launcher its just buildsystem work vs code work | 11:12 |
| uvos | and the code work benefits both | 11:12 |
| freemangordon | buildsystem work is just adding dh_launcher to reules file | 11:12 |
| sicelo | freemangordon you wanted to perhaps fix the usb problem for n900? | 11:12 |
| freemangordon | sicelo: well, at least to try to identigy it | 11:12 |
| freemangordon | uvos: and maybe exporting a symbol through .defs file | 11:13 |
| freemangordon | while reworking resource usage is lot more work I assume | 11:13 |
| sicelo | I'll see if can build kernel and share | 11:13 |
| freemangordon | ok | 11:13 |
| freemangordon | no hurry | 11:13 |
| sicelo | :-) | 11:14 |
| freemangordon | uvos: re https://github.com/maemo-leste/libhildon/pull/9 | 11:14 |
| freemangordon | what is that workflow thingie? | 11:15 |
| sicelo | I'm in a hurry, lol, before qt takes away your cpu cycles 😁 | 11:15 |
| freemangordon | "1 workflow awaiting approval"? | 11:15 |
| freemangordon | sicelo: I don;t plan qt soon | 11:15 |
| freemangordon | next is compositing accell in omap pvr xorg driver, most-probably | 11:15 |
| uvos | freemangordon: i try and make sphones module load order not matter | 11:16 |
| freemangordon | no, I understand why the pr | 11:16 |
| uvos | freemangordon: some modules require libhildon | 11:16 |
| freemangordon | wait | 11:16 |
| uvos | to not violate the ordering guarntee | 11:16 |
| uvos | i just init libhildon in eatch module that requires it | 11:16 |
| uvos | and then it throws warnings | 11:16 |
| freemangordon | github wants me to approve some "workflow" | 11:16 |
| uvos | i dont think the warnings are critical | 11:16 |
| freemangordon | agree | 11:16 |
| freemangordon | and I am to merge it | 11:17 |
| uvos | idk about the workflow thing | 11:17 |
| uvos | never seen it before | 11:17 |
| freemangordon | what I wont to know is if you requested that "workflow" | 11:17 |
| freemangordon | ok | 11:17 |
| freemangordon | oh, it seems we have automatic tests | 11:18 |
| uvos | thats news to me | 11:20 |
| freemangordon | only libhildon seems to have it | 11:20 |
| freemangordon | I remember we try to keep it compatible with upstream gtk | 11:20 |
| freemangordon | uvos: so, in theory you should be able to run sphone with libhildon outside maemo | 11:21 |
| freemangordon | as long as you don;t use maemo-specific stuff | 11:21 |
| uvos | why would i need to? | 11:21 |
| freemangordon | need? | 11:21 |
| uvos | sphone just ifdefs libhildon stuff | 11:21 |
| freemangordon | no need, only if you want | 11:21 |
| uvos | that works fine for me | 11:21 |
| uvos | ok | 11:21 |
| uvos | also as i say | 11:22 |
| uvos | i want to (and have prepared all the backend logic) to move sphone to qt one window at a time | 11:22 |
| uvos | so then libhildon becomes less relevant anyhow | 11:23 |
| uvos | with time | 11:23 |
| freemangordon | tmlind: I tested with that patch reverted on n900, I see no issues | 11:23 |
| freemangordon | sicelo: and once we have that, most-probably I will try to implement TE support in omapdss and then VRFB | 11:25 |
| sicelo | I'll be really happy (vrfb) | 11:27 |
| sicelo | i know/accept that n900 has really reached end of usefulness, but any little improvements/maintenance makes a welcome difference:-) | 11:29 |
| freemangordon | well, rotation will not add much to the usefullness | 11:32 |
| freemangordon | that's why it is with so low prio for me | 11:33 |
| freemangordon | oh, wait, I was about to fix connui-cellular :( | 11:34 |
| uvos | on larger devices it dose add a lot of usefullness imo | 11:35 |
| uvos | using d4 one handed in landscape is akward | 11:35 |
| uvos | but on n900 yeah | 11:35 |
| uvos | its small enough | 11:35 |
| freemangordon | well, it is useful in lots of cases | 11:35 |
| freemangordon | call-ui, book reading, etc | 11:36 |
| uvos | sure, but i think its more amplified the bigger the device gets | 11:36 |
| freemangordon | :nod: | 11:36 |
| freemangordon | oh, I really want pvr stuff first, that's what I will do :) | 11:37 |
| * mighty17[m] > <@sicelo:libera.chat> i think mighty17 has pvr working on 5.19 | 11:51 | |
| * mighty17[m] doesnt remember working on 5.19 | 11:51 | |
| mighty17[m] | I'll give it a go tho | 11:51 |
| freemangordon | uvos: were you able to gather some ofono issues log? | 11:58 |
| Wizzup | freemangordon: we hit off mode on n900 with certain drivers removed | 11:58 |
| Wizzup | freemangordon: we also jhave some tools to debug this | 11:59 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/545 | 11:59 |
| freemangordon | I tried your script, but it does not work | 11:59 |
| freemangordon | maybe a kernel patch is missing | 11:59 |
| Wizzup | https://github.com/maemo-leste/n900-pm/blob/master/scripts/openrc/n900-pm#L152 | 12:00 |
| Wizzup | this script? | 12:00 |
| freemangordon | yes | 12:00 |
| freemangordon | File "<stdin>", line 14, in <module> | 12:00 |
| freemangordon | IndexError: list index out of range | 12:00 |
| freemangordon | d=2022-10-01|t=11:16:03|i=OFF:0,RET:0|p=0|c=NA|b=none | 12:00 |
| Wizzup | freemangordon: with our kernel? | 12:00 |
| freemangordon | yes | 12:00 |
| Wizzup | hmmmm I wonder if uvos forgot the patch them | 12:00 |
| Wizzup | I don't test this specific feature every release of course | 12:01 |
| Wizzup | debugfs is mounted? | 12:01 |
| freemangordon | there is no idlest1 in /sys/kernel/debug/pm_debug/count | 12:02 |
| freemangordon | yes it is | 12:02 |
| freemangordon | though I wonder why it is not mounted by default | 12:02 |
| freemangordon | so I have to mount it by hand | 12:02 |
| Wizzup | well, debugfs is a security risk in some arguable cases | 12:02 |
| freemangordon | well, I think we are far from security concerns | 12:02 |
| freemangordon | esp on n900 | 12:02 |
| freemangordon | it is automounted on d4 | 12:03 |
| uvos | nopasswd sudo :P | 12:03 |
| uvos | freemangordon: ni | 12:03 |
| Wizzup | so I am not sure what the exact patch name was | 12:03 |
| uvos | freemangordon: no but will this weekend/monday | 12:03 |
| freemangordon | ok | 12:03 |
| uvos | Wizzup: what did i forget? | 12:03 |
| Wizzup | the n900 patch that exports ret/off blocker info | 12:03 |
| freemangordon | Wizzup: maybe this will help https://lists.goldelico.com/pipermail/letux-kernel/2019-December/004509.html | 12:04 |
| uvos | possible | 12:04 |
| freemangordon | Wizzup: if you have older tree, just git log arch/arm/mach-omap2/pm-debug.c | 12:04 |
| Wizzup | freemangordon: we had the patch in | 12:05 |
| Wizzup | freemangordon: yes it's that patch but I had forward ported it | 12:05 |
| Wizzup | it's a bit silly we keep losing stuff | 12:05 |
| uvos | i think a problem is | 12:06 |
| uvos | that several different people commit stuff to the kernel | 12:06 |
| uvos | as in patches | 12:06 |
| uvos | so it gets very dissorganized all th etime | 12:06 |
| Wizzup | as long as we don't merge in braches but rebase it should be ok | 12:07 |
| uvos | with what is sill required what made it upstream and so on | 12:07 |
| Wizzup | because then all our commits are on top | 12:07 |
| uvos | dosent really help | 12:07 |
| uvos | becuase you have to restart with linux-next really | 12:07 |
| freemangordon | Wizzup: ok, what's the patch sha id? | 12:07 |
| Wizzup | freemangordon: I am trying to find it for 10 minutes | 12:07 |
| freemangordon | "Wizzup: if you have older tree, just git log arch/arm/mach-omap2/pm-debug.c" | 12:08 |
| Wizzup | sec | 12:08 |
| freemangordon | and you'll see it | 12:08 |
| Wizzup | yeah waking up still | 12:08 |
| Wizzup | uvos: why @ restart? | 12:08 |
| Wizzup | freemangordon: you'll want 8917211408204f5de88cf0fec3e42f3c42c81570 | 12:08 |
| Wizzup | and also my revert of fb2c599f056640d289b2147fbe6d9eaee689f1b2 if you don't have it already | 12:08 |
| uvos | Wizzup: because you have to examine every patch to see if its sill needed | 12:08 |
| uvos | https://github.com/IMbackK/droid4-linux/commits/n900-516 | 12:08 |
| uvos | it should be here | 12:09 |
| uvos | i gues its not | 12:09 |
| uvos | so yes i forgot it | 12:09 |
| uvos | i makes the most sense to have feature branches like that | 12:09 |
| Wizzup | I found this commit in wip/n900/maemo-5.15-cleaned-up | 12:09 |
| freemangordon | well, I think it is because we merged to omap kernel | 12:09 |
| uvos | so that the patches are organized in a way that makes sense when it comes to figureing out which ones are still needed | 12:09 |
| freemangordon | and IMO it is normal some stuff was forgotten given the number of patches we carry | 12:10 |
| freemangordon | Wizzup: lemme check what fb2c599f056640d289b2147fbe6d9eaee689f1b2 is | 12:10 |
| Wizzup | it's the commit that automatically disabled off mode | 12:10 |
| Wizzup | this will cause all kinds of problems, during boot and at runtime (since off is not stable) | 12:10 |
| uvos | imo if we add stuff to feature branches first, it would make less stuff get forgontne | 12:10 |
| freemangordon | Wizzup: have we ever tested on 5.18? | 12:11 |
| freemangordon | to enable off mode during boot that is | 12:11 |
| freemangordon | Wizzup: we have it, 0396bd47a666fd16d14bb30dc3906c35f7d11383 | 12:13 |
| freemangordon | ok, so I'll pick 8917211408204f5de88cf0fec3e42f3c42c81570 and will rebuild the kernel | 12:14 |
| Wizzup | freemangordon: not sure @ 5.18, but in general off mode seemed to have quite a few problems, so when I'd hit it,power usage would be great, but eventually it would crash/hang | 12:17 |
| freemangordon | ugh, this adds stuff in debian | 12:17 |
| Wizzup | freemangordon: huh? | 12:17 |
| Wizzup | oh :/ | 12:17 |
| freemangordon | I'll fix it | 12:17 |
| Wizzup | ty | 12:17 |
| sicelo | regarding the pm patch, what would prevent upstreaming it btw? i don't remember if there was anything specific | 12:20 |
| freemangordon | no idea | 12:21 |
| Wizzup | it's just debug info, without any stable interface | 12:21 |
| Wizzup | I suppose it could be, probably up to tmlind | 12:21 |
| freemangordon | I wonder if this is going to work correctly on omap4 | 12:22 |
| freemangordon | Wizzup: a thing that is bugging me since long time ago - on d4, first wifi connection attempt always fails (when done by icd), any idea? | 12:35 |
| Wizzup | I think the connections sometimes fail because the wpa supplicant dbus ids for a specific network in a scan expire and wpa supplicant has a new id for the same network | 12:36 |
| Wizzup | but this is just my guess | 12:36 |
| freemangordon | this happens only the first time on boot | 12:36 |
| Wizzup | freemangordon: we already set the off mode bit on omap4 manually, so the auto patch doesn't do much there, but the kernel does not have code to enter off mode there, it enables us to get into RET | 12:36 |
| Wizzup | freemangordon: I also have it in other cases | 12:36 |
| freemangordon | no, I am talking about tmlind's patch | 12:37 |
| Wizzup | I don't think it works | 12:37 |
| freemangordon | that dump cm_idlest | 12:37 |
| freemangordon | yes, but could it result in oops | 12:37 |
| Wizzup | our d4 pm script already has a waty read | 12:37 |
| Wizzup | ah | 12:37 |
| freemangordon | d=2022-10-01|t=13:37:52|i=OFF:0,RET:0|p=508|c=NA|b=ST_SDRC,ST_SDMA,ST_OMAPCTRL,ST_UART2,ST_I2C1,ST_MCSPI4,ST_MMC1 | 12:38 |
| Wizzup | yeah so if you boot to n900 without h-d and most drivers loaded, we easily hit ret all the time, and even off | 12:39 |
| Wizzup | if you enable off mode we -sometimes- hit ret, iirc, but it's unstable already | 12:39 |
| Wizzup | we only hit it since I fixed up the ts driver to idle ok | 12:39 |
| Wizzup | (hit ret) | 12:39 |
| Wizzup | but typically there's many modules that block idle, even ret | 12:39 |
| Wizzup | how to best get at this list is what the long github issue is about, but I don't think I have a definitive list | 12:40 |
| Wizzup | some automated way of loaded modules one at a a time (with deps) and reporting on idle could be interesting | 12:40 |
| freemangordon | lets see what chron will report | 12:41 |
| freemangordon | *cron | 12:41 |
| freemangordon | anyway, I am not going to debug that now | 12:42 |
| freemangordon | I wonder how hard would be to write off mode code for d4 | 12:42 |
| freemangordon | it should be in the android kernel already | 12:42 |
| freemangordon | seems there is also a patch that was send pack then https://lore.kernel.org/all/1315144466-9395-15-git-send-email-santosh.shilimkar@ti.com/ | 12:46 |
| freemangordon | wait, this is in mainline | 12:49 |
| freemangordon | whay do we think OFF mode is not supported? | 12:49 |
| Wizzup | well, for the cpu yes, but not for the whole | 12:51 |
| Wizzup | which is what is necessarily afaiu | 12:51 |
| freemangordon | Wizzup: https://www.spinics.net/lists/linux-omap/msg71661.html | 13:02 |
| freemangordon | I wonder why it didn;t make it | 13:02 |
| freemangordon | Wizzup: for reference https://pastebin.com/HgiFwaV0 | 13:10 |
| Wizzup | freemangordon: hmm I see | 13:18 |
| freemangordon | ok, I still wonder why off mode series didn't make it upstream | 13:20 |
| freemangordon | there is only one note https://www.spinics.net/lists/arm-kernel/msg179301.html , which tero replied to and that's all | 13:20 |
| Wizzup | mhm, don't know | 13:21 |
| freemangordon | I think it might make sense to try to port | 13:21 |
| Wizzup | let's check with tony first | 13:23 |
| freemangordon | yeah, sure | 13:23 |
| Wizzup | but nice find :) | 13:28 |
| tmlind | i think it's mostly context save and restore that's missing, that should be under drivers/soc now | 17:22 |
| tmlind | i can try to do an experimental rebase to play with at some point when i have some spare time | 17:23 |
| sicelo | freemangordon: i found some pics i took of the dmesg errors related to the usb issue. i know images may aren't the easiest/best way to share error messages. will still send proper log later, but here goes: | 21:14 |
| sicelo | https://postimg.cc/Tytk5FzZ , https://postimg.cc/vcwvTG14 , https://postimg.cc/tsXtdDNy , https://postimg.cc/WqL0d71B , https://postimg.cc/tYDVbbFQ | 21:15 |
| Wizzup | tmlind: would be sweet | 21:44 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!