Thomas Hellstrm 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
Thomas Hellstrm wrote:
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.
Hmm, This is a nasty one.
What seems to happen is that when the X server waits in the kernel for
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
0x8002, with 2 corresponding to the correct DRM context. Upon exit
from the polling function,
Thomas Hellström wrote:
Hi!
I'm not sure what causes this, but IMHO it's quite serious.
OK, Easy to reproduce also with Mesa DRI.
I did the following alteration to via_context.h, so that it sleeps just
before and just after it takes the
hardware lock: The sleep before is necessary so that other
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
0x8002, with 2 corresponding to the correct DRM context. Upon exit from
the polling function,
Hi!
Dave Airlie wrote:
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
0x8002, with 2 corresponding to the correct DRM context. Upon exit
