Symptoms:
=====
Complete workspace freeze.  X does not respond to keyboard input (including toggle keys and Ctrl-Alt-<key> sequences) or mouse movement.  System is fully functional over ethernet otherwise.  'top' shows no processor usage by X or the clients.  Upon remotely killing last-launched GL client, X resumes normal operation.


Environment:
=====
VIA mainboard with CX700 host bridge (VT0324)
  and Unichrome Pro II IGP graphics processor (VT3157)
128 MB out of 512 MB mapped to shared graphics memory

Slackware Linux 11.0
GCC 3.4.6 default compiler, Glibc+NPTL 2.3.6 default libc
Kernel 2.6.20 (*)
Xorg 7.1.1 built using modified scripts found at:
  http://www.linuxquestions.org/questions/showthread.php?t=490395
Kernel DRM via.ko, drm.ko module from mesa/drm HEAD (*)
  (last change Thu, 15 Feb 2007 11:11:38 +0000)
libdrm from mesa/drm HEAD
  (last change Thu, 15 Feb 2007 11:11:38 +0000)
X DRI unichrome_dri.so module from Mesa's mesa_6_4_branch git repo
  (last change Wed, 18 Oct 2006 14:56:08 +0000)
X DDX via_drv.so from either unichrome.sf.net (*) 
  (last change Fri, 9 Feb 2007 18:11:46 +0000)
or openchrome.org (*)
  (SubVersion 294)

AIGLX and the Composite extension have been disabled.

*patched to find board product IDs and perform as expected.


Reproduction:
=====
Use WindowMaker (was not able to duplicate with others).
Start X as either root or a user.
Launch a terminal application.
Launch two GL clients (I used noof and glschool from the xscreensaver collection).
Use Alt-Tab window switching to switch among active windows.
Observe deadlock.


Comments:
=====
From the trimmed dmesg (appendix 2), it appears that a process is requesting the hardware lock when it already has possession of it.  Preliminary patches to either ignore the request or falsely report a successful lock capture have resulted in the client being killed from attempting to access DMA without holding the lock.

I'm uncertain as to whether this may be related to bug #9457.  I've been working with this off and on since late January and haven't seen any change with regards to this issue from either VIA- or locking-related patches during that timeframe.

--Jason


Appendices:
=====
1.)  Full dmesg (.gz) to deadlock.
2.)  Trimmed dmesg capture (.gz)
     Notes:  pid 2597==X, 2624==noof, 2625==glschool
             drm.ko's debug=3
3.)  xorg.conf (.gz)
4.)  Xorg.0.log (.gz) for the unichrome.sf.net driver
5.)  Xorg.0.log (.gz) for the openchrome.org driver
     Notes:  both invoked with:  startx -- -verbose 7 -logverbose 7 -keeptty