17:23karolherbst: Lyude: I am sure that resuming issue we have might be something simliar to your display messup. As running fini like unloading nouveau doesn't cause the issues afterwards
17:24karolherbst: not fini as in suspending
17:39vita_cell: guys what is the command for reclock
17:53vita_cell: I have nothing inside /sys/kernel/debug/
18:26karolherbst: vita_cell: depends on your GPU
18:47karolherbst: mslusarz: there are some unknown ioctls when running an opencl application with cuda-memcheck
18:47karolherbst: 0x38 and 0x3a
18:48karolherbst: mhh, uses the /dev/nvidia-uvm-tools file
18:53karolherbst: also, pushing one of my other traces through demmt gets me this: https://gist.github.com/karolherbst/4228a17b8f5f2458d9d784fd63d39326
18:53karolherbst: but I guess this is a demmt bug
18:54vita_cell: karolherbst GTK770 4gb
18:54vita_cell: but why now do I need mount? previously I had not
19:03karolherbst: dunno, your system :p
19:03karolherbst: not related to nouveau at all
19:46mslusarz: karolherbst: "= = 1 6 9 8 6 = = b r k s e g m e n t o v e r f l o w i n t h r e a d" is a Valgrind warning
19:48mslusarz: either application you are tracing is buggy or Valgrind's coregrind is... not perfect ;)
19:48mslusarz: nothing to do with mmt or demmt
19:48karolherbst: I am sure that the application isn't buggy on the CPU side
19:48karolherbst: matve nvidia OpenCL/Cuda libs are though
19:49pendingchaos: I don't think it's a serious problem
19:49pendingchaos: http://valgrind.org/docs/manual/manual-core.html#manual-core.limits (the first item)
19:49karolherbst: anyway, the mmt trace I got is mostly garbage
19:51mslusarz: hmm, you may try to set MMAP_THRESHOLD env var to some low value and see if it helps vg
19:51karolherbst: " Warning: noted but unhandled ioctl 0x27 with no size/direction hints."
19:51karolherbst: same for 0x7ff
19:52mslusarz: MALLOC_MMAP_THRESHOLD_ actually
19:54karolherbst: setting that to 0 helps... or maybe it is just random
19:56mslusarz: it changes the threshold where libc stops using sbrk and starts using mmap
19:56mslusarz: and VG complains about brk, which seams relevant ;)
19:57karolherbst: those are all the vlagrind messages I get: https://gist.githubusercontent.com/karolherbst/494b7b2c2225b6cc8cee0e65864f24f4/raw/27e64daa0ce845a32ea442f540534542e1f47140/gistfile1.txt
19:57karolherbst: mslusarz: yeah, but setting MMAP_THRESHOLD also helped and then it didn't anymore ;)
19:58karolherbst: the first one looks odd
19:58karolherbst: 0x7ff as well
19:59mslusarz: all those ioctls look weird
20:00karolherbst: the parsed thing is also kind of "empty"
20:00karolherbst: wanna have the trace?
20:01mslusarz: one is supposed to encode some important informations (size of the call, is it read or write, etc) in ioctl number and it seems nvidia ignored this convention with these ioctls...
20:03mslusarz: just adding "null" support for these ioctls may be enough
20:03mslusarz: or just quieting these messages
20:04karolherbst: yeah, I guess this would be better for now
20:04karolherbst: I simply want to know how nvidia sets up its trap handler for shader
20:06mslusarz: I'd recommend adding an option for that with default set to the current behavior
21:18karolherbst: mslusarz: can I somehow debug where that syscal is coming from? gdb doesn't seem to be much help here (or maybe there are magic valgrind macros, dunno)
21:30karolherbst: pendingchaos: ever mmt traced a compute shader on maxwell?
21:33karolherbst: not being able to extract the compute shaders is a bit annoying :)
21:34pendingchaos: I don't have a maxwell card
21:34pendingchaos: I do have a Pascal one and IIRC I didn't seem to be able to do it
21:35karolherbst: ohh, I see
21:36karolherbst: the code looks okayish though, so no idea what's up there
21:47karolherbst: mhhh, the unhandled class is 0xb06f
21:51mslusarz: karolherbst: maybe this: http://valgrind.org/docs/manual/manual-writing-tools.html#manual-writing-tools.advice ?
21:52karolherbst: mslusarz: maybe. Anyway, I doubt that those unhandled syscalls/ioctls area actually related to demmt not being able to parse/detect the compute stuff. We probably just miss something somewhere.
21:53mslusarz: where do you get unhandled b06f class?
21:54karolherbst: b0 should be maxwell, 6f? no idea
21:55mslusarz: b06f is fifo object
21:56karolherbst: I guess we could update those rnndb things
21:57karolherbst: I guess this sounds kind of important
21:58karolherbst: mhh, those are handled though
21:59mslusarz: are there any errors in demmt output?
22:00karolherbst: not that I am aware of
22:00mslusarz: those usually indicate where the problem may be
22:00karolherbst: decode_gk104_compute_terse is never called though
22:00mslusarz: ok, can I see the trace?
22:12karolherbst: ohh wait
22:12karolherbst: it looks like it is indeed due to those weirdo ioctls
22:13karolherbst: or maybe not, I simply don't know enough about all that
22:14karolherbst: those happen quite often though
22:14karolherbst: especially 0x21
22:22mslusarz: the problem with decoding this trace seems to come from demmt not understanding something about gpu vm setup
22:23mslusarz: with -g1 switch it should print gpu address of each read and write
22:23mslusarz: but it doesn't
22:24mslusarz: take a look at how demmt decodes other traces with this switch
22:24mslusarz: it should look like: "w 12:0x12ec (gpu=0x10027c2ec), 0x6b11decb"
22:25mslusarz: but for this trace it prints only "w 1:0x0371, 0x00"
22:31karolherbst: mslusarz: mhh, interesting
22:42mslusarz: I have a feeling ioctl 0x21 has something to do with gpu vm mapping
22:43mslusarz: you will have RE it...
22:43mslusarz: you will have to RE it...
22:46mslusarz: demmt/scripts/mmiotrace may help you with that
22:48mslusarz: I have to go, bye
22:50mooch3: just reviewed that pr
23:45karolherbst: mslusarz: nice, will try that out