https://bugs.freedesktop.org/show_bug.cgi?id=20341
--- Comment #14 from Ilia Mirkin <[email protected]> --- Don't worry about the WARN -- that should get fixed in -rc7 (or you can grab nouveau/master). [ 5096.360378] nouveau E[ PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[1337]] get 0x00037be4 put 0x0001d690 state 0x2000a428 (err: CALL_SUBR_ACTIVE) push 0x00000000 This is bad. Once this happens, I guess the fifo is out of sync, and that is a recipe for bad times. From https://github.com/envytools/envytools/blob/master/hwdocs/fifo/dma-pusher.txt: """ The call command copies dma_get to subr_return, sets subr_active to 1, and sets dma_get to the target. If subr_active is already set before the call, the DMA_PUSHER error of type CALL_SUBR_ACTIVE is raised. The return command copies subr_return to dma_get and clears subr_active. If subr_active isn't set, it instead raises DMA_PUSHER error of type RET_SUBR_INACTIVE. """ And it looks like we make use of the call functionality in nouveau_gem_ioctl_pushbuf. The whole scheme seems a bit fragile since we do the call to some new pushbuf, and then tell userspace to write a return at the beginning of its next pushbuf. However we might need to do a call in order to get to that pushbuf, thus causing this condition. But... this code is very subtle so perhaps I'm missing why this can't happen. Another thing to try is nouveau.vram_pushbuf on the kernel cmdline -- this might be what the old CBLocation thing did, not sure. -- 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
