14:10 karolherbst: DMA_DATA with SRC_ADDR and DST_ADDR being 0 will probably be a reason the GPU ran into memory faults, right? Or is it a "it depends" situation?
14:12 hakzsam: it should indeed hang, unless the src/dst is IMM I think
14:21 karolherbst: I mean it does, just wondering if that's the reason or if it could be something else
14:22 hakzsam: this is likely the reason, including the page fault
14:22 karolherbst: yeah.. I have 4 faults and the pattern is 4 times within the ib, so that matches. Anyway, thanks, guess I'll do more debugging then
16:37 karolherbst: apparently src and dst being 0 is fine if 0 bytes are copied and I missed that part
16:41 hakzsam: yeah, the packet is probably skipped, but there is no point to emit that :)
16:44 karolherbst: apparently radeonsi uses it to force a wait for idle
16:45 hakzsam: for CP DMA presumably
17:33 Venemo: karolherbst: see radv_cp_dma_wait_for_idle. but what are you trying to do exactly?
17:34 karolherbst: debugging my SVM MR
17:34 Venemo: SVM = ?
17:34 karolherbst: shared virtual memory, GPU buffers have the same address than an allocation on the host side
17:34 Venemo: ah, I assume that is an OpenCL feature?
17:34 karolherbst: yeah
17:34 Venemo: got it
17:35 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942 in case you are interested
17:35 karolherbst: tldr: frontend needs to assign addresses to pipe_resources soo.. that's a lot of fun
17:35 Venemo: so you're saying that there is a test case for SVM which causes radeonsi to hang?
17:35 karolherbst: yeah, but it's most likely my fault
17:35 karolherbst: just need to figure out what's wrong
17:36 Venemo: I don't think I'm competent enough in gallium to judge that code :(
17:36 karolherbst: that's the last IB submitted: https://gist.githubusercontent.com/karolherbst/7e7f2b82210bfa7fbb8cbf9a74c74a3b/raw/51db943f0f09a833bb140e92e61c43b9515cc108/gistfile1.txt
17:37 karolherbst: anyway.. probably something weird going on
17:39 karolherbst: happens with si_copy_buffer or maybe the previous si_clear_buffer call is messed up or so.. I'm sure there is a reasource having a NULL address for whatever reason.. oh well
17:39 Venemo: you could try turning on tracing in the IBs, it seems like it's hooked up to PIPE_CONTEXT_DEBUG - then it will be able to tell you until which point in the IB it executed your commands
17:40 karolherbst: one of the issue I'm facing is, that drivers might throw away the bo under certain circumstances, and that could end up messing up the address. I suspect something like that is going on here
17:41 Venemo: that tracing thing would help pinpoint where the problem is
17:42 Venemo: is the kernel able to soft-recover from this hang, or does it bring down your system?
17:42 Venemo: also, do you see any page faults or something like that in your dmesg logs?
17:44 karolherbst: soft-recover
17:44 karolherbst: and it faults on a NULL pointer
17:46 karolherbst: if I flush more often it works perfectly fine btw
17:49 karolherbst: "in page starting at address 0x0000000000000000 from client 0x1b (UTCL2)" what's UTCL2?
17:51 karolherbst: ohh yeah.. one of the ssbos in si_compute_clear_copy_buffer have a gpu_address of 0
17:51 karolherbst: so I guess I need to figure out where that's coming from