Bug 7595 - Radeon 9250 DRI stops working with ATI 6.5.8.0 driver
Summary: Radeon 9250 DRI stops working with ATI 6.5.8.0 driver
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.0 (2005.12)
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Michel Dänzer
QA Contact:
URL: https://bugzilla.redhat.com/bugzilla/...
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2006-07-22 03:51 UTC by Chris Rankin
Modified: 2006-08-26 03:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg config file (3.00 KB, text/plain)
2006-07-22 03:54 UTC, Chris Rankin
no flags Details
Xorg log file (46.35 KB, text/plain)
2006-07-22 03:58 UTC, Chris Rankin
no flags Details
dmesg kernel log (18.82 KB, text/plain)
2006-07-22 14:16 UTC, Chris Rankin
no flags Details
Kernel log with broken ATI driver (19.31 KB, text/plain)
2006-07-23 05:52 UTC, Chris Rankin
no flags Details
Xorg log with broken ATI driver (45.89 KB, text/plain)
2006-07-23 05:53 UTC, Chris Rankin
no flags Details
Possible fix (582 bytes, patch)
2006-07-23 08:02 UTC, Michel Dänzer
no flags Details | Splinter Review
Handle u32 overflow in radeon_check_and_fixup_offset() (1.86 KB, patch)
2006-07-30 23:41 UTC, Michel Dänzer
no flags Details | Splinter Review
Handle u32 overflows in radeon_check_and_fixup_offset() (1.97 KB, patch)
2006-08-25 02:42 UTC, Michel Dänzer
no flags Details | Splinter Review

Description Chris Rankin 2006-07-22 03:51:23 UTC
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.)
Comment 1 Chris Rankin 2006-07-22 03:52:23 UTC
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>
Comment 2 Chris Rankin 2006-07-22 03:54:24 UTC
Created attachment 6301 [details]
Xorg config file
Comment 3 Chris Rankin 2006-07-22 03:58:08 UTC
Created attachment 6302 [details]
Xorg log file
Comment 4 Erik Andren 2006-07-22 08:25:03 UTC
Are you experiencing this problem with the 6.6.1 driver release?
Comment 5 Michel Dänzer 2006-07-22 08:37:52 UTC
Please also attach the full kernel output.

Also, which version of Mesa (in particular the r200 DRI driver) are you using?
Comment 6 Chris Rankin 2006-07-22 14:16:24 UTC
Created attachment 6305 [details]
dmesg kernel log

No DRI errors in this log - just everything else.
Comment 7 Chris Rankin 2006-07-22 14:24:11 UTC
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
Comment 8 Michel Dänzer 2006-07-23 04:23:39 UTC
(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.
Comment 9 Chris Rankin 2006-07-23 04:37:14 UTC
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.
Comment 10 Michel Dänzer 2006-07-23 04:57:05 UTC
(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.
Comment 11 Chris Rankin 2006-07-23 05:52:52 UTC
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.
Comment 12 Chris Rankin 2006-07-23 05:53:57 UTC
Created attachment 6312 [details]
Xorg log with broken ATI driver

Probably the same as attachment 6302 [details].
Comment 13 Michel Dänzer 2006-07-23 08:02:11 UTC
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.
Comment 14 Chris Rankin 2006-07-23 12:04:46 UTC
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.
Comment 15 Michel Dänzer 2006-07-25 02:00:59 UTC
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?
Comment 16 Chris Rankin 2006-07-30 15:51:08 UTC
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
Comment 17 Michel Dänzer 2006-07-30 23:41:33 UTC
Created attachment 6405 [details] [review]
Handle u32 overflow in radeon_check_and_fixup_offset()

Thanks, please try this patch.
Comment 18 Chris Rankin 2006-07-31 16:04:02 UTC
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?
Comment 19 Michel Dänzer 2006-08-01 05:27:05 UTC
(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).
Comment 20 Michel Dänzer 2006-08-25 02:42:50 UTC
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.
Comment 21 Chris Rankin 2006-08-25 14:43:38 UTC
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.
Comment 22 Michel Dänzer 2006-08-26 03:27:28 UTC
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.