| freemangordon | hmm, it seems chromeos mesa pvr dri is newer version that the one in TI blobs | 07:00 |
|---|---|---|
| freemangordon | *than | 07:00 |
| Wizzup | parazyd: uvos: I am working on the news post now, do we plan to have charge-mode ready? | 10:26 |
| Wizzup | tmlind: uvos: I got a reset yesterday when playing music with mpv and having gps on, with ngsm debug on: https://wizzup.org/reset.txt | 10:40 |
| Wizzup | this is from pstore, but it doesn't seem to contain a whole lot | 10:41 |
| parazyd | Wizzup: I could try to make an upgrade that enables it sometime tomorrow. | 11:01 |
| parazyd | Wizzup: Do we have it on all devices now? | 11:01 |
| Wizzup | let's make it possible to test it first | 11:01 |
| tmlind | Wizzup: yeah no oops to see there unfortunately | 11:26 |
| Wizzup | tmlind: I am surprised not to see much more n_gsm debug there | 11:28 |
| Wizzup | maybe it stops writing to the pstore console after a while? | 11:28 |
| Wizzup | there should be a _lot_ more in there I think | 11:28 |
| uvos | Wizzup: from my end yes, for mapphones at least | 11:29 |
| uvos | for others we have the problem that we can only activate it for new installs | 11:30 |
| uvos | also someone needs to test it on pp | 11:31 |
| tmlind | Wizzup: yeah strange, maybe the buffer gets partially overwritten on boot or something | 11:35 |
| Wizzup | uvos: so maybe we just do it for mapphones? | 11:36 |
| uvos | no strong optinion | 11:37 |
| uvos | i suspect we want it on n900/pp too at some point | 11:38 |
| Wizzup | I think it would be a good idea, even to just move it along to more users | 11:38 |
| uvos | yeah sure no strong opininon. | 11:39 |
| uvos | one problem i forsee is that we cant role it out devel only on non mapphones afaik | 11:39 |
| uvos | for testing, since besides trying it twice on n900 i never tested it on something other than d4/bionic. | 11:40 |
| sicelo | You can possibly add it in device specific repo for now (mapphones?) then migrate later. | 11:42 |
| tmlind | i wonder.. can we just open /dev/dri/renderD128 directly somewhere in the mesa sources and bypass the blobs to fix the node name issue? | 11:42 |
| uvos | sure since mesa dlopens the blob you could shim open() to redirect stuff opend in /dev/dri/ | 11:44 |
| Wizzup | we could potentially also patch the blob to open a file that we create a symlink for | 11:45 |
| uvos | not sure why we need it to use the render node btw | 11:46 |
| tmlind | well i'm thinking about completely bypassing the blobs for open and close, not sure if the blobs need anything excecpt the fd | 11:46 |
| tmlind | uvos: the way things are moving, the render node is used for almost everything to avoid the permissions problem | 11:47 |
| tmlind | uvos: see kernel Documentation/gpu/drm-uapi.rst the paragraph that contains RENDER_NODE | 11:51 |
| tmlind | sorry i mean that contains DRIVER_RENDER | 11:52 |
| uvos | tmlind: i mean yeah thats why render nodes where introduced | 11:55 |
| uvos | but rendering without a drm master isent really what you do on a phone is it? is there some place client support for drm auth is being droped? | 11:55 |
| uvos | not that "updateing" the blobs is a bad thing | 11:55 |
| uvos | and yeah should be easy to do by shiming open() in pvr_dri.so | 11:55 |
| tmlind | well i'm thinking just implementing some of this directly in mesa, i see no point passing open and close via the blobs | 11:58 |
| uvos | sure | 11:58 |
| uvos | you could also re bits of the blobs and reimplement the functions in mesa dri_pvr | 11:58 |
| tmlind | heh i guess.. i just need open and close for wlroots i think | 12:00 |
| tmlind | i guess it's possible the blobs actually do something with the fd between open and close | 12:01 |
| Wizzup | uvos: btw the sms ui of sphone no longer closes when it sends | 12:17 |
| uvos | Wizzup: yeah i kow i fixed it + the other issue allready | 12:34 |
| uvos | https://github.com/maemo-leste/sphone/commit/12ab567c9fc65fa444aa6be80db3f19caf5cc7d4 | 12:34 |
| uvos | also note that without https://github.com/maemo-leste/sphone/commit/e19fb96bf6f0ef95b76811b349a748daa18933bb | 12:34 |
| uvos | sphone dosent give feedback (except in log) that an action could not be compleated by the selected comm backend | 12:35 |
| Wizzup | ok | 12:42 |
| freemangordon | why don;t we have ltrace on ARM?!? | 13:45 |
| Wizzup | seems debian doesn't have it | 13:46 |
| Wizzup | https://packages.debian.org/search?keywords=ltrace | 13:46 |
| freemangordon | yeah, that's why my question :) | 13:47 |
| Wizzup | stretch had it | 13:47 |
| freemangordon | hmm | 13:47 |
| freemangordon | lemme try to install | 13:47 |
| Wizzup | https://packages.debian.org/stretch/ltrace | 13:47 |
| freemangordon | yeah | 13:47 |
| uvos | oh neat dident know about ltrace | 13:48 |
| uvos | that sounds pretty usefull for debugging sphone/mce | 13:48 |
| Wizzup | I think gdb should work better for you potentially, but you could | 13:48 |
| Wizzup | I usually use lstrace when problems occur in libs I don't want to or can't change | 13:49 |
| Wizzup | ltrace* | 13:49 |
| uvos | sure i use gdb most of the time, but knowing what modules react to something should be easier this way | 13:49 |
| uvos | (dont have to break anywhere) | 13:49 |
| Wizzup | any objections to having osso-xterm just use the XDG browser env for opening urls? | 13:50 |
| Wizzup | we currently have the dbus call to browser ui stubbed | 13:50 |
| uvos | no | 13:50 |
| uvos | sounds very sane | 13:50 |
| uvos | or just xdg-open the url | 13:50 |
| uvos | that way it works with urls that shal not end in browser too | 13:51 |
| Wizzup | uvos: this, then? https://docs.gtk.org/gio/type_func.AppInfo.launch_default_for_uri.html | 14:52 |
| Wizzup | might make it async instead | 14:52 |
| uvos | sure yeah | 14:56 |
| uvos | that very likely uses xdg-mime and xdg-open to execute the right app | 14:57 |
| Wizzup | right | 14:57 |
| freemangordon | the fuck! running glmark through ltrace does not hang | 15:22 |
| Wizzup | heisenbugs | 15:22 |
| tmlind | freemangordon: does also glmark with -d option work just fine? i think i saw that earlier after switching to chromeos mesa, not that no longer works for me | 15:26 |
| freemangordon | what -d is for? | 15:26 |
| freemangordon | ah, debug | 15:27 |
| freemangordon | lemme try | 15:27 |
| freemangordon | it doesn;t, but it doesn't without -d as well | 15:28 |
| uvos | freemangordon: since its timeing related | 15:28 |
| uvos | maybe it will hang with ltrace if you change 0x4A008164 register | 15:29 |
| freemangordon | hmm? | 15:29 |
| freemangordon | what is this register? | 15:29 |
| uvos | sgx clock | 15:29 |
| freemangordon | ok, what value to write? | 15:29 |
| freemangordon | hmm, wait | 15:30 |
| freemangordon | I am not sure I will be able to | 15:30 |
| freemangordon | PM is enabled | 15:30 |
| uvos | works fine | 15:30 |
| freemangordon | ok | 15:30 |
| freemangordon | what value? | 15:30 |
| uvos | the clock is just disabled | 15:30 |
| uvos | sec im reading datasheet | 15:30 |
| uvos | so default should be 2a | 15:31 |
| uvos | d4 here | 15:31 |
| freemangordon | yeah, d4 | 15:31 |
| uvos | just increase the value | 15:32 |
| uvos | bits 0-4 are the devider ratio | 15:32 |
| uvos | (greping in irc.txt here | 15:35 |
| uvos | ) | 15:35 |
| uvos | looks like i used to use omapconf write 0x4A008164 0x1f to maximize the amount of artifacting on ddk1.19 | 15:36 |
| uvos | for testing | 15:36 |
| uvos | *ddk1.9 | 15:36 |
| uvos | freemangordon: yeah still works omapconf write 0x4A008164 0x1f makes it very artifact happy | 15:40 |
| freemangordon | uvos: seems to be a timing issue, there is absolutely no difference in calls between blob and chromeos when it comes to call to libpvr_dri_support.so | 16:02 |
| freemangordon | so I don't see how tweaking sgx regs could help | 16:02 |
| uvos | well any call that touches sgx will take longer | 16:03 |
| uvos | so if you slow down the cpu effectivly by adding a debuger the issue would reemerge if you slow sgx too, unless the problem is in omapdrm ofc | 16:04 |
| uvos | and the artifacting on ddk1.9 IS a timeing issue too | 16:05 |
| uvos | and is effected by sgx render time | 16:05 |
| Wizzup | would be nice if we can get tomi involved somehow I think | 16:12 |
| uvos | did anyone email him? | 16:17 |
| Wizzup | don't think we did | 16:17 |
| tmlind | uvos: ack, rwmem 0x4a008164=0x1f brings back a variant of my sway + termite not refreshing problem | 16:26 |
| freemangordon | tmlind: what is PVR_QUIRK_OMAP4 used for? | 16:27 |
| tmlind | freemangordon: nothing any longer, was used with ddk-1.17 for the ioctl proxying | 16:28 |
| tmlind | sorry i mean was used with ddk-1.9 for the ioctl proxying | 16:28 |
| freemangordon | but it is still enabled | 16:28 |
| freemangordon | shall I disable/remove it | 16:28 |
| tmlind | yeah i don't think there code is there any longer? | 16:28 |
| tmlind | yeah let's get rid of it | 16:28 |
| freemangordon | as I am going to test with ocp management disabled, on d4 | 16:29 |
| tmlind | ok great, sounds like we should not need it on omap4 and later | 16:29 |
| freemangordon | ok | 16:29 |
| tmlind | it might be that we only need it for 36xx | 16:29 |
| freemangordon | and it might be the reason for the hangs | 16:32 |
| freemangordon | the same way it was on 3430 | 16:32 |
| freemangordon | but, lets see | 16:32 |
| tmlind | ok good to check for sure | 16:37 |
| freemangordon | kmscube still works, glmark2 still hangs :D | 16:38 |
| lel | MerlijnWajer closed an issue: https://github.com/maemo-leste/bugtracker/issues/385 (droid4: osso-xterm doesn't change font size on volume buttons) | 16:40 |
| freemangordon | but, "use-vbo=false" FPS Is 2, so ocp control is needed for sure | 16:41 |
| freemangordon | ok, it still hangs with pvr module debug messages enabled | 16:44 |
| freemangordon | hmm, seem NULL pointer is being send to SGX | 17:41 |
| tmlind | freemangordon: ok so ocp still needed at least on omap4 sounds like | 17:54 |
| freemangordon | yeah | 18:12 |
| freemangordon | tmlind: any idea what is this "PDE valid: PTE = 0x00000000 (PhysAddr = 0x00000000, Invalid)" supposed to mean? | 18:35 |
| freemangordon | in short - when running glmark with chromeos pvr, there seems to be a pagefault triggered by SGX | 18:36 |
| freemangordon | it finds MMU context (Found MMU context for page fault 0x0dc08000), which is (GPU memory context is for PID=3025 (glmark2-es2-drm)) | 18:37 |
| freemangordon | does this mean that the page is mmaped to cpu and SGX cannot access it? | 18:37 |
| uvos | freemangordon: dose abook have api documentation somewhere, at least for the old pre RE version. | 18:40 |
| uvos | ah found http://maemo.org/api_refs/5.0/beta/libosso-abook/OssoABookRoster.html | 18:42 |
| freemangordon | :nod: | 18:51 |
| freemangordon | uvos: hmm, there is 'final' not 'beta' version too | 19:03 |
| uvos | so is abook is finised enough for me to wirte an sphone pluginn that uses it? | 19:04 |
| freemangordon | no | 19:04 |
| uvos | ok | 19:04 |
| uvos | freemangordon: would only need OssoABookContactChooser to work at first most likely | 19:04 |
| tmlind | freemangordon: heh that looks like a fancy way of saying null pointer exception | 19:05 |
| uvos | tmlind: am i reading that correctly some non null address in (invalid) page table entry maps to 0x0? | 19:11 |
| tmlind | probably everything is zero, maybe after memset or something like that? | 19:14 |
| tmlind | maybe the dropped mutex freemangordon noticed? | 19:15 |
| tmlind | or rather additional mutex in the blobs? | 19:15 |
| uvos | yeah thats the question the mutex might be guarding against something else causing the memory region to be swaped to some other space in mmu | 19:16 |
| uvos | (for the cpu to mess with it) | 19:16 |
| uvos | ofc that makes no sense if everything is 0 | 19:17 |
| freemangordon | but, that mutex makes sense in case of MT | 19:23 |
| freemangordon | I don't see MT in glmark | 19:23 |
| freemangordon | also, if something is being memset to zero, it shouldn't make any difference if I run through ltrace/valgrind or not, it should fail despit | 19:27 |
| freemangordon | but it does not | 19:27 |
| uvos | freemangordon: right | 19:28 |
| freemangordon | I mean - it never fails if it is run through valgrind or ltrace | 19:28 |
| freemangordon | with chromeos blob that is | 19:28 |
| uvos | freemangordon: so random scenario: sgx renders something, there is a fence missing in drm | 19:28 |
| freemangordon | I think rendering hasn't started yet | 19:29 |
| uvos | omapdrm grabs the buffer for dss, by adjusting mmu depending on timeing we get a half renderd frame with stuff missing, also depending on timeing sgx ends up rendering to a buffer thats unmaped | 19:29 |
| freemangordon | I have pvr driver debug traces | 19:29 |
| freemangordon | uvos: wait, I think we have 2 MMUs involved here | 19:30 |
| freemangordon | at least SGX has its own MMU | 19:30 |
| freemangordon | but, it is not controlled by omapdss driver, afaik | 19:30 |
| uvos | ok yeah | 19:31 |
| uvos | i have no idea about exact intenrals | 19:31 |
| freemangordon | me neither | 19:31 |
| freemangordon | :( | 19:31 |
| uvos | but the above description would in pricinal have the abillity to cause all issues | 19:31 |
| uvos | ie missing bits of frame and the exception | 19:31 |
| freemangordon | but, we may again hit some coherency issue | 19:31 |
| uvos | right missing drm fence | 19:31 |
| freemangordon | hmm, we still not render | 19:32 |
| freemangordon | it faults while stuff is still being prepared | 19:33 |
| uvos | before the first frame? | 19:33 |
| freemangordon | yes | 19:34 |
| uvos | hmm ok | 19:34 |
| freemangordon | i compared pvr traces with and without fault, nothing obviously wrong | 19:35 |
| uvos | could it be an interaction with a different drm client? like omapdrmfb? | 19:36 |
| freemangordon | gpu on d4 is single-core, right? | 19:37 |
| uvos | i think so dual core was added in -70 no? | 19:37 |
| freemangordon | no idea | 19:37 |
| freemangordon | but, just pulled latest driver from chromeos | 19:37 |
| freemangordon | building mesa ATM | 19:38 |
| freemangordon | not that I hope it will work :) | 19:38 |
| freemangordon | doesn;t seem like userspace issue to me | 19:38 |
| uvos | only omap5 is MP2 variant of sgx540 it seams | 19:38 |
| freemangordon | ok | 19:38 |
| uvos | freemangordon: hmm so where is chomeos kernel with pvr source | 20:15 |
| freemangordon | dunno, but why? | 20:16 |
| uvos | maybe they carry some commit like: fix null pointers in pvr driver | 20:17 |
| freemangordon | :) | 20:22 |
| freemangordon | yeah, right | 20:22 |
| freemangordon | https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-kernel/ ? | 20:23 |
| freemangordon | hmm, I think I am on something | 20:24 |
| freemangordon | in blobs, PVRDRIClientWaitSyncEXT does not call PVRDRIEGLFlushBuffers | 20:25 |
| freemangordon | in chromeos driver it does | 20:26 |
| freemangordon | 'upstream' chromeos driver does not flush too | 20:31 |
| freemangordon | aaah, mesa takes ages to build :( | 20:37 |
| freemangordon | tmlind: would you like to try a little change in mesa? | 20:48 |
| freemangordon | as my local build will take maybe 2 more hours and I am impatient :) | 20:49 |
| tmlind | freemangordon: sure if it does not force a rebuild and i don't fall asleep before done :) | 21:32 |
| freemangordon | it will rebuild only pvr_dri | 21:38 |
| tmlind | comment out PVRDRIEGLFlushBuffers? | 21:38 |
| freemangordon | not that simple, lemme provide a patch | 21:39 |
| tmlind | ok | 21:39 |
| freemangordon | tmlind: https://pastebin.com/CzYV1pxi | 21:40 |
| freemangordon | not even compile-tested, but you should get the idea | 21:40 |
| freemangordon | if you apply and run ninja from build directory, in theory only pvr_dri should be rebuid | 21:41 |
| tmlind | ok building now, had to manually apply as tabs got hosed | 21:49 |
| freemangordon | oh, sorry about that | 21:51 |
| tmlind | np, so i try to run glmark2-es2-wayland and see if oopses? | 21:53 |
| freemangordon | drm, not wayland | 21:53 |
| freemangordon | or, wayland oopses too? | 21:54 |
| tmlind | heh i don't think drm works for me :) yeah wayland glmark2 oopses also | 21:54 |
| freemangordon | -drm used to work | 21:54 |
| freemangordon | on 5.10 | 21:54 |
| freemangordon | oh, wait | 21:54 |
| uvos | -drm never worked | 21:54 |
| uvos | on chomeos blobs | 21:55 |
| freemangordon | it still works, with blobs | 21:55 |
| uvos | (for me) | 21:55 |
| freemangordon | yeah | 21:55 |
| tmlind | oopsed | 21:55 |
| freemangordon | :( | 21:56 |
| uvos | did you now try wayland or drm? | 21:56 |
| tmlind | wayland | 21:56 |
| freemangordon | try drm | 21:56 |
| freemangordon | you can rmmod/modprobe | 21:56 |
| freemangordon | 230 files remaining here | 21:57 |
| freemangordon | :) | 21:57 |
| tmlind | heh somehow rmmod no longer works for me.. | 21:57 |
| freemangordon | hmmm | 21:58 |
| freemangordon | weird, works every time here | 21:58 |
| tmlind | after the glmark2 oops, need to reboot | 21:58 |
| tmlind | i'll try again tomorrow actually, zzz time for me here | 21:58 |
| freemangordon | ok | 21:59 |
| tmlind | ok later | 21:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!