Re: [r300] [patches] debugging lockups
On Fri, 3 Jun 2005 14:57:37 +0200 Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Friday 03 June 2005 10:28, Aapo Tahkola wrote: > > > On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: > > >> Aapo Tahkola wrote: > > >> > I did some figuring on the CB_DPATH problem. > > >> > After little testing it turns out that the lock up with > > >> > progs/demos/isosurf goes away when the pacifier sequences are applied > > >> to > > >> > clearbuffer. > > >> > > > >> > Im starting to think that this sequence is needed whenever > overwriting > > >> > certain states rather than whenever 3d operation begins and ends. > > > > > > Perhaps. I don't think it's just the pacifier sequence, though. I've > been > > > running applications with RADEON_DEBUG=sync, which causes idle calls > > > between cmdbuf calls, and I've been seeing lockups where the read > pointer > > > sits after the beginning of what cmdbuf emits and long before the first > > > rendering commands. > > > > I dont know if packet3 was issued before since I tweaked isosurf to dump > > each frame portion of RADEON_DEBUG info into files using freopen. > > But "DISCARD BUF" was really the only key difference in these logs. > > > > > This indicates that at least one lockup is cause by > > > one > > > of the following: > > > - intial pacifier sequence in r300_cp_cmdbuf > > > - emission of cliprects or > > Cliprects seem to be little off scale when compairing progs/samples/logo > > against software rendering. > > Perhaps near plane is negative ? > > > > > - initial unchecked_state commands sent by the client > > This is bad as you can see from first frame drawn by texwrap... > > Sticking: > > r300_setup_textures(ctx); > > r300_setup_rs_unit(ctx); > > > > r300SetupVertexShader(rmesa); > > r300SetupPixelShader(rmesa); > > or resethwstate to r300_run_vb_render should fix it. > > I'm not sure we're talking about the same thing here. This happens when the > client sends a command buffer where all the state blocks (from r300->hw) > are sent to the hardware *anyway*. It's actually the *order* of emission > (e.g. the order in which insert_at_tail is called for state bits) that can > make a difference. The thing is, while the order definitely *does* affect > the probability of lockups, lockups will not go away completely even if I > use the exact same order that fglrx uses. So I'm beginning to believe that > we can't trust radeon_do_cp_idle to completely idle the chip, or that > whatever is wrong is pretty fundamentally wrong (some wrong bits in how the > memory is configured?). Remember that because of reemiting, those states arent in perfect order. Fortunately taking out lines 206-212 of r300_context.c doesnt seem to have any side effects on rv350. -- Aapo Tahkola --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Friday 03 June 2005 00:25, Benjamin Herrenschmidt wrote: > > > > > > You guys seem to be getting closer... > > > When I had X + xfce4 + quake3 running (with this patch + > > > patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X > > > locked up within 2 minutes. > > > However, X + quake3 (no window manager), I went thirty minutes before > > > my first problem. Quake3Arena crashed, and X quit. There was some > > > message on the terminal about radeon_wait and "IRQ 16". > > > > > > Here it is: > > > > radeonWaitIrq: drmRadeonIrqWait: -16 > > Have you tried David Airlie's or my latest DRM IRQ fixes ? It is unlikely that the problem is related, especially when X locks up, too. If you see this message and X is continuing to run fine (i.e. no complete lockup), you should indeed consider looking at the IRQ code. However, if X locks up completely, the most likely reason for this message is simply that the R300 locks up before it encounters the IRQ EMIT command in the ring buffer. It just happens then that the DRI client waits for an IRQ instead of busy-looping for the chip to idle. So it is perfectly likely that this message appears even when the IRQ handling code is working fine. Nevertheless, testing that patch can't hurt. cu, Nicolai pgp5KDqFMYqUZ.pgp Description: PGP signature
Re: [r300] [patches] debugging lockups
On Friday 03 June 2005 10:28, Aapo Tahkola wrote: > > On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: > >> Aapo Tahkola wrote: > >> > I did some figuring on the CB_DPATH problem. > >> > After little testing it turns out that the lock up with > >> > progs/demos/isosurf goes away when the pacifier sequences are applied > >> to > >> > clearbuffer. > >> > > >> > Im starting to think that this sequence is needed whenever overwriting > >> > certain states rather than whenever 3d operation begins and ends. > > > > Perhaps. I don't think it's just the pacifier sequence, though. I've been > > running applications with RADEON_DEBUG=sync, which causes idle calls > > between cmdbuf calls, and I've been seeing lockups where the read pointer > > sits after the beginning of what cmdbuf emits and long before the first > > rendering commands. > > I dont know if packet3 was issued before since I tweaked isosurf to dump > each frame portion of RADEON_DEBUG info into files using freopen. > But "DISCARD BUF" was really the only key difference in these logs. > > > This indicates that at least one lockup is cause by > > one > > of the following: > > - intial pacifier sequence in r300_cp_cmdbuf > > - emission of cliprects or > Cliprects seem to be little off scale when compairing progs/samples/logo > against software rendering. > Perhaps near plane is negative ? > > > - initial unchecked_state commands sent by the client > This is bad as you can see from first frame drawn by texwrap... > Sticking: > r300_setup_textures(ctx); > r300_setup_rs_unit(ctx); > > r300SetupVertexShader(rmesa); > r300SetupPixelShader(rmesa); > or resethwstate to r300_run_vb_render should fix it. I'm not sure we're talking about the same thing here. This happens when the client sends a command buffer where all the state blocks (from r300->hw) are sent to the hardware *anyway*. It's actually the *order* of emission (e.g. the order in which insert_at_tail is called for state bits) that can make a difference. The thing is, while the order definitely *does* affect the probability of lockups, lockups will not go away completely even if I use the exact same order that fglrx uses. So I'm beginning to believe that we can't trust radeon_do_cp_idle to completely idle the chip, or that whatever is wrong is pretty fundamentally wrong (some wrong bits in how the memory is configured?). cu, Nicolai pgprQzzlJLfsA.pgp Description: PGP signature
[Bug 3460] dri-20050601 [r200] americas army crash after start
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3460 --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 05:28 --- I forgot to put dmesg: [drm] Initialized drm 1.0.0 20040925 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc Radeon R200 QL [Radeon 8500 LE] [drm] Loading R200 Microcode -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3460] dri-20050601 [r200] americas army crash after start
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3460 --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 05:22 --- I have build drm and mesa from source. I run some tests and I get this: test:/Mesa/progs/tests# ./arbfptest1 program 0: glGetError = 1280 errorpos: 11 !ARBfp1.0 TEMP R0, R test:/Mesa/progs/tests# ./arbfptexture: Error: GL_ARB_fragment_program not supported! test:/Mesa/progs/tests# ./arbvptest1 glGetError = 0 glGetError = 0 glGetError = 0 glGetError = 0 test:/Mesa/progs/tests# ./crossbar Sorry, this program requires GL_ARB_multitexture and either GL_ARB_texture_env_combine or GL_EXT_texture_env_combine (or OpenGL 1.3). Either GL_ARB_texture_env_crossbar or GL_NV_texture_env_combine4 (or OpenGL 1.4) are also required. Some tests runs fine: ./antialias ./bufferobj // // Tests say that I don't have some GL librarys. But glxinfo says: server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig 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_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 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_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.3 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_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 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_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, 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 glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess / So something is wrong. I hope you will find out how to fix this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- _
Re: [r300] [patches] debugging lockups
> On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: >> Aapo Tahkola wrote: >> > I did some figuring on the CB_DPATH problem. >> > After little testing it turns out that the lock up with >> > progs/demos/isosurf goes away when the pacifier sequences are applied >> to >> > clearbuffer. >> > >> > Im starting to think that this sequence is needed whenever overwriting >> > certain states rather than whenever 3d operation begins and ends. > > Perhaps. I don't think it's just the pacifier sequence, though. I've been > running applications with RADEON_DEBUG=sync, which causes idle calls > between cmdbuf calls, and I've been seeing lockups where the read pointer > sits after the beginning of what cmdbuf emits and long before the first > rendering commands. I dont know if packet3 was issued before since I tweaked isosurf to dump each frame portion of RADEON_DEBUG info into files using freopen. But "DISCARD BUF" was really the only key difference in these logs. > This indicates that at least one lockup is cause by > one > of the following: > - intial pacifier sequence in r300_cp_cmdbuf > - emission of cliprects or Cliprects seem to be little off scale when compairing progs/samples/logo against software rendering. Perhaps near plane is negative ? > - initial unchecked_state commands sent by the client This is bad as you can see from first frame drawn by texwrap... Sticking: r300_setup_textures(ctx); r300_setup_rs_unit(ctx); r300SetupVertexShader(rmesa); r300SetupPixelShader(rmesa); or resethwstate to r300_run_vb_render should fix it. -- Aapo Tahkola --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
