https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855557
now ain't that fascinating. optirun combined with fvwm2 is a sure-fire extremely fast and 100% *guaranteed* way to repro this "freezing but you can ctrl-alt-f1 then ctrl-alt-f7 and it miraculously all works whoopidoo" problem. primus (and optirun) is a headless gpu thingy where you have a main CPU/GPU which actually does the screen writing, then you have a *second* xorg server running (this time into a framebuffer) which you have a *second* GPU writing to, where OpenGL is told to use the *second* GPU's acceleration libraries, then primus takes care of dropping the resultant frame(s) into the *first* xorg's screenspace. fascinatingly it's very very easy to make primus/optirun "hang" under fvwm2: all you need to do is resize the window: that results in a wireframe, then primus goes into a *permanent* loop "primus: warning: dropping a frame to avoid deadlock" which is clearly where chromium is obviously going wrong: it's *not* doing the required "frame dropping" and is (surpriiiiise!) ending up in deadlock. now, the hardware shouldn't *BE* getting into deadlock in the first place, and chromium shouldn't *BE* relying on the hardware to quotes get itself out of deadlock quotes, but that's beside the point. this all seems to be, then, a series of overlapping cross-project errors, each inter-related. hardware shouldn't *be* failing but it is. xorg shouldn't *be* deadlocking due to those hardware-related errors but it is. chromium and other programs shouldn't *be* deadlocking because xorg is deadlocking... but they are. l.
