My R430 based graphics card can only run the first opengl program after X is loaded. For example, I can load glxgears, and then after I close glxgears and try to load it again I get an error message saying that it can't get a double buffer RBG visual.If I restart X I can once again load the first opengl program, but none after that until I restart X. I currently have Xserver 1.4 installed, or Xorg 7.3 installed with the git clone of mesa, libdrm, and drm modules.This bug started about a month ago. I was thinking of testing the three additional GLX extensions since Mesa 7.0 was released. One more thing is that if I install mesa 7.0 I can get opengl working again without restarting the X server.
This occurs after any 3d app has been run once.
Weird one - I suppose this doesn't happen with Git of everything including xserver? Can you attach the output of glxinfo from before and after the problem?
brian@masigla ~ $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20061018 NO-TCL OpenGL version string: 1.3 Mesa 7.1 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x60 32 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None brian@masigla ~ $ glxinfo name of display: :0.0 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x25 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 libGL warning: 3D driver claims to not support visual 0x28 libGL warning: 3D driver claims to not support visual 0x29 libGL warning: 3D driver claims to not support visual 0x2a libGL warning: 3D driver claims to not support visual 0x2b libGL warning: 3D driver claims to not support visual 0x2c libGL warning: 3D driver claims to not support visual 0x2d libGL warning: 3D driver claims to not support visual 0x2e libGL warning: 3D driver claims to not support visual 0x2f libGL warning: 3D driver claims to not support visual 0x30 libGL warning: 3D driver claims to not support visual 0x31 libGL warning: 3D driver claims to not support visual 0x32 Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 0 8 8 8 0 24 8 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r y . 0 8 8 8 0 24 0 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r y . 0 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r y . 0 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r . . 0 8 8 8 0 24 8 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r . . 0 8 8 8 0 24 0 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r . . 0 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r . . 0 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r y . 0 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r y . 0 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r y . 0 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r y . 0 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r . . 0 8 8 8 0 24 8 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r . . 0 8 8 8 0 24 0 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r . . 0 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r . . 0 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x60 32 tc 0 32 0 r . . 0 8 8 8 0 0 0 0 0 0 0 0 0 Ncon
I changed it from a specific driver to mesa core because this is happening with software, and all the radeon drivers. This is also on the AMD64 platform with xorg-server 1.4. I did try Git X11 server, and friends, but there were more serious corruption bugs with regards to 3d acceleration, but the bug existed there too. The glxinfo command was run right after the first. One thing I have noticed is that if I have X loaded with mesa 7.0.2, and then install mesa git and run glxinfo/glxgears and other 3d apps the bug doesn't appear. Once I restart the X server this begins to happen. This also occurs on a fresh power up / reboot. I'm not noticing anything odd in the Xorg.0.log either.
(In reply to comment #4) > One thing I have noticed is that if I have X loaded with mesa 7.0.2, and then > install mesa git and run glxinfo/glxgears and other 3d apps the bug doesn't > appear. Once I restart the X server this begins to happen. Interesting, so the issue seems to be on the server side. If you have AIGLX enabled, can you try disabling it, or vice versa? P.S. Please create attachments instead of cluttering up comments.
Do you have AIGLX enabled on your X server? Does indirect rendering work better? Try LIBGL_ALWAYS_INDIRECT=1 glxinfo and similar for glxgears.
> OpenGL renderer string: Mesa DRI Radeon 20061018 NO-TCL Why is it using radeon on r300 ?
I have tried with both AIGLX enabled, and disabled. I was using just the default xorg.conf file generated by X -configure, but I disabled AIGLX and the same thing occurs as in Comment #3. I also tried LIBGL_ALWAYS_INDIRECT=1 while AIGLX was enabled since that would be required for indirect rendering, and the same occurred. The reason that the output in Comment #3 says radeon for the driver is that I am currently using a Radeon 7000VE, but I have the following video cards to test this bug with: 3dfx Voodoo 3500TV AGP, Radeon 7000VE, Radeon 9000, Radeon 9250 (128/256Meg), and my ATI Radeon X800 XL (256Meg) video cards. I have currently tested the X800 XL, and 7000VE for this bug, and both have it as well does software rendering when DRI doesn't load correctly.
Created attachment 12988 [details] Mesa 7.0.2 Xorg server 1.4 log Xorg log with mesa 7.0.2. Hoping that this gives more information.
Created attachment 12989 [details] Mesa 7.1-git Xorg server 1.4 log More log, but with Mesa git, and libdrm git.
Hi, I've the same problem on the same platform: amd64 x850 after running glxinfo, dmesg | tail: [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs Also I manually create a s-link to libGL.so after Mesa installation on Gentoo.
Sorry, I've dummly wrote the r300 initialization kernel output. Not just kernel output aftere glxgears. How can I help debugging?
I started getting this recently as well, with git images of libdrm, x11-drm and mesa, for r300. Was fine about a month ago, the last time I recompiled this stuff. Anybody figure this one out yet?
(In reply to comment #13) > I started getting this recently as well, with git images of libdrm, x11-drm and > mesa, for r300. xserver Git as well? On 64 bit? ...
The solution is to use Xserver GIT as well.
Whoops! Yeah, it works fine with git xserver, and yeah, it's 64 bit. I haven't been using git xserver for a while, because I've been having issues with fonts and window damage redraws. Slashdot and a few other sites have their fonts all garbled, so I've been using xserver 1.4 until it gets fixed, or until I figure out how to fix it myself. git drm used to work with 1.4, but something broke in the last month or two. (actually, even the fonts in this bugzilla page are corrupt. Scrolling the window down and back slowly, or highlighting the corrupt text with the mouse clears it temporarily - any thoughts on this)?
On Sat, 2008-03-22 at 03:27 -0700, bugzilla-daemon@freedesktop.org wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=13358 > > > > > > --- Comment #14 from Michel Dänzer <michel@tungstengraphics.com> 2008-03-22 03:27:47 PST --- > (In reply to comment #13) > > I started getting this recently as well, with git images of libdrm, x11-drm and > > mesa, for r300. > > xserver Git as well? On 64 bit? ... > Whoops! Yeah, it works fine with git xserver, and yeah, it's 64 bit. I haven't been using git xserver for a while, because I've been having issues with fonts and window damage redraws. Slashdot and a few other sites have their fonts all garbled, so I've been using xserver 1.4 until it gets fixed, or until I figure out how to fix it myself. git drm used to work with 1.4, but something broke in the last month or two.
(In reply to comment #17) > I haven't been using git xserver for a while, because I've been having > issues with fonts and window damage redraws. Slashdot and a few other > sites have their fonts all garbled, Sounds like bug 13104. > git drm used to work with 1.4, but something broke in the last month or two. This is probably between xserver and mesa but unrelated to drm.
On Mon, 2008-03-24 at 02:19 -0700, bugzilla-daemon@freedesktop.org wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=13358 > > > > > > --- Comment #18 from Michel Dänzer <michel@tungstengraphics.com> 2008-03-24 02:19:06 PST --- > (In reply to comment #17) > > I haven't been using git xserver for a while, because I've been having > > issues with fonts and window damage redraws. Slashdot and a few other > > sites have their fonts all garbled, > > Sounds like bug 13104. > Yeah, using EXA instead of XAA got me around the font thing. Thanks for the help.
Why was this resolved as fixed? Probably related to one of the GLX visual reworks.
*** Bug 16718 has been marked as a duplicate of this bug. ***
I forgot about this bug, but it is fixed upstream. Mesa 7.1.* requires X server 1.5 to work correctly. I completely forgot about this bug though. Other bugs like this could be prevented by blocking mesa 7.1 and newer with xorg-server 1.4.2 and older. It is related to one of the GLX visuals rework.
Oops. Ignore my last comment. I thought this was a gentoo bug I had submitted. Closing as resolved upstream.
(In reply to comment #22) > Mesa 7.1.* requires X server 1.5 to work correctly. According to what? That Mesa 7.1 doesn't work with xserver < 1.5 is precisely what this bug report is about...
I did a bit of gdbing and here is what I noticed. In glx/x11/glxext.c, getVisualConfigs performs a GLXGetVisualConfigs request and then calls createConfigsFromProperties which calls __glXInitializeVisualConfigFromTags which parses the reply. Everything goes well at first, but on the very last property in the reply stream, the parser reads a spurious GLX_RED_SIZE item with value 0. And from then, everything goes down, since the DRI code does not understand why someone would like a R0G8B8 visual. If I overwrite the redBits field of the visual struct with 8, opengl applications seem to work fine. I have not yet looked why the reply stream is corrupted (?).
The following is a wild guess, since I haven't had time to compile and test a modified 1.4 server. It's only from a quick glance at the server code. As I mentioned in the previous comment, the GLX stream from the server is corrupted. And looking at the code of DoGetVisualsConfigs in the server GL/glx/glxcmds.c, it doesn't seem surprising. The function allocates a huge buffer on the stack, then it fills it with a few integers from the visual data, and finally it sends the whole buffer to the client. The client will then happily parse the data, including the uninitialized bytes from the buffer. In the server from master branch, the issue does not occur, since the server adds an end-of-stream token to the buffer after the visual data. Looking at the comment in the code, I'm not even sure this token was added on purpose. But at least, it prevents the client from failing its initialization. The fact that the failure only happens on x86-64 is pure luck: The uninitialized data on the stack just happens to crash the clients there, but it could also happen on other platforms. Note also that there is an obvious security issue (both in 1.4 and master): The server is leaking a big chunk of its stack private data to the client.
Isn't this a dupe of #13863? Length of the glx reply is simply larger than what the server fills in (though those zeros aren't really what should be in there, rather the multisample properties should be there - this is fixed in master)
You are right, this is the same as bug #13863. It's really unfortunate the patch from the bug-report wasn't applied. Anyway, the patch below is the patch I tested, and it does indeed fix glx applications that rely on mesa git when using xserver 1.4. diff --git a/GL/glx/glxcmds.c b/GL/glx/glxcmds.c index 900a347..3b1272b 100644 --- a/GL/glx/glxcmds.c +++ b/GL/glx/glxcmds.c @@ -992,6 +992,10 @@ int DoGetVisualConfigs(__GLXclientState *cl, unsigned screen, buf[p++] = GLX_TRANSPARENT_INDEX_VALUE; buf[p++] = modes->transparentIndex; + while (p < __GLX_TOTAL_CONFIG) { + buf[p++] = 0; + } + if ( do_swap ) { __GLX_SWAP_INT_ARRAY(buf, __GLX_TOTAL_CONFIG); }
Closing, this is fixed if you use proper combination of xserver and mesa.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.