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 : http://gatos.sourceforge.net/livid-gatos/2001-December/msg00117.html is probably the most relevent (same error as me w/ same consequences) here is another one : http://www.xfree86.org/pipermail/xpert/2002-February/015805.html 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: Always Steps to Reproduce: 1. run XFree86 4.2 stock redhat 7.3 w/ r128 chipset 2. 3. Actual Results: gibberish on screen non refresh of icons etc Expected Results: clean screen Additional info:
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.
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.
Turning DRI off doesn't help the console-switching problem. Sometimes while switching consoles, the system just hangs with nothing in the logs.
*** Bug 64747 has been marked as a duplicate of this bug. ***
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 :(
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.
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 hardware. 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.
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.
Created attachment 57204 [details] Working Xfree log
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
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 /usr/src/linux/drivers/char/drm/r128_state.c 1522,1529d1521 < 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 1533,1579c1525 < 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. 1581,1592c1527 < BEGIN_RING( 2 ); < RADEON_WAIT_UNTIL_3D_IDLE(); < 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;
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
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:
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.
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.
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.
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.
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.
jceklosk: 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.
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 bug report list, as well as the xpert mailing list. That parallelizes those looking into the issue, since it seems a lot of you are experiencing it.
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.
It would be extremely cool to finally see /etc/X11/XF86Config-4 attached to this bug report, along with XFree86.*.log (non-working one).
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?
Created attachment 59984 [details] Xfree log
Created attachment 59985 [details] XF config
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.
You are right as long as you can reproduce the lock-up at 1400x1050. Please, try.
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.
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.
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.
Created attachment 65507 [details] Patch the r128 fullscreen DMA video lockups
*** This bug has been marked as a duplicate of 68668 ***