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