[Nouveau] [Bug 70390] [NV84] Repeated system crashes under graphics load, E[PFIFO] DMA_PUSHER and lots of E[PGRAPH]

[bugzilla-daemon at freedesktop.org]

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

--- Comment #10 from Martin von Gagern <Martin.vGagern at gmx.net> ---
Created attachment 87553
  --> https://bugs.freedesktop.org/attachment.cgi?id=87553&action=edit
report 0x00406040 value in nouveau_bo_wr32

(In reply to comment #9)
> (In reply to comment #8)
> > So... the mystery is where does this 0x40 method come from.
> 
> Can we add a bit of debug code somewhere, to detect that specific value when
> it enters the ring, and emit useful information like a kernel stack trace?

Gave this a stab, using a BUG_ON conditional the way this attachment describes
it. Unless static function scope variables don't work the same in kernel space
and in unser space, this should report if, BEGIN_NV04, OUT_RING or some other
command was used to write this value.

Result: I managed to get that first DMA_PUSHER line all by itself:

nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 4 [stellarium[14333]] get
0x0020111a6c put 0x0020116e10 ib_get 0x00000070 ib_put 0x00000097 state
0x80007641 (err: INVALID_CMD) push 0x00406040

With no stack trace or other indication that my BUG_ON got triggered. Also with
no subsequent error messages, or system crash.

So I'd conclude that the line does not neccessarily lead to a crash, and that
the critical value does not get written via nouveau_bo_wr32. Where else could
it come from? What is the most central location where I might put such code?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20131013/022808d9/attachment.html>