01:49 marex: [ 460.557788] refcount_t: underflow; use-after-free.
01:50 marex: [ 460.557805] WARNING: CPU: 0 PID: 536 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
01:50 marex: [ 460.557957] Call Trace:
01:50 marex: [ 460.557962] nouveau_gem_new+0xc1/0xf0 [nouveau]
01:50 marex: [ 460.558092] nouveau_gem_ioctl_new+0x53/0xf0 [nouveau]
01:50 marex: [ 460.558181] ? nouveau_gem_new+0xf0/0xf0 [nouveau]
01:50 karolherbst: ehhhh
01:50 marex: well ... uh
01:50 karolherbst: that's bad
01:50 karolherbst: but I think we actually have a patch for that..
01:50 karolherbst: either lost or...
01:50 karolherbst: uhm...
01:50 marex: that's the 5.14.9 still btw
01:51 marex: this was firefox on kde 5.something for a chance, on x11 I think
01:51 karolherbst: let me find a proper patch
01:52 marex: karolherbst: dont worry about it, its not urgent
01:52 karolherbst: https://lists.freedesktop.org/archives/nouveau/2020-December/037571.html
01:53 karolherbst: bcf34aa5082ee2343574bc3f4d1c126030913e54
01:53 karolherbst: but that should only matter in an error case
01:54 karolherbst: but.. you might actually hit it or something.
01:54 karolherbst: marex: well.. it leads to memory corruptions
01:54 karolherbst: which have the annoying side effect of causing literally any other issue as well
01:56 marex: karolherbst: that's almost a year old patch , that must obviously be already upstream ...
01:57 marex: ... is not ...
01:57 karolherbst: well...
01:57 karolherbst: we were very bad with this kind of stuff
01:57 karolherbst: but it's already applied
01:57 karolherbst: just didn't end up in linus' tree yet
01:57 karolherbst: it's part of drm.git
01:58 karolherbst: marex: I am working on making the process of getting patches in way easier and less prone to this kind of "missing patches"
01:59 karolherbst: anyway.. it's already in the git repo on kernel.org I just don't know which branches/repo it got pulled in yet: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcf34aa5082ee2343574bc3f4d1c126030913e54
01:59 marex: in the meantime, lemme add another patch into the set of backports
01:59 karolherbst: probably only linus-next
01:59 karolherbst: *linux-next
01:59 marex: karolherbst: I'm already compiling it, picked from next, thanks
01:59 karolherbst: cool
02:00 karolherbst: there are probably still a bunch of random patches left, so I started to clean up patchwork, but.. 1100 patches left to check :(
02:00 marex: sounds like a lot of not-fun
02:00 karolherbst: well.. I started with 4200 patches
02:01 karolherbst: we had this script for mesa which would mark patches as accepted once we push it
02:01 karolherbst: I used that stuff and made some adjustments
02:01 karolherbst: so this got rid of over 3000 patches :)
02:01 marex: oh
02:01 karolherbst: soo.. it could have been worse
02:01 marex: I can imagine the workflow can be improved
02:01 karolherbst: yeah...
02:02 marex: I've seens a few discussions on this topic, but the mail based one is hard to replace
02:02 karolherbst: atm I am working on having gitlab as another option and push also all patches from the ML through that
02:02 karolherbst: atm the CI pipeline runs checkpatch and build tests every patch
02:02 karolherbst: later we want to do hw testing as well
02:02 marex: hmmmm, the gitlab part has its downsides, like you cannot comment on the commit message
02:02 marex: and it doesnt support full-text search in all the messages and comments as far as I can tell
02:02 karolherbst: yeah...
02:02 marex: email does
02:03 karolherbst: it's annoying
02:03 karolherbst: every solution sucks, just differently
02:03 marex: that :)
02:03 karolherbst: but it does also have nice benefits of nice CI integration
02:03 karolherbst: especially the scripting
02:04 marex: gitlab ?
02:04 karolherbst: yeah
02:04 marex: I've started running into limitations of that
02:04 karolherbst: next step I want to work on is that if an MR gets accepted, a bot will add signed-of-by tags automatically, adds Link: tags to point to the MR and merges the patches
02:04 marex: it still isn't geared toward building larger things
02:04 karolherbst: after CI passed
02:04 karolherbst: marex: how so?
02:04 karolherbst: you can trigger CI pipelines of other projects if you really want to
02:04 marex: karolherbst: I;ve been building OE with it, basically the whole OS
02:05 marex: that's where one starts to work around the CI limitations
02:05 karolherbst: well.. try that based on a mailing list :p, but yeah...
02:05 karolherbst: complex deploys make everything complicated
02:05 marex: indeed
02:05 karolherbst: luckily we only have to build the kernel
02:06 karolherbst: or mesa where we already use it heavily
02:07 marex: karolherbst: for mesa the gitlab CI works nicely indeed, I kinda like it there
02:07 marex: all right, kernel is built and installed, let's see
02:08 karolherbst: that's the latest MR I play around against nouveau https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
02:08 karolherbst: I kind of like the idea of having such an annoying bot, so people don't tell users to "just check the logs" :P
02:11 marex: karolherbst: I wasnt aware of this bot, is this one new ?
02:12 karolherbst: marex: I wouldn't call it a bot really.. it's just the CI pipeline using the REST API to post a comment and is using a project auth token for it
02:12 karolherbst: ehh
02:12 karolherbst: "Access Token"
02:14 marex: well, so firefox got totally misrendered , there is rendering corruption and heck even the desktop behind it had black triangle flashing on/off
02:14 marex: seems like the GPU went nutty
02:14 karolherbst: :(
02:14 marex: oh well
02:14 marex: maybe I should run next on this one
02:14 karolherbst: I fixed such a bug for nv30 recently :D
02:15 karolherbst: but on nv30 gnome went nuts with issues
02:15 karolherbst: apparently vbos were broken since forever or so
02:15 marex: and nobody noticed, oh well
02:16 karolherbst: yeah well... it's like GL 1.4 hardware
02:16 karolherbst: 2.1 actually..
02:16 karolherbst: just when desktop start to use more OpenGL features we really find those ugly bugs on drivers for such old GPUs
02:18 marex: karolherbst: I've been mostly dealing with gles2 in the embedded space, thats like gl1.3-1.4 modulo a few features
02:18 marex: so ... no problem
02:19 karolherbst: yeah... but nv50 is in a much better shape than nv30
02:21 marex: oh
02:24 marex: https://www.phoronix.com/scan.php?page=news_item&px=MTMyODE oh ... "Nouveau has supported the Quadro NVS 140M for years with its GeForce 8 enablement, but the support has regressed from time to time." , article from 2013 it seems :-)
02:28 imirkin: marex: the cache error, afaik, is due to a generic issue on nv50
02:28 imirkin: we don't do fifo switching correctly (at least sw intr, but probably other things too)
02:35 marex: imirkin: wouldn't I see that on Quadro FX 880M too ?
02:35 marex: but then, I am not torturing that one with KDE
02:56 imirkin: marex: it's random
02:56 imirkin: i think some boards see it more often than others
02:56 imirkin: marex: the NVS 140M, iirc, is extra-special ... it's missing PCRYPT
02:57 imirkin: (which we handle ... perhaps that's what that phoronix article was about, 2013 sounds right for fixing that)
02:58 marex: :)
21:49 marex: it seems that older quadro 140M is really flaky even on next
22:06 imirkin: karolherbst: what's the latest with CL on nouveau?
22:06 imirkin: karolherbst: i might give nv50 another shot at some point
22:16 karolherbst: imirkin: should work out of the box more or less
22:16 karolherbst: I think
22:16 imirkin: oh wow, ok
22:16 karolherbst: maybe some patches are missing for nv50, but nothing major afaik
22:16 imirkin: where are you with CL-CTS?
22:16 imirkin: on nvc0+, that is
22:16 karolherbst: mhhh, hard to say
22:16 imirkin: lol
22:16 imirkin: that bad, huh
22:16 karolherbst: not really
22:17 imirkin: put another way ...
22:17 karolherbst: the CTS is just really bad
22:17 imirkin: i don't actually need to use CL
22:17 karolherbst: it's more a colelction of CL sample applications
22:17 imirkin: i just think it'd be cool to support
22:17 karolherbst: yeah
22:17 karolherbst: well
22:17 imirkin: so i have zero use-cases, so CTS would be it
22:17 karolherbst: I got test_basic to pass 100% at some point
22:17 imirkin: so if CTS won't work, then i have nothing :)
22:17 karolherbst: I even got luxmark to run
22:17 imirkin: what are some things i can aim to play with?
22:17 karolherbst: but... it didn't like the result
22:17 imirkin: lol
22:17 karolherbst: imirkin: fixing CTS fails I guess
22:18 imirkin: karolherbst: yeah, but i'm not _super_ interested in doing a lot of the "common" legwork
22:18 karolherbst: so essentially, most of the stuff should run
22:18 karolherbst: you just can't expect to get the proper result
22:18 imirkin: esp as it's all going to be in NIR
22:18 karolherbst: mhhh
22:18 karolherbst: I doubt there is anything left besides compiler stuff tbh
22:18 imirkin: i just want to get the nv50 hookup to work so that it's at the same level as nv50
22:18 imirkin: er
22:18 imirkin: "same level as nvc0", obviously
22:18 karolherbst: well.. some annoying API bits
22:18 karolherbst: but
22:19 karolherbst: OpenCL is like 99% in the compiler
22:19 imirkin: i get that
22:19 imirkin: but i'd rather put that work into making sure the nv50 stuff works well
22:19 karolherbst: yeah...
22:19 karolherbst: ask Pierre
22:19 karolherbst: I think there are some leftover patches for nv50
22:19 imirkin: right
22:19 karolherbst: let's see...
22:19 imirkin: i'm aware of those
22:19 karolherbst: okay
22:20 karolherbst: besides that... I think only fixing nir regressions is really what's left
22:20 karolherbst: I mean...
22:20 imirkin: perhaps i phrased my comment poorly
22:20 imirkin: what i mean is
22:20 karolherbst: there is something
22:20 karolherbst: but this is _super_ annoying
22:20 imirkin: i'm not super-interested in the common spirv / nir code
22:20 karolherbst: userptr UAPI
22:21 imirkin: i'm more interested in making the nv50_ir_from_nir (and anything downstream of that) to work well with nv50
22:21 karolherbst: CL kind of requires userptr if you don't want the runtime to suck
22:21 karolherbst: ahhh
22:21 karolherbst: mhhh
22:21 karolherbst: soo..
22:21 karolherbst: there are two ways of going on about it
22:21 imirkin: but also i don't want to do a ton of the legwork on making nv50_ir_from_nir support "general" things
22:21 karolherbst: 1. run piglit or the GL CTS with nir enabled instead of TGSI and fix all the regressions
22:21 imirkin: i.e. i'd like to limit my improvements to making nv50 work well, vs other things
22:21 karolherbst: or just crunch through the remaining patches from Pierre
22:22 karolherbst: imirkin: well.. it works good enough for Volta+
22:22 imirkin: if it doesn't work with nvc0, "someone else" can fix it
22:22 karolherbst: I think there are like 50 regressions left to fix in the entire CTS?
22:22 imirkin: well, i was hoping to focus on CL rather than GL
22:22 karolherbst: right
22:22 karolherbst: mhh
22:22 imirkin: since GL works well enough, and i'll just be mad about having to re-fix the same things i already spent a bunch of time making work well before
22:23 karolherbst: I only know about pierres patches tbh
22:23 imirkin: ok, fair enough
22:23 karolherbst: ohh
22:23 karolherbst: one thing
22:23 karolherbst: one could fix that FILE_ADDRESS crap
22:23 karolherbst: I overused it a little I think
22:23 imirkin: mmmm ok. i doubt it's overused, but i could look
22:23 imirkin: what in particular?
22:24 karolherbst: I had no idea where to use FILE_ADDRESS so I used it in places it might make sense...
22:24 imirkin: ok. so more of a general audit?
22:24 karolherbst: yeah
22:24 imirkin: ok, i can have a look
22:24 karolherbst: I think that would be useful
22:24 imirkin: in nv50_ir_from_nir, right?
22:24 karolherbst: just making sure it's not terrible broken in certain ways
22:24 karolherbst: yes
22:24 imirkin: will do
22:24 imirkin: the FILE_ADDRESS stuff is "slightly" subtle
22:25 karolherbst: yeah..
22:25 imirkin: but realistically, the move is to do whatever from_tgsi does :)
22:25 karolherbst: I think I use it for all indirects or so
22:25 imirkin: i think that's a mistake for memory indirects
22:25 imirkin: i.e. ssbo/etc stuff
22:25 karolherbst: yeah... I think the compiler fixes it up anyway
22:25 imirkin: for nvc0, sure
22:25 imirkin: but for nv50 it'll end up with an address register
22:25 imirkin: which will lose data
22:25 karolherbst: ahh
22:26 imirkin: address regs are 16-bit (not really, but it's easiest to think of them that way)
22:26 imirkin: which is all well and good for e.g. constbuf indexing
22:26 karolherbst: another thing would be that nir_shader_compiler_options stuff, but I think Pierre already has a patch for that
22:26 imirkin: (and a few other spots they're used)
22:26 imirkin: but not so much for global memory addressing into a 128MB ssbo
22:26 karolherbst: we should review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10711 and merge it
22:26 imirkin: ok. i'll look through those and see what's good and what need smore work
22:27 imirkin: i think pmoreau said he wasn't really going to have a ton of time going forward
22:27 karolherbst: well, we can always fix up the patches and merge it anyway
22:27 imirkin: karolherbst: unrelatedly, another thing i want to do is wiki overhaul
22:27 karolherbst: yep
22:27 imirkin: i'm going to try to put something together soonish
22:27 karolherbst: cool
22:27 imirkin: (i know i've said it before, but ... for realz this time?)
22:27 karolherbst: there is always something more important
22:28 imirkin: do you know if there's a way to get a preview via gitlab?
22:28 karolherbst: yes, in the MR
22:28 karolherbst: or locally
22:28 imirkin: i'm interested in both
22:28 imirkin: can you tell me more / point me somewhere?
22:28 karolherbst: just do what CI is doing: https://gitlab.freedesktop.org/nouveau/wiki/-/blob/master/.gitlab-ci.yml
22:29 karolherbst: you can ignore the sphinx stuff
22:29 imirkin: and how to preview in MR? look at the build results?
22:29 karolherbst: e.g. look at https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/18
22:29 karolherbst: there is this "View exposed artifact" point
22:29 imirkin: neat-o
22:29 karolherbst: then open "public" and click a html file
22:30 imirkin: thanks
22:30 karolherbst: I wished it would be as nice as the way before, but... that would have meant rewriting all the files and using the gitlab wiki stuff
22:32 karolherbst: installing those extra packages for ikiwiki is important though, it won't fail if they are missing afik
22:32 karolherbst: just not generate everything as we want it to
22:34 karolherbst: we should put that into a README.md file :D
22:34 karolherbst: ohh
22:34 karolherbst: I actually did
22:34 imirkin: karolherbst: i expect to rewrite the entire thing. what's the "new" way?
22:34 karolherbst: jcline started to do that in sphinx
22:34 karolherbst: which is located inside docs/
22:35 karolherbst: there is a pending MR you could work on as well: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/15
22:38 imirkin: interesting, i'll have a look
22:38 imirkin: really my view is that with rare exceptions, the info in the wiki is *wrong*
22:38 imirkin: so i sorta just want to start from scratch
22:38 karolherbst: yeah...
22:38 imirkin: port the handful of things which aren't completely bogus
22:39 karolherbst: my only concern with that is, I don't want to break external links
22:39 imirkin: and then we can add new things as necessary
22:39 imirkin: we can maintain a couple of redirects
22:39 karolherbst: either we add redirects, or we put stuff under the same URL
22:39 imirkin: maybe for stuff linked off the main page
22:39 karolherbst: well
22:39 imirkin: redirects, imo
22:39 karolherbst: that's the reason I did this google thing
22:40 imirkin: google can follow redirects
22:40 karolherbst: google yes, but not other websites
22:40 karolherbst: well
22:40 karolherbst: browsers can
22:40 imirkin: :)
22:40 karolherbst: but I wanted to know which pages we can just remove
22:40 imirkin: most :)
22:40 karolherbst: and which are the most commonly accessed ones
22:40 karolherbst: I can give you access if you want to
22:41 karolherbst: apparently reddit has the most links to the wiki :D
22:42 imirkin: heh
22:42 karolherbst: so if you want to look at the data, I just need your google account email
22:43 karolherbst: imirkin: https://search.google.com/search-console/links?resource_id=https%3A%2F%2Fnouveau.freedesktop.org%2F&hl=en does this work?
22:43 karolherbst: anyway.. in case it works, have fun with this :D
22:43 imirkin: yep
22:43 imirkin: thanks
22:43 karolherbst: np
22:43 karolherbst: we could improve mobile usability e.g. :D
22:43 karolherbst: but oh well
22:44 karolherbst: let's wait until we have the fancy new wiki
22:45 imirkin: anyways, i see the redirect issue as secondary
22:45 karolherbst: yeah
22:45 karolherbst: me as well
22:45 imirkin: primary issue is to have a site which makes sense
22:45 karolherbst: just something we should keep in mind
22:45 imirkin: and then we can think about how to make every link to nouveau not break
22:45 imirkin: so i'll work on that.
22:57 imirkin: karolherbst: just looked at those "opencl part 1" patches. look pretty reasonable. i'm going to pull in and maybe make a handful of changes and then re-push.
22:57 karolherbst: okay cool
22:57 karolherbst: will review it then
22:58 imirkin: yep