Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dïnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think this
function will be called asynchronously, so the hardware lock isn't held,
and another client can keep the engine busy long enough for
RADEONWaitForIdleMMIO() to time out, in which case it will try to reset
the chip, still without the lock, which would explain the kernel
messages about radeon_cp_reset. This is also more likely to happen with
SMP, so I think it matches your observations pretty well. :)
Woohoo. We have a likely culprit. Vladimir, does that make sense to you?
Well, have you tried removing the call? Does it fix your problems?
It does make sense to me, an easy way to check is to disable merged framebuffer mode in X.
If it works fine without merged framebuffer than this is an issue.
I am unsure of how to fix it though, as the call *is* needed, we should not be reading from registers with engine busy.
Well, I gave it a shot by commenting out that call, per Michel's instructions. SMP + USB + MergedFB + framebuffer, and everything is working fine. I realize that the call is needed, but maybe we should leave it out till it does less damage than it fixes :-)
Adam
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
