Hi!
I have an application that takes the hardware DRI lock and then does an usleep(1) while polling hardware status. Entering the polling function, I've verified that the lock is indeed taken
0x80000002, with 2 corresponding to the correct DRM context. Upon exit from the polling function, sometimes the X server has stolen the lock, 0x80000001, or even 0x1, signalling the X server already did it's processing.
The lock has never been touched by the application in-between.
This, later on results in a drm error when the application tries to submit an AGP command buffer while the X server has stolen the lock.
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held, held -2147483648 owner d2c4a580 d7792780
The occurence is quite rare (this is xine with the via xvmc library), and it happens when a window is moved over xine's output window, triggering a lot of hardware redraws and at the same time a lot of X server activity.
I'm not sure what causes this, but IMHO it's quite serious.
drm CVS as of today. xorg 6.8.2 Mandrake patched.
Anybody having an idea?
------------------------------------------------------- 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_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
