RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Sat, 13 Dec 2003, Michel [ISO-8859-1] Dnzer wrote: On Sat, 2003-12-13 at 23:04, Fred Heitkamp wrote: Can someone explain why the business is in the source file? It's a merge conflict. (It's a good idea to check the output of cvs up for lines starting with a capital C for conflict) I deleted my xfree cvs and reacquired a new set of sources. The sources compiled fine and now my DRI is working. I got 1907 fps on my Radeon 8500 with glxgears. Still checking the stability issue. Hopefully that is resolved now too. Thanks for everyones help. I've appended the glxinfo output, if anyone is curious. Fred libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: busid is PCI:1:5:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports PCI:1:5:0 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_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read client glx vendor string: SGI client glx version string: 1.2 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_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_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_SGI_video_sync OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20030328 AGP 2x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 5.0.2 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_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, 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_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_object, GL_EXT_texture_lod_bias, 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_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_texture_rectangle, GL_NV_texgen_reflection, 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 glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess 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 . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Tue, 9 Dec 2003, Michel [ISO-8859-1] Dnzer wrote:
On Fri, 2003-12-05 at 13:11, Fred Heitkamp wrote:
I set the AGP mode to 2. Setting the mode to 2 seemed to allow X to run
continuously the longest without locking up. In fact I used mode 2 all
day and I don't believe X11 ever locked up. I still wasn't sure whether
the GL lib issue was a being a confuser, so I changed the mode back to 4.
X ran about 7 hours without locking up, essentially running with just a
XFCE terminal open with a tar verify scrolling all night and the
Xscreensaver running. When I logged in this morning and brought up
Mozilla, X locked-up a few seconds later. Lastly, I checked to see that
all the proper kernel modules were inserted, after learning that kernel
2.6.x is different than 2.4.x in respect to the DRI/AGP modules, but
glxinfo still shows DRI is not working.
So it was likely AGP.
Eventually the display locked up at mode 2 too, though it took a lot
longer. I have been trying to compile the latest CVS and am not having
success. Actually it compiled OK but I got this message from glxinfo:
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed
(/usr/X11R6/li
b/modules/dri/r200_dri.so: cannot open shared object file: No such file or
direc
tory)
libGL error: unable to find driver: r200_dri.so
name of display: :0.0
display: :0 screen: 0
direct rendering: No
I tried compiling with #define DriDrivers mga radeon r200
in my host.def file but the compile stops. Here is the code that makes it
stop. Can someone explain why the business is in the source file?
static void r200SetBuffer( GLcontext *ctx,
GLframebuffer *colorBuffer,
GLuint bufferBit )
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
r200_span.c
switch ( mode ) {
case GL_FRONT_LEFT:
===
switch ( bufferBit ) {
case FRONT_LEFT_BIT:
1.2
if ( rmesa-doPageFlip rmesa-sarea-pfCurrentPage == 1 ) {
rmesa-state.pixel.readOffset = rmesa-r200Screen-backOffset;
rmesa-state.pixel.readPitch = rmesa-r200Screen-backPitch;
rmesa-state.color.drawOffset = rmesa-r200Screen-backOffset;
(II) RADEON(0): Direct rendering enabled
This means the DRI is fine as far as the X server and the kernel are
concerned; does
LIBGL_DEBUG=verbose glxinfo
Fred
Error Loading Explorer.exe
You must reinstall Windows.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Wed, 3 Dec 2003, Andrew P. Lentvorski, Jr. wrote: On Wed, 3 Dec 2003, Alexander Stohr wrote: I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. It can also mean problems in DRI and OpenGL. I had to remove several of the screen savers from the random list because they would lock up my system quite reliably. You might want to check which specific screen savers are running when the system locks. I implemented some of the suggestions that folks on the list were kind enough to give and hopefully got a little closer to the core issue. I made sure that I did not have any old Mesa/GL libraries in the /usr/X11R6/lib directory. I set the AGP mode to 2. Setting the mode to 2 seemed to allow X to run continuously the longest without locking up. In fact I used mode 2 all day and I don't believe X11 ever locked up. I still wasn't sure whether the GL lib issue was a being a confuser, so I changed the mode back to 4. X ran about 7 hours without locking up, essentially running with just a XFCE terminal open with a tar verify scrolling all night and the Xscreensaver running. When I logged in this morning and brought up Mozilla, X locked-up a few seconds later. Lastly, I checked to see that all the proper kernel modules were inserted, after learning that kernel 2.6.x is different than 2.4.x in respect to the DRI/AGP modules, but glxinfo still shows DRI is not working. Here are some log snippets: (II) LoadModule: dri (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.3.99.16, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module drm (II) LoadModule: drm (II) Loading /usr/X11R6/lib/modules/linux/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.3.99.16, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: GLcore (II) Reloading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) LoadModule: record (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor=The XFree86 Project compiled for 4.3.99.16, module version = 1.13.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.2 snip drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created radeon driver at busid PCI:1:5:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0b51000 (II) RADEON(0): [drm] mapped SAREA 0xe0b51000 to 0x44276000 (II) RADEON(0): [drm] framebuffer handle = 0xf000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x1022/0x700c; Card 0x1002/0x514c] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xfc00 (II) RADEON(0): [agp] Ring mapped at 0x44278000 (II) RADEON(0): [agp] ring read ptr handle = 0xfc101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x44379000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xfc102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x4437a000 (II) RADEON(0): [agp] GART texture map handle = 0xfc302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x4457a000 (II) RADEON(0): [drm] register handle = 0xef00 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191) (II) RADEON(0): Reserved area from (0,1024) to (1280,1026) (II) RADEON(0): Largest offscreen area available: 1280 x 7165 (II) RADEON(0): Will use back buffer at offset 0x140 (II) RADEON(0): Will use depth buffer at offset 0x190 (II) RADEON(0): Will use 34816 kb for textures at offset 0x1e0 (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0):
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
maybe there is just a power save flaw, ACPI has been significantly reworked, and I think it's on by default now. ACPI BIOS implementations are also notoriously buggy. ACPI can also affect your IRQ routing etc, so if you're using it you might want to try turning it off and seeing what happens. Craig Ringer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
I suppose I could have a hardware problem, since my PC is a couple years old now. However, I can leave the same computer just running a 2.4.x kernel for days with no problems. Would the redesigned kernel 2.6.x bang the hardware so much more; going beyond that of kernel 2.4.x? It can be that a new kernel does make use of resources that were previousely ignored. in the past e.g. turning on fast writes on the AGP bus lead several systems to instable behaviour - the chipset claimed it supports that but when enabling this it all turned out to be of questionable use. maybe there is just a power save flaw, a problem with IRQ coding or something else that hits the system at a rather sporadic rate - it is hard to say what it is. sometimes only an analysis with quite advanced hard and software tools can shed a light on the root cause. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Wed, 3 Dec 2003, Alexander Stohr wrote: I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. having a machine frozen after several hours could mean a thermal problem. this can inlcude even overclocked CPUs or instable RAM or anything else on the bus or the grafics. I suppose I could have a hardware problem, since my PC is a couple years old now. However, I can leave the same computer just running a 2.4.x kernel for days with no problems. Would the redesigned kernel 2.6.x bang the hardware so much more; going beyond that of kernel 2.4.x? -Alex. Fred Error Loading Explorer.exe You must reinstall Windows. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
FH I suppose I could have a hardware problem, since my PC is a couple years FH old now. However, I can leave the same computer just running a 2.4.x FH kernel for days with no problems. HZ is 1000 by default in 2.6; the different scheduling might perhaps cause a deadlock somewhere. Can you try with a 2.6 kernel compiled with HZ being 100 and see whether you can reproduce the problem? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. having a machine frozen after several hours could mean a thermal problem. this can inlcude even overclocked CPUs or instable RAM or anything else on the bus or the grafics. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Wed, 3 Dec 2003, Alexander Stohr wrote: I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. It can also mean problems in DRI and OpenGL. I had to remove several of the screen savers from the random list because they would lock up my system quite reliably. You might want to check which specific screen savers are running when the system locks. -a ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Sat, 2003-11-29 at 21:03, Fred Heitkamp wrote: On Sat, 29 Nov 2003, Michel [ISO-8859-1] Dnzer wrote: On Fri, 2003-11-28 at 19:27, Fred Heitkamp wrote: name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 4.0.4 Current XFree86 CVS is based on Mesa 5.0.x, it seems to be picking up the wrong libGL? The libOSMesa libraries as of Nov 22 seems to be the following on my system. The OS stands for off-screen, it's unrelated. Start with the output of ldd `which glxinfo` | grep libGL.so (**) RADEON(0): Option AGPMode 4 Have you tried lower AGP modes? No but there doesn't seem to be a problem with the 2.4.x kernels running on mode 4. I will lower the mode and try disabling backing store and see what happens. [...] I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. But that was still at AGP 4x? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Sat, 29 Nov 2003, Michel [ISO-8859-1] Dnzer wrote: On Fri, 2003-11-28 at 19:27, Fred Heitkamp wrote: name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 4.0.4 Current XFree86 CVS is based on Mesa 5.0.x, it seems to be picking up the wrong libGL? The libOSMesa libraries as of Nov 22 seems to be the following on my system. -rw-r--r--1 root root 160 Nov 22 10:34 libOSMesa.a -rwxr-xr-x1 root root 809 Aug 31 00:24 libOSMesa.la lrwxrwxrwx1 root root 16 Nov 22 11:21 libOSMesa.so - libOSMesa.so.4.0 lrwxrwxrwx1 root root 16 Nov 29 13:24 libOSMesa.so.4 - libOSMesa.so.4.0 -rwxr-xr-x1 root root 1543615 Nov 22 10:34 libOSMesa.so.4.0 (**) RADEON(0): Option AGPMode 4 Have you tried lower AGP modes? No but there doesn't seem to be a problem with the 2.4.x kernels running on mode 4. I will lower the mode and try disabling backing store and see what happens. (**) RADEON(0): Option BackingStore (**) RADEON(0): Backing store enabled BTW, do you really want to use backing store? I doubt it causes your problems, but it may hurt performance for local clients. I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer Fred Error Loading Explorer.exe You must reinstall Windows. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Fri, 2003-11-28 at 19:27, Fred Heitkamp wrote: name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 4.0.4 Current XFree86 CVS is based on Mesa 5.0.x, it seems to be picking up the wrong libGL? (**) RADEON(0): Option AGPMode 4 Have you tried lower AGP modes? (**) RADEON(0): Option BackingStore (**) RADEON(0): Backing store enabled BTW, do you really want to use backing store? I doubt it causes your problems, but it may hurt performance for local clients. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
