Thomas Hellström wrote:
I don't think this is the cause of the problem, since what you're referring to above is IIRC a drawable spinlock, not the heavyweight hardware lock.

If a client takes the heavyweight lock and then sleeps even for a couple of seconds, the X server should freeze during this time, which it also usually does. In this case (the Mesa testcase) we're talking the minimal amount of sleep available (1ms on 2.6 kernels), and from what I can see in the above file, the X server uses DRM_LOCK, which immediately calls the kernel if the cmpxchg fails.

/Thomas

Since the error messages I get indicate that indeed the filp associated with the HW lock has changed, the stealing has probably occured in the kernel DRM code.

I'll try to check back with the old 2.6-series drm.

/Thomas





Reply via email to