On Sunday 22 May 2005 21:00, Jerome Glisse wrote: > Hi, > > I setup a x86 with radeon 9800 pro or xt, trying to find > why it locks. I see little improvement with option no silken > mouse can you test and tell me if it dones anythings for > you (X -nosilk). > > My thought on this lockups is that it's similar to the one > r200 users report, X taking 100% of CPU waiting for > something. I saw a mail from Felix about a lock holding > issue will try to dig in mail archive.
If I interpret the logs correctly, all those lockups are of the form where the R300 fails to process the ring buffer any further, i.e. the R300 locks up. This in turn causes the 3D driver or the X server (depending on the exact circumstances, and probably in a rather random fashion) to wait for the R300 to become idle in an endless loop. The 100% CPU usage is merely caused by the fact that we're polling the chip instead of doing proper IRQ-based wait-for-idle. > Anyone have any idea on that ? Could it be the mouse > code in xorg ? Or is it in r300_mesa or drm ? I really > suspect xorg radeon code... It is easy to blame the DDX, but the truth is, we just don't know. The people seeing lockups should try to figure out whether there is a direct causal connection between e.g. mouse movements and lockups. If you are in a fullscreen OpenGL applications, not moving the mouse, no popups occuring from something like a panel applet, and the chip *still* locks up, it is highly unlikely that the DDX is at fault. It is equally likely that the lockup is caused by, say, alignment or wraparound issues of the ring buffer. Note that fglrx always submits commands in indirect buffers, which are stored linearly in physical memory. We, on the other hand, always submit commands into the ring buffer, which is not linear (because it wraps around). Also, fglrx likes to emit NOPs into the command stream sometimes, though I haven't been able to find an exact pattern in those NOPs. We never emit NOPs (or do we?). So the fact is: We just don't know whether alignment/wraparound can cause trouble. The emission of NOPs by fglrx is IMO significant evidence that there *are* issues in this area, at least on some chipsets, but it could just be some weird artifact of the fglrx codebase. cu, Nicolai
pgpgCpffRgue8.pgp
Description: PGP signature
