04:12 airlied[d]: okay got past 595 hurdle, missing rmon memory allocation, now it can't idle channels just like 580 😛
04:18 gfxstrand[d]: orowith2os[d]: Sadly, neither having ARMv8 nor an aarch64 kernel saves you. The moment any userspace is 32-bit, we're toast.
04:19 gfxstrand[d]: But also, that part is fairly easy. Just copy what panthor does into nouveau.
04:20 gfxstrand[d]: orowith2os[d]: That biggest problem here is that coherent maps are just busted and I don't know why. We're not going to make any more progress until that's sorted.
04:20 gfxstrand[d]: https://gitlab.freedesktop.org/drm/nouveau/-/issues/452
04:22 gfxstrand[d]: It seems kind of okay to have one coherent map but the moment there's a second, we SIGBUS.
04:38 HdkR: Just never run a 32-bit application :P
04:41 gfxstrand[d]: I'm fine with that
04:42 gfxstrand[d]: There are 64-bit builds of Super TuxKart
04:44 HdkR: And all legacy applications just run as AArch64 emulated processes anyway :D
09:58 karolherbst[d]: wow64 for linux when
10:53 marysaka[d]: you mean qemu-user-static right /s
22:26 _lyude[d]: Hm. Looking at the "Kernel Memory Write via Integer Overflow in Nouveau Relocation Offset Validation" email. I don't think that's the right fix but it pointed out something else, e.g. that we are apparently using `unsigned int ` for specifying the offset for `nouveau_bo_wr32()`/`nouveau_bo_rd32()`. Yikes
22:29 _lyude[d]: also, we're using an inconsistent mix of u64/u32 for specifying things like the size all over the place in nouveau_bo.c
22:31 _lyude[d]: airlied[d]: karolherbst[d] just to make sure I'm not making a mistake here - ^ I assume there's no technical reason for actually using 32-bit offsets is there? or is this something we have for compatibility with older chipsets
22:32 airlied: I don't seem to have that email
22:32 airlied: but yeah I doubt we want to use bo_rd/wr32 with very big offsets, not really meant to be a generic used thing
22:33 airlied: uggh relocations use it I supose
22:34 _lyude[d]: airlied[d]: forwarded the email
22:35 _lyude[d]: happy to write up a patch tomorrow or monday
22:43 airlied[d]: The email didn't have any email in it 🙂 do we allow relocs on nv50+, sounds like nv40 might be the only one susceptible
22:46 _lyude[d]: ag-will send again
22:46 _lyude[d]: maybe it's in a special ink only I can read
22:47 _lyude[d]: airlied[d]: resent, try one more time?
22:56 airlied[d]: Okay better info in that one
22:56 airlied[d]: But I'd confirm you can even hit that code on nv50+
23:02 _lyude[d]: gotcha
23:03 _lyude[d]: ....i might know a fix for the flashing screen issue. There's nothing protecting `vma->refs` from concurrent modifications in `nouveau_gem_object_close`!!!
23:28 _lyude[d]: woooohoooo yeah wooooo yeah woo yeah woo wooo wooo wooo wooo yea wooooo
23:28 _lyude[d]: It would appear I just confirmed what is extremely likely to be causing the screen flashing on my machine with nouveau 🙂
23:29 _lyude[d]: we have a race condition in nouveau_vma_new() where we increment the refcount on a vma object that is exposed to other threads without actually grabbing the appropriate lock for doing so
23:43 _lyude[d]: also, who wants to bet that this is probably going to fix a wide range of weird issues outside of just display? 🙂