[Bug 20341] NV31 lockup

[bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org]

[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=20341

--- Comment #14 from Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> ---
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.

[-- Attachment #1.2: Type: text/html, Size: 2403 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau