Bug 64503 - DRI /r128 bug in Xfree86 4.2
DRI /r128 bug in Xfree86 4.2
Status: CLOSED DUPLICATE of bug 68668
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: 64747 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-05-06 17:22 EDT by Need Real Name
Modified: 2007-04-18 12:42 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-15 22:59:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Working Xfree log (30.79 KB, text/plain)
2002-05-13 20:28 EDT, Joe Ceklosky
no flags Details
Xfree log (30.51 KB, text/plain)
2002-06-06 22:50 EDT, Joe Ceklosky
no flags Details
XF config (3.69 KB, text/plain)
2002-06-06 22:50 EDT, Joe Ceklosky
no flags Details
Patch the r128 fullscreen DMA video lockups (3.22 KB, patch)
2002-07-15 22:59 EDT, Joe Ceklosky
no flags Details | Diff

  None (edit)
Description Need Real Name 2002-05-06 17:22:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux)

Description of problem:
This is a new bug in Xfree86 4.2 that I had not seen in the older redhat Xfree86
in /var/log/messages the following error message shows up :

May  6 15:15:38 bloosqr kernel: [drm:r128_cce_indirect] *ERROR* process 1224 using buffer owned by 0
May  6 15:15:40 bloosqr last message repeated 40 times

and the kdm screen does not refresh properly and instead has
gibberish on it (though resetting X fixes this).

I did a bit of google searching and noticed a few other people
seem to have this same issue at some point in the past :


is probably the most relevent (same error as me w/ same consequences)

here is another one :


The system I am testing this on is a dell5000e laptop. This has
the r128 mobility chip w/ 16 mb ram and a 1400x1050 screen. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run XFree86 4.2 stock redhat 7.3 w/ r128 chipset

Actual Results:  gibberish on screen non refresh of icons etc

Expected Results:  clean screen

Additional info:
Comment 1 Joe Ceklosky 2002-05-09 08:10:33 EDT
I have the same problem with an laptop which uses the ATI Rage 128 M3 chipset.
The DRI stuff in 4.2.0 appears to be messed up for some of the ATI cards.
To get around this, disable DRI support in the X configuration.
Comment 2 Miloslav Trmac 2002-05-10 10:44:12 EDT
Happens for me too, not in RHL 7.2. Additional symptoms: switching between 
console and X takes very long (between 10 seconds and 60), part of the time 
mouse cursor moves but that's all.

Can this bug be marked high priority, please? It's quite a serious regression 
and just Not Right (tm) when the supposedly-uber-stable OS crashes about as 
often as Win95 does.
Comment 3 Miloslav Trmac 2002-05-13 11:39:22 EDT
Turning DRI off doesn't help the console-switching problem. Sometimes while 
switching consoles, the system just hangs with nothing in the logs.
Comment 4 Miloslav Trmac 2002-05-13 11:42:21 EDT
*** Bug 64747 has been marked as a duplicate of this bug. ***
Comment 5 Joe Ceklosky 2002-05-13 12:48:18 EDT
I compiled the latest CVS Xfree86 and will test with that.  It appears
that they are doing a lot of work in the ATI world to support the R128 and
the newer Radeon cards.  

