07:10tzimmermann: danvet, hi. the phy-compliance topic branch has patches from drm-fixes and requires a backmerge (dim apply-pull) into drm-misc-next. do i have to backmerge from drm-fixes or from drm-next?
07:11danvet: backmerging drm-next right now means -rc1 lands in drm-misc-next
07:12danvet: that's nasty
07:13danvet: hm not super nasty, since it's pre-merge window
07:14danvet: tzimmermann, just merge it in, it's just a backmerge of drm-next
07:14danvet: without anything else nasty
07:14tzimmermann: danvet, does drm-next contain the fixes from drm-fixes?
07:14danvet: tzimmermann, if you get massive conflicts or anything outside of drm pulled in, then need to stop because then I didn't check the right stuff
07:15danvet: tzimmermann, the baseline for that topic pull is more or less just the merge window drm-next pull plus a few patches
07:15danvet: tzimmermann, or I'm not clear what your question is
07:15tzimmermann: danvet, it's what i wanted to know
07:16danvet: tzimmermann, so if that baseline would have contained non-drm patches, then normal backmerge flow first
07:16danvet: and generally _never_ backmerge anything from the middle of the merge window, it's too crappy normally
07:16danvet: even backmerging -rc1 isn't a good idea, -rc2 is usually much better shape
07:17danvet: also don't bake the merge in if it has conflicts for non-drm-misc drivers
07:17danvet: like amd or intel
07:17danvet: anyway less topic branches, less headaches imo :-)
07:19tzimmermann: danvet, i can also wait another week. there are only a hand full of patches in that topic branch and there's still plenty of time to merge them
07:19danvet: tzimmermann, the topic pull should be safe to merge
07:21danvet: tzimmermann, and it's been stuck for a while, better to land that thing finally
07:21tzimmermann: danvet: but that PR needs the backmerge. i'm worried that i merge back crap
07:21tzimmermann: well, ok.
07:22danvet: I've check the pull against drm-misc-next, against the merge window (it contains nothing outside of drm merge window)
07:22danvet: and doing it here as a test only gives me a conflict in drm/bridge, which is drm-misc material
07:22danvet: so triple-checked verdict: should be fine
07:23danvet: maybe give it a few extra cycles of build testing to make sure
07:27tzimmermann: danvet. i'm confused. you seem to be concerned about the quality of the topic branch (?)
07:27danvet: it's just topic branches are a pain, so better don't have them if we can avoid them
07:27danvet: I think the baseline is roughly ok
07:28tzimmermann: i see
07:36tzimmermann: danvet, thanks for explaining
07:49MrCooper: narmstrong: mesa-ci-aarch64-lava-baylibre runner seems to be having some trouble, see e.g. https://gitlab.freedesktop.org/daenzer/mesa/-/jobs/2300191
07:51narmstrong: MrCooper: investigating
07:53tpalli: MrCooper what one should do when " Pipeline blocked. The pipeline for this merge request requires a manual action to proceed" occurs?
07:53MrCooper: tpalli: assign the MR to Marge :)
07:54tpalli: MrCooper ok thanks!
07:54MrCooper: when it's ready to be merged
07:54narmstrong: `runner=9WEx9Psi status=couldn't execute POST against https://gitlab.freedesktop.org/....` !good
07:54MrCooper: otherwise, you can trigger jobs manually as needed
07:55MrCooper: narmstrong: hmm, might still be fallout from nginx changes yesterday? Let's take it to #freedesktop and ask bentiss maybe
07:56narmstrong: MrCooper: I restarted the runner, please retry a job
07:58narmstrong: daniels: I still have some `WARNING: Checking for jobs... failed runner=9WEx9Psi status=couldn't execute POST against https://gitlab.freedesktop.org/api/v4/jobs/request: Post https://gitlab.freedesktop.org/api/v4/jobs/request: net/http: TLS handshake timeout`
08:19MrCooper: narmstrong: retry passed, took over 20 minutes though
08:19narmstrong: MrCooper: yes, the system is very slow, checking why
10:11MrCooper: is it time to restrict access to master (all Mesa main project branches?) to Mesa maintainers/owners (which includes Marge)?
11:32andrzej_p: danvet: can you also reply to dri-devel with your R-b of https://patchwork.freedesktop.org/patch/361577/ ? I made a typo in the address and sent it to "freedsktop" and then resent to proper address and you replied to the copy which included invalid dri-devel address. The net result is that the patch in patchwork has no R-b.
11:33danvet: andrzej_p, but the 2nd patch only had dri-devel on recipients?
11:33danvet: so that's confusing
11:33danvet: just reply adding dri-devel to my mail and then merge it, that's good enough
14:58danvet: pinchartl, devm_drm_dev_alloc discussion?
15:00pinchartl: danvet: sorry again :-( I'd say tomorrow, but reasonably, I don't think I can find time before the middle of next week
15:12danvet: tzimmermann, can you pls also look at "[PATCH 01/59] drm: Add devm_drm_dev_alloc macro"?
15:12danvet: since you looked at a lot of the driver patches that uses that
15:12tzimmermann: danvet, ok
15:13danvet: tzimmermann, btw did you not push out the topic branch merge?
15:13tzimmermann: no, but it's now in drm-intel-next-queued from what i read
15:14tzimmermann: i wanted to wait until by PR went into drm-next before doing that backmerge. but apparently that's not required now
15:14tzimmermann: s/by/my ^
15:15danvet: tzimmermann, the point of a topic branch is that 2 trees merge it
15:15danvet: if only one merges, really no point
15:16tzimmermann: than i'll merge as well.
15:16danvet: so just for exercise purposes, smash it into drm-misc-next
15:16danvet: it's good learning so next time around you can just reply "pls don't, just merge somewhere" :-)
15:17tzimmermann: danvet, sure but...
15:18tzimmermann: danvet, "dim apply-pull" wants a backmerge from drm-next into drm-misc-next. i'd prefer to do this backmerge after the PR has been merged.
15:18tzimmermann: to keep the git history simpler
15:20danvet: tzimmermann, look at 2b703bbda2713fd2a7d98029ea6c44f9c3159f34 in drm-misc and you know what to do
15:20danvet: or well, drm-tip has that too
15:21danvet: the script is only a bit confusing since drm-fixes also now has these commits
15:21danvet: since the pull request was hanging around in limbo
15:21danvet: if you'd have processed the pull 2 weeks ago it would have said "pls backmerge drm-next"
15:21danvet: I guess maybe it should check both branches
15:36robclark: so, 64b vbo's aren't actually a thing in gles, are they? Just looking at reasons we end up using u_vbuf and wondering if they are worth fixing..
15:44shadeslayer: anholt_: hey! I was wondering, what's your criteria for selecting applications for tracing?
15:46HdkR: robclark: 64bit never made it to ES
15:47robclark: ok.. so might be worth teaching u_vbuf when those formats aren't required..
15:48robclark: not really sure how much u_vbuf hurts in cases where it isn't actually translating anything.. this all just started from trying to track down why we emit identical vbo state every draw in gfxbench driver-overhead..
16:49karolherbst: ehhh.. I have drm_gem_handle_create failing randomly with ENOENT :/ anybody any ideas?
16:50daniels: karolherbst: where are you calling it from, and where are you getting the GEM handle from?
16:50karolherbst: from inside nouveau_gem_ioctl_new
16:50karolherbst: and the handle was just created
16:51karolherbst: ohh wait.. the handle not
16:51karolherbst: mhh, let me see
16:52karolherbst: daniels: well. I want to debug why creating bos randomly fails
16:52karolherbst: and if at least mesa reattempts the call, it succeeds
16:52karolherbst: but I didn't check if calling with the exact same ioctl data works
16:55karolherbst: ahh yeah
16:55karolherbst: doing the same drmCommandWriteRead call again makes it work as well on the second try
16:55danvet: karolherbst, you're using drmIoctl?
16:56karolherbst: danvet: seems like it
16:58danvet: karolherbst, I guess patch your kernel and figure out where that ENOENT is from
16:58karolherbst: from drm_gem_handle_create
16:58karolherbst: ;).. but yeah
16:58karolherbst: I should dig deeper
16:58danvet: ah missed that
16:58danvet: I did read around a bunch of drm an nouveau code
16:58danvet: didn't even spot a ENOENT anywhere
16:58danvet: really shouldn't be
16:58karolherbst: replacing nouveau is just more trivial then booting a new kernel :/
16:59karolherbst: keeps my gdb session
16:59karolherbst: I guess it comes somewhere out of drm directly
16:59danvet: you don't have drm modular?
16:59karolherbst: I have
16:59karolherbst: intel uses it :p
17:00karolherbst: I should probably use a second machine for devel stuff... :/ to much work though
17:01danvet: my work machine is amd
17:01danvet: never run the risk of breaking that
17:01danvet: professionally at least :-)
17:01danvet: all the intel boxes are on fire ofc
17:01karolherbst: wouldn't risk using intel for my personal machiones either :o
17:03karolherbst: the only call where ENOENT could come from would be that idr_alloc one
17:03danvet: hm where?
17:03danvet: I looked there
17:03karolherbst: ohh there is a ret further down though
17:03danvet: I looked into idr_alloc already
17:03karolherbst: okay.. so maybe there is more
17:03danvet: and I looked into nouveau's gem_open already
17:03danvet: and the drm_vma_node_allow
17:03danvet: so no idea
17:04danvet: just add printk everywhere
17:04danvet: and we'll learn what I didn't spot :-)
17:04danvet: I mean for me debugging is mostly "where is my blind spot today?"
17:04karolherbst: let me verify it's ENOENT for real though
17:05karolherbst: okay.. so it's -2 which is ENOENT if I am not mistaken
17:14karolherbst: danvet: ret = dev->driver->gem_open_object(obj, file_priv); fails
17:15karolherbst: calls nouveau_gem_object_open which returns -2 :)
17:15karolherbst: I expect that comes from ttm then
17:15karolherbst: ttm_bo_reserve probably
17:15danvet: uh right that's the one I didn't check
17:16danvet: karolherbst, or the pm_runtime_get_sync
17:16danvet: tried disabling rpm on your nouveau?
17:16karolherbst: the GPU gets resumed
17:17karolherbst: I am debugging CTS fails
17:17karolherbst: so I would have noticed if something fails there
17:17danvet: ok pretty sure the ttm_bo_reserve isn't it
17:17karolherbst: let me verify that :)
17:17danvet: well, but if it's a bit delayed or so
17:17danvet: then it might only work on 2nd try
17:17karolherbst: well.. the CTS was already executing other tests before that
17:17karolherbst: would be weird
17:18danvet: isn't that kernel programming?
17:18danvet: weird shit happening
17:18karolherbst: well.. I am done with debgging runpm shit :D after everybody refused to accept it's an intel hw bug :p
17:19karolherbst: (the nouveau runpm bug we had, I am 99% confident is due to broken intel hw)
17:22karolherbst: ahh, it's nouveau_vma_new
17:22danvet: karolherbst, can't ever admit in public that the hw is broken
17:22karolherbst: it's not about new hardware
17:22danvet: even more so
17:23danvet: just trying to find the people who create the stuff out there is impossible
17:24karolherbst: :/ yeah
17:24karolherbst: we had a super hard time even getting somebody looking into the bug
17:24karolherbst: nobody from intel did..
17:24karolherbst: well.. at least not in private channels
17:24karolherbst: public.. yes
17:24karolherbst: but that wasn't helpful in figuring out what's wrong
17:26anholt_: shadeslayer: "is it an interesting workload to me in any way and can I get a reasonably sized trace?"
17:27anholt_: I would *love* to get some chrome rendering, and some webrender. they're tremendously underrepresented in Mesa's tuning, because they're so hard to measure.
17:27anholt_: I've got a tip from pcwalton (mozilla) on how to get some representative webrender.
17:34imirkin: danvet: it's not broken. it's featureful.
17:42karolherbst: danvet: nvkm_umem_search
17:43danvet: karolherbst, how did you get there?
17:43karolherbst: do you really want to know or will you accept that this happens :)
17:43danvet: just splat a backtrace() in there and let me appreciate the beauty :-)
17:44danvet: I guess it was runtime pm?
17:45karolherbst: danvet: https://gist.githubusercontent.com/karolherbst/56526072aa9b1947b6438540619fb7c0/raw/6476fb52334dad980a8bc5198be04d1783f95fc6/gistfile1.txt
17:48agd5f: danvet, vsyrjala: any idea about https://gitlab.freedesktop.org/drm/amd/-/issues/1100 ?
17:48danvet: well at least not my problem
17:49agd5f: All I did was move drm_dp_aux_register to the late_register function
17:51danvet: agd5f, CONFIG_DRM_DP_AUX_CHARDEV <- test with that enabled, if that's somehow failing we'll fail to set up the i2c
17:51danvet: but that /should/ result in some failure in the mst enabling
17:51danvet: but I think those are silent because hotplug
17:52danvet: that's the only guess I have right now ...
17:52danvet: I have some vague memory that there's some ordering trick, but you do the drm_dp_aux_init ...
17:53danvet: it's also kinda surprising, since if ddc is busted
17:53danvet: how can we even enable the screen
17:54agd5f: it looks like the aux i2c buses are not created for some reason
17:55danvet: also no idea how that meshes with what's happening to MrCooper
17:55agd5f: the aux buses are the ones labeled "dmdc"
17:56agd5f: yeah, that one is weird too. we explicitly set the transfer function
17:58danvet: aux.dev also seems to be set everywhere
17:58danvet: frankly no idea
18:02vsyrjala: adjtm: looks like missing aux regiser in amdgpu_dm_connector_late_register() ?
18:02vsyrjala: agd5f: ^
18:02vsyrjala: somehow ended up in the mst connector's hook
18:03danvet: oh right, which display driver are we even running
18:05danvet: vsyrjala, that part looks good
18:05danvet: convoluted logic, but I think correct
18:06vsyrjala: what looks good? the register is clearly in the wrong place afaics
18:08danvet: hm yeah
18:09danvet: or at least I'm lost enough
18:09vsyrjala: i think what consuses the brain is the fact that amdgpu_dm_initialize_dp_connector() lives inside the wrong file
18:09danvet: yup that's for sure
18:09agd5f: so should we not register aux in the mst late register?
18:09danvet: agd5f, I'm not seeing where you set it up
18:10danvet: and the register for normal dp connectors seems absent
18:10danvet: so I guess that's why MrCooper sees an oops
18:10danvet: the mst dp aux isn't set up properly, goes boom
18:10danvet: and the dp one is set up properly
18:10danvet: but not registered
18:10danvet: anyway my rhubarb toast is ready
18:11vsyrjala: you shouldn't have to do anything for the mst fake aux devices. should be all handled by the drm_dp_mst stuff iirc
18:11vsyrjala: ah, you do have to call drm_dp_mst_connector_late_register()
18:14danvet: iirc Lyude has patches to unify this all for 5.8
18:14danvet: but 5.7 is more hand rolling
18:14vsyrjala: so something like http://paste.debian.net/1140847/ i think should work
18:17agd5f: vsyrjala, yeah, I just typed up pretty much the same thing. Thanks!
18:18Lyude: danvet: unify it in what way exactly?
18:19Lyude: Also - does anyone remember what the name of that kernel argument is that lets you disable the locking on fbcon?
18:23Lyude: oh-i don't think I'll need it actually :)
18:25danvet: Lyude, the patches to remove most of the dp mst driver hooks?
18:26danvet: or was that not you?
20:13Lyude: danvet: oh-yeah that was someone from intel but I finished the last amd bits
20:13Lyude: (I was the one who suggested it though!)