Nicolai Haehnle wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either.
Did I miss something, or is this intended behaviour? It certainly seems strange to me.


Also, it is possible for a DRI client to effectively lock up the entire machine simply by entering an endless loop after taking the lock. I suppose one could still log in remotely and kill the offending process, but that's not a realistic option for most people. Switching to a different VT or killing the X server does not work, because the X server has to take the DRI lock in the process.

This is a problem that I want to fix (it makes playing around with the R300 hack Vladimir Dergachev posted an infinite-rebooting nightmare), but I am unsure what the best solution would be.

If you're looking for ways to deal with debugging unstable drivers, I'm sorry but there's nothing that's going to come close to using two machines - one to do all your development, etc. on, and the other to continually reboot, crash, etc. as your test box.


Keith



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to