[Pkg-chromium-maint] Bug#848895: Chromium freezes randomly
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Feb 22 14:50:45 UTC 2017
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.
More information about the Pkg-chromium-maint
mailing list