seems like there's really an issue when support for opengl ES is compiled into mesa
and running chromium / a composited desktop
it's running more than 1+1/2 days and still no hardlock, knock on wood
will see in a few more hours or tomorrow how it goes ...
Last edited by Danny; 06-29-2011 at 07:26 PM.
most stable graphics card driver for a radeon graphics I EVER had so far
awesome work@ Alex, Dave, Marek and all other devs involved
Thanks a lot !
only googleearth kept on hardlocking the box in the past
will try in the next days if that's still the case with opengl ES not compiled in
I don't even know what ES is used for. What does it do?
It's the "embedded" version of OpenGL, with some of the legacy stuff removed and other stuff tweaked for fixed-point operation (since a lot of embedded/mobile CPUs are not great at floating-point math). It's mostly used on mobile platforms (iOS, Android, etc.). WebGL is also based on OpenGL ES rather than regular OpenGL.
Originally Posted by RealNC
I was more interested about stuff that needs ES. So am I missing anything is I build Mesa without it on a desktop PC?
Right now, not really. Most desktop oriented software that support OpenGL ES has a compile-time switch to use regular OpenGL instead, and most distros default to regular OpenGL.
Originally Posted by RealNC
However, as a lot of mobile/embedded hardware has OpenGL ES drivers, but not full OpenGL drivers, some distros, especially those trying to compete on the ARM architecture (such as Emdebian and Ubuntu), might change that policy in the near future.
and it is STILL happening (the hardlock) !
now even with mp3-playback and then continuously playing a small sound-bit of and mp3 at the hardlock (only power off & on worked after that - this box has no reset button )
will try out the suggested patch once I have access to my system again
seems like the posted patch helps
the GPU still locks up and tries to reset (like I experienced on Ubuntu 11.04 where it was successful to reset but did resets pretty often)
but seems to fail (sometimes it reset the gpu 1-3 times - screen goes blank shortly and I can switch to tty for several seconds and maybe back but then the screen content locks up)
at least it doesn't hardlock anymore (where it couldn't manage to reset the gpu)
I can save the state of my work via magic sysrq key and reboot or shutdown
* it's probably NOT entirely related to Chromium browser but it happens most with it while browsing through github
* it once happened while bringing an minimized window to the front (magic lamp animation and it got stock in the mid of the animation, mp3/music was playing and looped for that moment (1/2 - 1 second loop)
* another time afaik I had switched apps around and wanted to open up an app from awn (avant-window-navigator), clicking on an app icon where it locked up
each time this was with compiz-fusion + gtk-window-decorator enabled
static application switcher, no wobbly windows enabled (these enabled probably trigger it more faster), ...
ok - so some feedback
my system is up now for 3 days + 4 hours
and haven't had a hardlock yet (usually the hardlocks would appear between: after several minutes of uptime or after approx. 1 day and some hours)
I've switched to KDE 4.7 + qt 4.7.3
gcc 4.6.1 hardened, linux kernel 3.0.0, binutils 2.21.1 [set for compilation]
xf86-video-ati, libdrm, mesa, xorg-server all latest stable or rc versions that are available in the gentoo tree
seems like the previous configuration (gnome 2.32* with awn + compiz-fusion 0.8*)
especially in combination with chromium + browsing on github triggered this
this might be an inherent and/or not yet discovered bug lying in the graphics subsystem [or the kernel itself]
that gets triggered and causes hardlocks
since I currently need my box for production I'll stick to KDE 4 for some time and see whether it's stable
actually I'd like to use awn + gnome + compiz-fusion due to its faster workload & improved productivity (time saved)
but kde also isn't that bad
Thanks & please keep up improving the opensource graphics drivers
They rock !