Bug 198840

Summary: Radeon 250 DRI has stopped working after recent update
Product: [Fedora] Fedora Reporter: Chris Rankin <rankincj>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: hdegoede, wtogami, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-23 20:16:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg configuration.
none
Xorg log file none

Description Chris Rankin 2006-07-13 23:11:34 UTC
Description of problem:
Any attempt to (say) launch an OpenGL screensaver now fails.

Version-Release number of selected component (if applicable):
xorg-x11-drv-ati-6.5.8.0-1

How reproducible:
All the time.

Steps to Reproduce:
1. Apply updated RPM, and reboot.
2. Launch /usr/libexec/xscreensaver/rubik

Actual results:
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


Expected results:
A rotating Rubik's cube.

Additional info:
This happens with either the stock 2.6.17.2 radeon.ko, drm.ko modules, or the
latest kernel modules from CVS. I have also tried both with and without

Option "AccelMethod" "EXA"

in xorg.conf, with no effect. (To be honest, I *hate* the EXA mode anyway - it
is S-O S-L-O-W!!!)

Comment 1 Chris Rankin 2006-07-13 23:11:35 UTC
Created attachment 132404 [details]
Xorg configuration.

Comment 2 Chris Rankin 2006-07-13 23:13:30 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 3 Chris Rankin 2006-07-13 23:15:19 UTC
Created attachment 132405 [details]
Xorg log file

Comment 4 Mike A. Harris 2006-07-25 06:16:19 UTC
Dave, did this PCI ID get removed from the kernel along with R300 too?


Comment 5 Chris Rankin 2006-07-25 20:41:05 UTC
What's the difference between this RPM and the "vanilla" 6.5.8.0 ATI driver?

Comment 6 Hans de Goede 2006-08-23 05:07:12 UTC
Could you try downloading and installing (not upgrading but installing) the
latest kernel from rawhide and see if that helps?


Comment 7 Chris Rankin 2006-08-23 20:16:00 UTC
Oops, I forgot to mention that I'd since contacted the Xorg people, who gave me
this patch against my Radeon DRI kernel module. The basic problem was that the
u32 fb_end variable was overflowing on my system, such that fb_start + fb_size = 
0.

diff -u -u -r1.72 radeon_state.c
--- drm/shared-core/radeon_state.c      24 May 2006 18:36:24 -0000      1.72
+++ drm/shared-core/radeon_state.c      23 Aug 2006 20:20:50 -0000
@@ -43,6 +43,10 @@
                                                    u32 * offset)
 {
        u32 off = *offset;
+       u32 fb_start = dev_priv->fb_location;
+       u32 fb_end = fb_start + dev_priv->fb_size - 1;
+       u32 gart_start = dev_priv->gart_vm_start;
+       u32 gart_end = gart_start + dev_priv->gart_size - 1;
        struct drm_radeon_driver_file_fields *radeon_priv;

        /* Hrm ... the story of the offset ... So this function converts
@@ -62,10 +66,8 @@
        /* First, the best case, the offset already lands in either the
         * framebuffer or the GART mapped space
         */
-       if ((off >= dev_priv->fb_location &&
-            off < (dev_priv->fb_location + dev_priv->fb_size)) ||
-           (off >= dev_priv->gart_vm_start &&
-            off < (dev_priv->gart_vm_start + dev_priv->gart_size)))
+       if ((off >= fb_start && off <= fb_end) ||
+           (off >= gart_start && off <= gart_end))
                return 0;

        /* Ok, that didn't happen... now check if we have a zero based
@@ -78,15 +80,12 @@
        }

        /* Finally, assume we aimed at a GART offset if beyond the fb */
-       if (off > (dev_priv->fb_location + dev_priv->fb_size))
-               off = off - (dev_priv->fb_location + dev_priv->fb_size) +
-                       dev_priv->gart_vm_start;
+       if (off > fb_end)
+               off = off - (fb_end + 1) + gart_start;

        /* Now recheck and fail if out of bounds */
-       if ((off >= dev_priv->fb_location &&
-            off < (dev_priv->fb_location + dev_priv->fb_size)) ||
-           (off >= dev_priv->gart_vm_start &&
-            off < (dev_priv->gart_vm_start + dev_priv->gart_size))) {
+       if ((off >= fb_start && off <= fb_end) ||
+           (off >= gart_start && off <= gart_end)) {
                DRM_DEBUG("offset fixed up to 0x%x\n", off);
                *offset = off;
                return 0;

Comment 8 Hans de Goede 2006-08-24 08:57:30 UTC
Good,

Can you verify that this is fixed by the rawhide kernel version? If not we
should incorperate this into the Fedora kernel so that this is fixed for other
users too before FC-6 gets released.