The only solution we have is to downgrade and install Xfree 4.1 from RH 7.1 :(

Comment 6 Joe Ceklosky 2002-05-13 20:02:37 EDT
I did a little digging around and with the CVS Xfree and  Xfree 4.2 in Redhat
7.3.  I changed the Driver from "r128" to "ati" and things appear to be FINE.
Everyone with this problem, please try this and see what happens.  DRI and
console/graphic switches are A-OK.  It looks like all of the ATI drivers have
been folded into the "ati" driver.
Comment 7 Mike A. Harris 2002-05-13 20:19:23 EDT
Your hypothesis above is incorrect.  There are three ATI video drivers
present in XFree86.  They are:  ati, r128, radeon

The "radeon" driver is for all ATI Radeon, Radeon mobility boards based on
the R100, RV100, R200, RV200 chipsets.  This driver only supports Radeon,
and will not function with non-Radeon hardware.

The "r128" driver is for all ATI Rage 128 chipsets, including Rage 128
Mobility M3/M4, and all variants of Rage 128.  It only supports r128
chips and does not support Radeon or Mach64 or any other hardware.

The "ati" driver is for ATI Mach64 based chipsets, and various miscellaneous
older ATI boards.  This driver does not support any Rage 128 or Radeon

Each of these three drivers is specific to the chipset family they were
written for, and does not support hardware outside that family.  The drivers
have also been made "smart".  This means if you misconfigure the wrong ATI
driver, such as using "radeon" driver when you really have a Rage 128 board,
the driver recognizes the r128 chip on your card, and realizes it is not
a Radeon, then unloads the radeon driver and reloads the proper (r128)
driver.  Likewise, if one uses the "ati" driver, and has a r128 board or
a Radeon board, the "ati" driver will autodetect this, abort and load
the proper driver for the board you do have.

You can see this in motion, by purposefully configuring the wrong driver,
then starting up XFree86 and examining the X server log.  You'll see
that no matter what driver you load, if you have an r128, it will use
the r128 driver.  One should _always_ choose the _proper_ driver however
regardless, since there are some cases in which the autodetection can
fail and a crash can result, or some other problem, and there are no
benefits to choosing the wrong driver.

So.. I can assure you that the ATI drivers have not at all been folded
into one driver.  If you have a Rage 128, and have chosen the "ati" driver,
and it appears to work, you're really still using the "r128" driver, and
just experiencing some fluke.  You can examine your log file to confirm
that this is indeed the case.

Comment 8 Joe Ceklosky 2002-05-13 20:27:01 EDT
After just looking at the Xfree log, yes it uses the r128 driver, but it
works correctly when I use "ati" instead of "r128" in th xconfig.   I have
attached my log as well.
Comment 9 Joe Ceklosky 2002-05-13 20:28:29 EDT
Created attachment 57204 [details]
Working Xfree log
Comment 10 Joe Ceklosky 2002-05-13 20:49:14 EDT
Sorry for all the nonsense.  I just located what I think might be a problem with
Xfree86 4.2 on Redhat 7.3 and the r128 driver.  Everything worked fine until I
added KDE 3.0 into the mix.  Now I am seeing TONS of the r128_cce_indirect
errors in the kernel logs
Comment 11 Joe Ceklosky 2002-05-13 23:55:34 EDT
Tracking this down some more, the Redhat 7.3 linux-2.4.18-3 kernel might be using
the wrong DRM code for the r128.  I diff'ed r128_state.c in linux-2.4.18-3 and
the stock 2.4.18 kernel and noticed the following differences, see below.
The stock 2.4.18 disables the code in the function r128_cce_indirect, saying
this is NOT supported yet

diff /usr/src/linux-2.4.18-3/drivers/char/drm/r128_state.c
<       drm_r128_private_t *dev_priv = dev->dev_private;
<       drm_device_dma_t *dma = dev->dma;
<       drm_buf_t *buf;
<       drm_r128_buf_priv_t *buf_priv;
<       drm_r128_indirect_t indirect;
< #if 0
<       RING_LOCALS;
< #endif
<       if ( !dev_priv ) {
<               DRM_ERROR( "%s called with no initialization\n", __FUNCTION__ );
<               return -EINVAL;
<       }
<       if ( copy_from_user( &indirect, (drm_r128_indirect_t *)arg,
<                            sizeof(indirect) ) )
<               return -EFAULT;
<       DRM_DEBUG( "indirect: idx=%d s=%d e=%d d=%d\n",
<                  indirect.idx, indirect.start,
<                  indirect.end, indirect.discard );
<       if ( indirect.idx < 0 || indirect.idx >= dma->buf_count ) {
<               DRM_ERROR( "buffer index %d (of %d max)\n",
<                          indirect.idx, dma->buf_count - 1 );
<               return -EINVAL;
<       }
<       buf = dma->buflist[indirect.idx];
<       buf_priv = buf->dev_private;
<       if ( buf->pid != current->pid ) {
<               DRM_ERROR( "process %d using buffer owned by %d\n",
<                          current->pid, buf->pid );
<               return -EINVAL;
<       }
<       if ( buf->pending ) {
<               DRM_ERROR( "sending pending buffer %d\n", indirect.idx );
<               return -EINVAL;
<       }
<       if ( indirect.start < buf->used ) {
<               DRM_ERROR( "reusing indirect: start=0x%x actual=0x%x\n",
<                          indirect.start, buf->used );
<               return -EINVAL;
<       }
<       RING_SPACE_TEST_WITH_RETURN( dev_priv );
<       VB_AGE_TEST_WITH_RETURN( dev_priv );
<       buf->used = indirect.end;
<       buf_priv->discard = indirect.discard;
< #if 0
<       /* Wait for the 3D stream to idle before the indirect buffer
<        * containing 2D acceleration commands is processed.
>       /* Indirect buffer firing is not supported at this time.
<       BEGIN_RING( 2 );
<       ADVANCE_RING();
< #endif
<       /* Dispatch the indirect buffer full of commands from the
<        * X server.  This is insecure and is thus only available to
<        * privileged clients.
<        */
<       r128_cce_dispatch_indirect( dev, buf, indirect.start, indirect.end );
<       return 0;
>       return -EINVAL;
Comment 12 Tom Diehl 2002-05-18 01:48:05 EDT
Ok I just want to say I am having the same problem. Same error in the log as 
the original poster and random garbage on the screen. Also If I run an ncurses 
program like ntsysv all of the borders are garbage. I can still for the most 
part read the text though. All was well until the upgrade from 7.2-> 7.3
Comment 13 Joe Ceklosky 2002-05-29 21:01:12 EDT
I tested Xfree-4.2.0-50.3 from rawhide on Redhat 7.3.  It works for the most
part , but I had to force install it because it was looking for a new GCC.
Items that don't work:
Comment 14 Joe Ceklosky 2002-05-29 21:03:11 EDT
I tested Xfree-4.2.0-50.3 from rawhide on Redhat 7.3.  It works for the most
part, but I had to force install it because it was looking for a new GCC.
Items that don't work:
  Full Screen video playing using XINE (locks up machine, non-full screen is OK)
  Bleed through display issues when XINE is on the screen (happens after a
return from suspend I think)
  XVideo does not survive a suspend, XINE must be restarted then all is OK.

Comment 15 Joe Ceklosky 2002-05-30 11:25:20 EDT
I did additional testing with XF 4.2.0-50.3 on RH 7.3 and here is what I see:

   -Xvideo does NOT work at full screen, locks up the machine SOLID

   -Any application using Xvideo at suspend time and resume will break Xvideo.
    If you kill and then restart the application using Xvideo, you get 
    the video picture bleeding through other windows on the screen

We have progress.  This is with kernel RH 2.4.18-3.
Comment 16 Joe Ceklosky 2002-06-03 15:54:46 EDT
mharris, I have yet to test with Xfree-4.2.0-50.10 to see if this clears the
remaining issues DGA.  But I recently noticed THREE Xfree86 update that might be
related to the remaining issues.  Please check the Xfree CVS for the updates to
(r128_dga.c, radeon.h, and radeon_dga.c).  These updates address DGA issues
which I am still seeing with Xfree-4.2.0-50.3.  I checked Xfree-4.2.0-50.10 and
those patches are not included.  I could be totally wrong, but it's worth a try.
Comment 17 Need Real Name 2002-06-06 01:43:04 EDT
I have similar problems. playing mpeg files causes the display 
and keyboard to lock up completely. The mouse can move, but it cannot do anything.
Cannot even restart X, cannot get a 
console prompt (Ctrl-Alt-F1), the only way out is the reset button.
I looked at loaded modules, agpgart is loaded along with r128.
Comment 18 Need Real Name 2002-06-06 03:09:42 EDT
I just tried the XFree-4.2.0-50.10 from the RawHide distribution. Still Xv
problems. Also replaced the drm stuff with the latest CVS snapshot from
dri.sourceforge.net. No success. Replacing the r128 drivers with the drivers
from Gatos (experimental 11), did not work either.

X continious to hang. It's only X that hangs. When the system hangs I just do a
remote login to my notebook and kill X and the application using Xv (in my case
Xine) and everything runs fine again after restarting X.
Comment 19 Mike A. Harris 2002-06-06 03:39:22 EDT
jceklosk@voicenet.com:  in response to posted diff from 2002-05-13 23:55:34

The stock Linus Torvalds kernel DRM code is for XFree86 4.1.0, and will
NOT work with XFree86 4.2.0.  The new DRM did not get merged with Linus's
kernel for reasons that are outside of the scope of this bug report.
However, diffing with Linus' DRM is not useful.  Those people using Linus
kernels, or kernels from elsewhere will have broken buggy DRM, or no
DRM at all unless they compile DRM from XFree86 4.2.0 source code.

I just wanted to clarify that one issue first, so you realize why our DRM
is different.  Our DRM is the correct one.
Comment 20 Mike A. Harris 2002-06-06 03:42:34 EDT
As for the remainder of comments about testing rawhide XFree86... the results
you'll see are likely to be the same.  No part of the code has changed with
respect to the r128 driver since 7.3.

I recommend also reporting this problem to XFree86.org by way of both
the xfree86@xfree86.org bug report list, as well as the xpert@xfree86.org
mailing list.  That parallelizes those looking into the issue, since it
seems a lot of you are experiencing it.
Comment 21 Joe Ceklosky 2002-06-06 10:01:37 EDT
I know the RH 2.4.18-3 kernel includes the correct DRM kernel code.
I updated the DRM code in 2.4.18 (STOCK) to the correct DRM code for Xfree 4.2.0
directly from the DRI website, so that's in SYNC.
I am in the process of pulling the latest Xfree86 CVS code and testing it on RHG
7.3 with a r128 based laptop.  The Xfree people will require this is done before
posting to the news groups.
Comment 22 Alexei Podtelezhnikov 2002-06-06 19:47:47 EDT
It would be extremely cool to finally see /etc/X11/XF86Config-4 attached to this
bug report, along with XFree86.*.log (non-working one).
Comment 23 Alexei Podtelezhnikov 2002-06-06 20:09:24 EDT
Also, your resolution is 1024x768x16bpp, while the prescribed resolution for
this laptop is 1400x1050. And they mean it, I had lock-ups on console-switching
because of this with XF86-4.1.0 of RH-7.2. Somehow, in the earlier attached log
only 8Mb of 16Mb assigned for the normal use. Is that intended, why?
Comment 24 Joe Ceklosky 2002-06-06 22:50:03 EDT
Created attachment 59984 [details]
Xfree log
Comment 25 Joe Ceklosky 2002-06-06 22:50:38 EDT
Created attachment 59985 [details]
XF config
Comment 26 Joe Ceklosky 2002-06-06 22:51:43 EDT
My laptop only has a 14.1, so I am at 1024x768 with 16 bit color. I have
attached the log and config file.  The doubt the config has anything to do with
the full screen video lockups.  XFree86 4.1.0 works perfectly on this laptop.
I think something got borken in the r128 drivers and Xfree 4.2.0.
Comment 27 Alexei Podtelezhnikov 2002-06-07 17:55:00 EDT
You are right as long as you can reproduce the lock-up at 1400x1050. Please, 
Comment 28 Joe Ceklosky 2002-06-17 20:02:47 EDT
All, I have tested the r128 driver with all of the patches from Michel Ddnzer
installed on top of the Xfree 4.2.50-17 SRPMS from rawhide.  All of the problems
I experienced are gone.  Michel's fixes included (indirect buffer, set to NULL,
RH already had this), but the r128 and radeon default DMA copies for XVideo
(default to OFF) are missing.  Mharris, please pull these from the Xfree CVS.
Comment 29 Need Real Name 2002-06-20 05:44:28 EDT
I just installed the lastest GATOS drivers from CVS over XFree86-4.2.0-50.17
from Rawhide. Xv seems to work fine now. I did some small DRI test and also this
seems to work fine. I only have some problems switching to a text console and
back. When I do that, I get vertical lines at the top of the screen and on the
windows with Xv apps. But these disappear after a few seconds.
Comment 30 Joe Ceklosky 2002-07-15 22:58:23 EDT
mharris, I have created a patch for the r128 fullscreen video locks.  The acutal
patch to the Xfree86 code was created by Michel Danzer.  I created diffs for it
based on Redhat's Xfree 4.2.0-52 code baseline.  Apply this patch file AFTER all
other r128 patches have been run.  Patch is attached directly after this.

Comment 31 Joe Ceklosky 2002-07-15 22:59:26 EDT
Created attachment 65507 [details]
Patch the r128 fullscreen DMA video lockups
Comment 32 Mike A. Harris 2002-07-19 06:32:29 EDT

*** This bug has been marked as a duplicate of 68668 ***

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