Bug 861699

Summary: [i855] Every GL program does not work with mesa 9.0.1-1.fc18
Product: [Fedora] Fedora Reporter: Mamoru TASAKA <mtasaka>
Component: mesaAssignee: Adam Jackson <ajax>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: ajax, awilliam, bkelly, jerome, jreznik, lech.lobocki, petr.tuma, rbergero, robatino, scp.stjohn, swilmet, tflink
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-08 09:34:58 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
gdb log when lauching glxgears
xorg.0.log again none

Description Mamoru TASAKA 2012-09-30 01:06:30 EDT
Description of problem:
Looks like every OpenGL program causes segfault.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. launch one program using GL
Actual results:
Just segfault, sometimes X crashes.

Expected results:
Does not segfault
Comment 1 Mamoru TASAKA 2012-09-30 01:08:01 EDT
Created attachment 619321 [details]


/etc/x11/xorg.conf does not exist.
Comment 2 Mamoru TASAKA 2012-09-30 01:09:50 EDT
Created attachment 619322 [details]
gdb log when lauching glxgears

gdb log when launching glxgears as one example.
Comment 3 Adam Williamson 2012-10-04 13:50:16 EDT
This clearly isn't affecting everyone, I had mesa 9.0 in the GFX Test Week images.
Comment 4 Adam Williamson 2012-10-04 13:54:48 EDT
[ 67933.956] (--) intel(0): Integrated Graphics Chipset: Intel(R) 852GM/855GM

Here's a quarter, kid, go buy yourself a real graphics card ;)
Comment 5 Mamoru TASAKA 2012-10-11 11:08:17 EDT
With mesa-libGL-9.0-1.fc18.i686, mesa-libGLU-9.0.0-1.fc18.i686:

[tasaka1@localhost ~]$ glxgears 
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  28
  Current serial number in output stream:  30

No segv, however still does not launch.
Comment 6 Mamoru TASAKA 2012-10-11 11:09:36 EDT
Created attachment 625554 [details]
xorg.0.log again

/var/log/Xorg.0.log this time
Comment 7 Mamoru TASAKA 2012-10-27 04:35:16 EDT
Proposing for a final blocker.
Comment 8 Tim Flink 2012-11-30 14:24:21 EST
There have been no new reports or movement in this bug in over a month - is this still happening? Does it affect the operation of shell?

I'm -1 blocker on this - it doesn't seem to be affecting enough hardware to justify blocking release until a fix is available. It doesn't sound like it affects general non-openGL operation of the system, either and could be fixed with an update post-install.
Comment 9 Mamoru TASAKA 2012-12-01 01:38:08 EST
(In reply to comment #8)
> There have been no new reports or movement in this bug in over a month - is
> this still happening? 

No new reports = No improvement yet

> Does it affect the operation of shell?

I am using fallback mode.
Comment 10 Adam Williamson 2012-12-01 03:24:52 EST
-1 blocker, 855 is ancient stuff and GL-only breakage isn't worth blocking for. I believe 8xx is blacklisted for Shell purposes, so such cards get fallback mode, so there's no ootb breakage in critical functionality.
Comment 11 Mamoru TASAKA 2012-12-01 13:16:24 EST
This seems to affect some critical component on GNOME such as gnome-control-center, like:

[tasaka1@localhost ~]$ gnome-control-center 

(gnome-control-center:15657): Gdk-ERROR **: The program 'gnome-control-center' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadContext'.
  (Details: serial 166 error_code 167 request_code 152 minor_code 6)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap
Comment 12 Kevin Fenzi 2012-12-04 18:40:00 EST
-1 blocker, would be nice to fix of course.
Comment 13 Robyn Bergeron 2012-12-04 23:10:43 EST
-1 blocker.  The age of the 855GM ... I would expect laptops with it are probably 5+ years old, and perhaps we might have a few folks running on old/spare hardware but I think the number would be very, very low. GL-only makes it even less blockery; comment 11 wrt gnome-control-center raises an eyebrow a bit but not getting the impression that it is a persistent issue...
Comment 14 Jaroslav Reznik 2012-12-05 08:24:54 EST
Well, the real question is why it leads to the crash mentioned in comment #11.  Could you provide backtrace for the non-GL apps too? It hits the "All applications listed under the Applications menu or category must start successfully" but as pointed by folks, it's probably not very common HW these days.

-1 blocker
Comment 15 Mamoru TASAKA 2012-12-05 10:00:39 EST
(In reply to comment #14)
> Well, the real question is why it leads to the crash mentioned in comment
> #11.  Could you provide backtrace for the non-GL apps too?

Well, why is backtrace for "non"-GL apps needed here (and for what non-GL apps do you want, for example)?
Comment 16 Mamoru TASAKA 2012-12-05 10:10:07 EST
(Note that:

$ ldd -r /usr/bin/gnome-control-center | grep GL
	libEGL.so.1 => /lib/libEGL.so.1 (0x410db000)
	libGL.so.1 => /lib/libGL.so.1 (0x41013000)
Comment 17 Tim Flink 2012-12-05 10:19:32 EST
I count -5 blocker votes, moving to rejected.
Comment 18 SP 2013-01-30 12:10:33 EST
My laptop does have an 82852/855GM Integrated Graphics device and glxgears and desktop effects (with KDE) fail with the upgrade from Fedora 17 to 18.  It worked fine with Fedora 17.  It does not help anyone to rush out a release that breaks usability for many users.
The upgrade was on 01-29-13 and all packages were updated - so no fix yet available it seems.
Comment 19 Mamoru TASAKA 2013-02-13 19:35:03 EST
I've already switched to use rawhide, and it seems that with mesa-9.1-0.1.fc19 GL programs seems to be working. Hopefully mesa 9.1 will be pushed into F-18 to fix this issue.
Comment 20 Mamoru TASAKA 2013-03-19 03:05:05 EDT
I (the original reporter) no longer uses F-18, and now using F-19, however with xorg-x11-server-1.14.0-1.fc19 and mesa-9.1-1.fc19 GL program seem to be working (at least xscreensaver gl hacks are working).

Now it seems mesa-9.1-1.fc18 is going to be pushed into F18 stable, I hope someone can test this issue.
Comment 21 Jerome Hettich 2013-03-21 08:40:54 EDT
mesa 9.1-1.fc18 resolves this for me (on an old Dell inspiron 510m with an 855GM graphics). GL programs and the gnome-control-center which previously failed now working
Comment 22 Lech Lobocki 2013-04-03 16:51:06 EDT
mesa 9-1-1.fc18 fixed this problem on i82865G (IBM ThinkCentre), however the next update (9-1-3) apparently caused (I cannot verify this, since 9-1-1 is no longer available to me) weird problems with KDE (both 4.9 and 4.10 suffer). At random occassions during KDE session (usually, after some time, say 10-30 minutes) the control panel vanishes and window applications suddenly lose taskbars, it becomes impossible to switch focus, etc. 

Initially, I thought this to be a problem with KDE 4.10, so I downgraded it back to 4.9, no effect. Then downgraded Mesa to 9.0 - this helped immediately, however OpenGL applications begun to fail again.

The problem appeared on 7 IBM ThinkCentre computers, 5 of them equipped with i82865G and two with i82915G/GV/910GL.
Comment 23 Mamoru TASAKA 2013-04-08 09:34:58 EDT
- I am the original reporter
- I no longer use F-18, now using F-19
- For me, F-19 mesa-libGL-9.1-3.fc19 seems to be working,

once I close this bug.