similar to: [PATCH 1/4] drm/nouveau: split fifo interrupt handler

Full piglit run with this patch: http://people.freedesktop.org/~mslusarz/chan_owners.txt This patch covers only a small subset of all error messages, so: Not-yet-signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Comments? Ideas? (This commit depends on this one: http://people.freedesktop.org/~mslusarz/0001-drm-nouveau-split-fifo-interrupt-handler.patch ) ---

Hello, Could someone briefly describe (or point me to the documentation) what can be a reason for getting NV_PFIFO_INTR_DMA_PUSHER status (nouveau_fifo_irq_handler). This started happening immediately after I set the nouveau_vram_pushbuf flag to TRUE ,it's 100% repetitive and causes fences not to be signaled. Below is the debug log from moment of creation of fifo 1 to some point in time

But does it work? --- shared-core/nouveau_reg.h | 248 ++++++++++++++++++++++---------------------- 1 files changed, 124 insertions(+), 124 deletions(-) diff --git a/shared-core/nouveau_reg.h b/shared-core/nouveau_reg.h index ea4a2f6..e2b3012 100644 --- a/shared-core/nouveau_reg.h +++ b/shared-core/nouveau_reg.h @@ -25,14 +25,14 @@ # define NV_RAMHT_CONTEXT_VALID

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

http://bugs.freedesktop.org/show_bug.cgi?id=20341 Summary: NV31 lockup Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: detringj at