[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 #7 from Martin von Gagern <Martin.vGagern at gmx.net> ---
Not sure whether this will be of any use, but I'm trying to think of ways which
might cause this, in my own pretty naive way of thinking about hardware drivers
and graphics cards. Simply ignore dumb ideas. I don't need answers to these
questions, as long as you know that the answers exists and don't help us here.

(In reply to comment #6)
> But 0x00406040 is a perfectly valid command, ever since the Riva TNT chips.

Could it be that the command is invalid AT THAT TIME? Perhaps due to a race
condition? Could it be that the semaphore is already high?

> happens a fair bit for CPU vs GPU syncs.

Therefore the command likely won't fail all the time. The load pattern must be
part of the issue.

Do things like stack overflows occur in GPU memory? Could excessive allocation
of e.g. texture memory somehow clobber memory needed by GPU firmware for
methods such like this?

What other resources might become exhausted by concurrent access from
graphics-intensive applications? Would that exhaustion be reported in some way?

Of course, actual hardware breakage is always an option. But the thing doesn't
seem random enough to suggest a simple hardware defect as the main cause, imho.
Of course it would be nice if I had another card with the same kind of chips to
plug into my system, just to rule out that alternative…

I must confess, I cannot follow how you decode 0x00406040 to method = 0x10. The
way I read BEGIN_NV04, I can find your subc = 0, and size = 0x10, but I'd read
mthd = 0x40 directly from the least significant bits. Did I miss something?

-- 
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/20131011/4ead1c23/attachment.html>