Bug 190245

Funnily enough even gnash.i386 crashes on x86_64 with GLXBadContext.

Jens, 

I don't have access to x86_64-machines, nor can I reproduce your problem with
FC4 nor FC5 on i386, nor does gnash look compelling to me.

Are you able to deterministically produce a traceback with "button" or any other
example from GtkGlExt/examples? 

All the gtkglext demos including glxinfo crash immediately on startup for me.
It is 100% reproducible.  However the fact that 32bit apps crash too
makes me wonder if it may be an X/hardware related issue.

Does(In reply to comment #3)
> All the gtkglext demos including glxinfo crash immediately on startup for me.
> It is 100% reproducible.  However the fact that 32bit apps crash too
> makes me wonder if it may be an X/hardware related issue.
Not unlikely - A minimal check would be running glxgears. Does it run?
Another rather frequent issue with GL apps is them being rather "sloppy" on
detecting usable visuals. Some of the gtkglext examples are known to suffer from
this issue (They typically fail if glx/gl doesn't provide a certain feature,
e.g. 24bit visuals.)

A more real world check would be running one of the apps from the Inventor rpm
(e.g. SceneViewer). These are more elaborated (ancient code) than gtkglext and
have been developed on 64bit platforms.

(In reply to comment #3)
> All the gtkglext demos including glxinfo crash immediately on startup for me.
Oops, I missed "glxinfo" ... then you definitely have a HW, GL/glx installation
problem, or an X server config problem.

Is there a faq or wiki page say somewhere that describes how to
track down the problem?  I'm pretty sure it was working with FC4.
(I'm using the xorg-x11 nvi driver fwiw.)  Not sure whether to move
this to kernel or xorg-x11...

(In reply to comment #6)
> Is there a faq or wiki page say somewhere that describes how to
> track down the problem?
Hmm, I am sure there are many, but ... it's been a long time, since I had been
facing low level GL/GLx issues, so I am not aware of any.

Normally, the first step is to check if libGL* are correctly installed (Using
the nvidia-installer breaks them terribly).

Subsequent step would be to check /etc/X11/xorg.conf ('Load  "glx"'
in Modules, dri?).

Afterwards, restart/start "X" and check "/var/log/X.*log". You should see a
message referring to loading "glx".

Next step would be to run glxinfo and xdpyinfo in a terminal and to check their
results. If they appear to work, running glxgears would be an initial test to
verify if gl is working.

>  I'm pretty sure it was working with FC4.
> (I'm using the xorg-x11 nvi driver fwiw.)
nvi? This doesn't tell me much. I know about the nv and nvidia drivers.
(I am using livna's nvidia drivers ;) )

>  Not sure whether to move
> this to kernel or xorg-x11...
Depends, if you're sure your issue is gtkglext related the gtkglext list would
be appropriate. Otherwise, one of the fedora lists also might be useful.

I have the same error (GLXBadContext), with an HP laptop
(AMD Turion 64, ATI Radeon XPRESS 200M as reported by lspci).

I am using the same homebake kernel (2.6.16.16) which worked
OK for me with FC4.
I can get the "radeon" driver to work with FC5, which was not
the case before (I used either plain old "vesa" or the ATI
"fglrx"). However, the error messages from Xorg.log.0 show

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
...
(II) RADEON(0): [drm] drmOpen failed
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.

and so on: In fact the /dev/dri directory is empty even though
the radeon and drm kernel modules are loaded.

Then I get

[root@ceiriog Mesa-5.0.1]# LIBGL_DEBUG=1 glxgears
libGL error: XF86DRIQueryDirectRenderingCapable returned false
X Error of failed request:  GLXBadContext

So firstly, why does the radeon kernel driver not create the
/dev/dri entries (even though I have not changed the kernel)?
and secondly, why does not Xorg advertise the GLX
extension (via xdpyinfo) when it is in fact unusable?


when it is 

Yep, I meant the nv driver, sorry.  mesa-libGL seems to be installed fine.
My xorg.conf has both glx and dri modules listed, and libglx.o loads ok in the 
log. 

Actually I get the error even for a freeglut program.
So this is definitely not a gtkglext bug.

Reassigning to xorg-x11.

After installing rawhide on my x86_64 testbox (ATI Radeon Xpress 200G)
glxinfo and glxgears run just fine now.  So this definitely seems FC5
specific.

Our bugzilla database had a catastrophic failure on June 13, 2006
which lost all bug changes from Thurs June 9th through 13th.  I have
bugzilla email records of the time period however, and will be
restoring as many changes as I can manually.

------- Additional Comments From redhat  2006-06-13 00:56 EST -------
I have the same problem on my FC5 x86_64 box with anything that uses GL (Wine,
Tuxracer, and some OpenGL programming I did for a class).

Looking through the list of possible things to do:
Yes my xorg.conf has glx and dri listed in the module section, and yes, they
load correctly.

My compiled code runs(ran) fine on FC4, but in the upgrade to FC5 it stopped
working.

My system information (let me know if you want full conf files or log files, but
I dont see any point to contributing them as this seems to be exactly the same
problem as everyone else)
Video Card: nVidia Corporation NV17 [GeForce4 MX 440]
Using drivers: nv (included with fc5)
kernel version: 2.6.15-1.2054_FC5 (older version... upgrading versions is a
hassle to re-compile some of my kernel modules..which I will do soon!)
Exact error:
(my simple 'hello world' type opengl application):
freeglut (./a.out): Unable to create direct context rendering for window 'Checkers'
This may hurt performance.
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  143 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  29
  Current serial number in output stream:  29
(Planet Penguin Racer):
PPRacer 0.3.1 --  http://racer.planetpenguin.de
(c) 2004-2005 The PPRacer team
(c) 1999-2001 Jasmin F. Patry<jfpatry>
PPRacer comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
See http://www.gnu.org/copyleft/gpl.html for details.

X Error of failed request:  GLXBadContext
  Major opcode of failed request:  143 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  19
  Current serial number in output stream:  19
(Wine):
err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  143 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  164
  Current serial number in output stream:  164

------- Additional Comments From petersen  2006-06-13 02:43 EST -------
The most useful thing now would be to work out if this is a
kernel or xorg-x11 issue?  Just upgrading fc4 to modular X is
hard, but maybe the fc5 kernel can be installed in fc4?

The problem is a misalignment of the entries in a struct _Visual
between Xorg and Mesa due to a discrepancy in their idea of the
size of a VisualID.  You need to make sure _XSERVER64 is set
before X.h is included, because unsigned long is 64, not 32 bits.
This requires modification to the mesa_source code.  It looks like
this has already been done in the Rawhide version (6.5).  But before
looking at this, I had already fixed the problem with this patch.
Actually, this should be applied to the the mesa_source package
instead (since xm_api.c is actually just a symlink).

Created attachment 131092 [details]
Fix 64-bit issue for GLX

Created attachment 131093 [details]
Pass correct visual pointer to XMesaCreateVisual

While tracking down this bug, I came across this.
I think this is probably right?

Created attachment 131096 [details]
Fix GLXBadContext error on x86_64

This patch includes "dix-config.h" in "glheader.h"
(my previous effort put it in "glxheader.h", which worked
too, but I notice the rawhide version puts it here instead).

If you want to do this by hand and not wait for the official
bug fix:
It needs to be applied to the mesa-6.4.2-6.src.rpm and compiled.
(i.e. add the appropriate PatchXXX and %patchXXX lines in the
spec file).
The resulting rpm mesa-source-6.4.2-6.x86_64.rpm needs to be
installed. Then the xorg-x11-xserver .src.rpm needs to be recompiled
and installed.

Now glxgears runs... very slowly...
Unfortunately I still don't get DRI enabled on my ATI radeon,
but that must be a separate issue (kernel?)

*** Bug 185929 has been marked as a duplicate of this bug. ***

*** Bug 187603 has been marked as a duplicate of this bug. ***

*** Bug 185727 has been marked as a duplicate of this bug. ***

*** Bug 189730 has been marked as a duplicate of this bug. ***

mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

*** Bug 185929 has been marked as a duplicate of this bug. ***

Additional notes:

- This really is a bug in mesa.
- This bug really is fixed in the new mesa.
- The mesa bug, causes there to be a bug also in the X server.
- The X server needs to be recompiled against the new mesa to be properly
  fixed.

The two were intended to go out in a tandem erratum to fix this, but mesa
was being released for something else also, so went out early.  The X server
update has lagged a bit due to unforseen buildsystem troubles which are now
being resolved.

So this issue wont be fully resolved until the X server update is released,
at which time it should be solved for everyone.  So if you are observing
this problem, and still seeing it now, please wait for the X server update
to be released, which should be sometime this week.

Apologies for any inconveniences...

*** Bug 181456 has been marked as a duplicate of this bug. ***

The other half of the fix for this (xorg-x11-server) should be released as
an update sometime today or tomorrow.

Setting state to MODIFIED

mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

xorg-x11-xtrans-devel-1.0.0-3.2.FC5.0 libX11-1.0.0-3.FC5.0 xorg-x11-server-1.0.1-9.FC5.4 xorg-x11-xdm-1.0.1-2 xorg-x11-xfs-1.0.1-4.FC5.0 xorg-x11-xinit-1.0.1-2.FC5.0 xorg-x11-apps-7.0-1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

xorg-x11-xtrans-devel-1.0.0-3.2.FC5.0 libX11-1.0.0-3.FC5.0 xorg-x11-server-1.0.1-9.FC5.4 xorg-x11-xdm-1.0.1-2 xorg-x11-xfs-1.0.1-4.FC5.0 xorg-x11-xinit-1.0.1-2.FC5.0 xorg-x11-apps-7.0-1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Fedora Core 5 is no longer supported, please, could you reproduce this bug with
the updated version of the currently supported distribution (Fedora Core 6, or
Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please
let us know in this bug report.  If after a month's time we have not heard back
from you, we will have to close this bug as CANTFIX/INSUFFICIENT_DATA.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.

The Mesa and Xorg update discussed above fixed it for me.
I'd mark it CLOSED unless anyone else still has problems.

Thanks a lot. Closing per reporter's request.