https://bugs.freedesktop.org/show_bug.cgi?id=70390
--- Comment #14 from Martin von Gagern <[email protected]> --- (In reply to comment #13) > nv84_fence_emit32+0xda/0x1a0 > > Can you figure out exactly which write this is pointing at? For some of the > values, it could be perfectly legitimate to have the 0x406040 value (e.g. > the sequence id, or the low bits of the address). It's the sequence id. The inlined OUT_RING function makes line numbers almost unusable, but I see the right shift for upper_32_bits, and it's the third nouveau_bo_wr32 call after that. False alarm? > My point about nv50_dma_push is that this is the path that user-submitted > command streams take; they don't go through nouveau_bo_wr*, they are written > by userspace via mmap'd sections, and then commands are written to the ring > to jump to them. I see. And after all, I got the error message in comment #10 without triggering the BUG_ON, so there has to be a way around this check. So what exactly do I examine in nv50_dma_push? I see arguments delta and length, and the delta is used to compute some offset. But all of these are declared as integers of various sizes and signedness, not as pointers. Should I cast one or the other to void* and iterate over length 32bit words? Or length/4 32bit words? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
