Bug 198840 - Radeon 250 DRI has stopped working after recent update
Summary: Radeon 250 DRI has stopped working after recent update
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-13 23:11 UTC by Chris Rankin
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-23 20:16:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg configuration. (3.00 KB, application/octet-stream)
2006-07-13 23:11 UTC, Chris Rankin
no flags Details
Xorg log file (46.35 KB, text/plain)
2006-07-13 23:15 UTC, Chris Rankin
no flags Details

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.



Note You need to log in before you can comment on or make changes to this bug.