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