I have already raised this bug in Fedora Core 5's bugzilla as Bug 198840. However, I am concerned that it hasn't been seen by the relevant people. With the ATI 6.5.8.0 driver, any attempt to use the DRI fails. The following errors are written to the terminal: drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) And the following errors appear in the kernel log: [drm:radeon_check_and_fixup_packets] *ERROR* Invalid depth buffer offset [drm:radeon_emit_packets] *ERROR* Packet verification failed [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed I have reverted to the ATI 6.5.7.3 driver instead, which works OK. (Note that XAA acceleration is much better with this driver than the new EXA acceleration. With EXA, there is a noticeable pause before windows contents are redrawn when you - say - switch desktops, close apps etc.)
Video card's PCI information: 01:00.0 0300: 1002:5961 (rev 01) Subsystem: 174b:7c13 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f0000000 (32-bit, prefetchable) [size=128M] I/O ports at ec00 [size=256] Memory at ff8f0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff800000 [disabled] [size=128K] Capabilities: <access denied> 01:00.1 0380: 1002:5941 (rev 01) Subsystem: 174b:7c12 Flags: bus master, 66MHz, medium devsel, latency 64 Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at ff8e0000 (32-bit, non-prefetchable) [size=64K] Capabilities: <access denied>
Created attachment 6301 [details] Xorg config file
Created attachment 6302 [details] Xorg log file
Are you experiencing this problem with the 6.6.1 driver release?
Please also attach the full kernel output. Also, which version of Mesa (in particular the r200 DRI driver) are you using?
Created attachment 6305 [details] dmesg kernel log No DRI errors in this log - just everything else.
As I said, this is Fedora Core 5, so the only drivers I have tried are the ones provided as RPMs. In other words, no I haven't tried driver v6.6.1. Here is the output from glxinfo, containing the Mesa version (6.4.2): $ 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_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, 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_EXT_texture_from_drawable, 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 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_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/SSE2 TCL OpenGL version string: 1.3 Mesa 6.4.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_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_NV_vertex_program, 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 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 Slow 0x4b 32 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None
(In reply to comment #6) > > No DRI errors in this log - just everything else. Thanks, but is this from running with xf86-video-ati 6.5.8? If not, please attach the kernel output from that. Also, it seems weird that this says the radeon DRM is version 1.25 whereas the attached X log file says it's 1.24. There seems to be an inconsistency. Last but not least, it would be great if you could try Mesa 6.5 or CVS.
The inconsistency is probably because I've tried with both the native drm/radeon kernel modules and with the modules that come from DRI CVS, with *exactly* the same result each time. If it had worked with one and not the other then I wouldn't have needed to raise a bug report. I'm not sure what you expect to see in the kernel's dmesg log, regardless of which ATI driver I'm using, either. The only remotely relevant messages I could see there were these: [drm] Initialized drm 1.0.1 20051102 ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 17 [drm] Initialized radeon 1.25.0 20060524 on minor 0: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode [drm] Setting GART location based on old memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs And these were all from the AGP, DRM and Radeon modules. As for trying CVS, can you provide me with relevant RPMs or SRPMs please? Thanks.
(In reply to comment #9) > The only remotely relevant messages I could see there were these: [...] > [drm] Setting GART location based on old memory map Just as one example, I've seen reports where this line also said 'old memory map', even though the X log file showed that it should have used the new memory map. Such an inconsistency might cause problems like the one you reported. In general, it's best to always provide full files instead of just what seems relevant, because quite often it's not immediately clear to bug reporters or even triagers what's really relevant. > As for trying CVS, can you provide me with relevant RPMs or SRPMs please? No, sorry.
Created attachment 6311 [details] Kernel log with broken ATI driver It looks like the GART is using the new memory map with the 6.5.8.0 driver.
Created attachment 6312 [details] Xorg log with broken ATI driver Probably the same as attachment 6302 [details].
Created attachment 6315 [details] [review] Possible fix Thank you for providing the additional information. Please try this patch for the DRM; it looks like it doesn't handle the case correctly where the framebuffer lies at the very end of the card's address space.
I am confused. What does this patch actually change? OLD: dev_priv->fb_size = ((A & 0xffff0000u) + 0x10000) - dev_priv->fb_location; NEW: dev_priv->fb_size = (A & 0xffff0000u) - dev_priv->fb_location + 0x10000; Both original and patched radeon.ko modules have identical MD5 hashes.
I was thinking the wraparound when adding 0x10000 to 0xffff0000 might cause problems, but on second thought you're right, it shouldn't. Can you try adding debugging output in the DRM around radeon_check_and_fixup_packets to see the values that are causing the check to fail?
Hi, I placed the following printk() lines in radeon_check_and_fixup_offset(): /* Ok, that didn't happen... now check if we have a zero based * offset that fits in the framebuffer + gart space, apply the * magic offset we get from SETPARAM or calculated from fb_location */ if (off < (dev_priv->fb_size + dev_priv->gart_size)) { radeon_priv = filp_priv->driver_priv; printk(KERN_DEBUG " Old off=0x%x, ", off); off += radeon_priv->radeon_fb_delta; printk(KERN_DEBUG " New off=0x%x\n", off); } ... printk(KERN_DEBUG " off=0x%x, fb_location=0x%x, fb_size=0x%x, " " gart_vm_start=0x%x, gart_size=0x%x\n", off, dev_priv->fb_location, dev_priv->fb_size, dev_priv->gart_vm_start, dev_priv->gart_size); return DRM_ERR(EINVAL); } and this is what they said for the broken driver: [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs off=0xd1900000, fb_location=0xf0000000, fb_size=0x10000000, gart_vm_start=0xe0000000, gart_size=0x800000 [drm:radeon_check_and_fixup_packets] *ERROR* Invalid depth buffer offset [drm:radeon_emit_packets] *ERROR* Packet verification failed [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed
Created attachment 6405 [details] [review] Handle u32 overflow in radeon_check_and_fixup_offset() Thanks, please try this patch.
Aha! That patch seems to have done the trick! However, I am slightly confused how because off = 0xd1900000 and fb_location = 0xf000000. Doesn't this imply that (off < fb_start), which would violate one of the bounds-checks?
(In reply to comment #18) > Aha! That patch seems to have done the trick! Thanks for testing it, going to commit something along these lines and push soon. > However, I am slightly confused how because off = 0xd1900000 and fb_location = 0xf000000. Doesn't this imply > that (off < fb_start), which would violate one of the bounds-checks? I was initially confused by the value 0xd1900000 as well, but then I realized it was the result of modifying off to try and account for old clients. off was within range at the beginning, but the checks failed due to the overflow (dev_priv->fb_location + dev_priv->fb_size == 0).
Created attachment 6682 [details] [review] Handle u32 overflows in radeon_check_and_fixup_offset() Please verify that this patch works for you as well. It fixes another potential u32 overflow in the fixup code.
Yes, that new patch works too. (u32 off -> u64 off?) I've since upgraded to XOrg 7.1 and the 6.6.1 ATI driver, but since the underlying problem was using the "GART location based on new memory map", I don't think that should have affected anything.
Thanks, pushed to 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.