Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dnzer wrote: [ I assume you meant to follow up to the list as well ] yes it is possible I failed to do so. The first one definitely wasn't correct. A process of pid 0 doesn't exist, but it has been handled as if it existed. The test ( buf-pid != current-pid ) isn't there for fun. The pid field of the buffer must contain the current process' pid. Yes, exactly. But this test fails if buf-pid == 0, which is wrong. Hence I added this test. See added, not deleted or replaced Looking at r128_freelist_get(), ( buf-pid == 0 ) means the buffer is free, i.e. not supposed to be in use by any process. Yes thats exactly what I'm talking about, this isn't tested though in other places. Obviously _something_ related to it is broken, but does that mean the pending field shouldn't be used at all Definitely, that's why I said my patch is most probably incorrect, but it solved my problems nevertheless (at least I think so). Basically I am too stupid to fix it correctly so I'm just curing the symptoms. After digging around the code a bit, my current theory is that the indirect buffer is incorrectly reused after the start of a new server generation. I too think this is the most probable cause. The only difference I see in the radeon driver (which I assume doesn't have the same problem?) Well, noone reported it so no idea. is in the LeaveServer() function, where it releases the indirect buffer. Can you try if that fixes the problem? Another idea is to set info-indirectBuffer to NULL in R128CCEAccelInit(). Sounds reasonable, I'll try it. I hope I'll be around on tomorrows irc meeting, we can try stuff in realtime then :-) Please test these ideas, hope one of them works. Sure dude. Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- 0 and 1. Now what could be so hard about that? msg02553/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dnzer wrote:
After digging around the code a bit, my current theory is that the
indirect buffer is incorrectly reused after the start of a new server
generation. The only difference I see in the radeon driver (which I
assume doesn't have the same problem?) is in the LeaveServer() function,
where it releases the indirect buffer. Can you try if that fixes the
problem?
Yes this seems to have fixed it, here's the patch:
--- ati.2/r128_dri.cMon Dec 31 06:00:11 2001
+++ ati.2-shurdeek/r128_dri.c Sun Jan 27 20:50:19 2002
@@ -308,6 +308,9 @@
info-sc_bottom = INREG(R128_SC_BOTTOM);
info-aux_sc_cntl = INREG(R128_SC_BOTTOM);
}
+} else {
+ R128CCEFlushIndirect(pScrn);
+ R128CCEReleaseIndirect(pScrn);
}
}
Would please the responsible person in all projects (dri, xf86, gatos) apply it?
Bye,
Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023
--
The product Microsoft sells isn't the software; it's comfort.
The product that Linux vendors usually sell is freedom.
msg02555/pgp0.pgp
Description: PGP signature
Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 08:15:29PM -0300, Davor Buvinic wrote: Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI drivers sources. No more messages in the kernel log like the following: [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 Yes this was exactly what it was intended to fix, and several similar errors as well. But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't appears to help... Hmm I just tried aviplay together with glxgears without crashing (though gears caused aviplay to crawl). What do the logs show? - Davor Mit freundlichen Gren Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg02557/pgp0.pgp Description: PGP signature
Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sunday 27 January 2002 20:43, you wrote: On Sun, Jan 27, 2002 at 08:15:29PM -0300, Davor Buvinic wrote: Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI drivers sources. No more messages in the kernel log like the following: [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 Yes this was exactly what it was intended to fix, and several similar errors as well. But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't appears to help... Hmm I just tried aviplay together with glxgears without crashing (though gears caused aviplay to crawl). What do the logs show? - Davor Mit freundlichen Gren Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 Yes, running glxgears cause the movie player to crawl and if I start to move or resize their windows X crashes. The movie player is MPlayer, today cvs. Here is my log file from X. As you can see, at the end of the file the following messages appears: [...] (II) R128(0): StopVideo (EE) R128(0): Idle timed out, resetting engine... [...] I found some documentation at the DRI website for debugging. I'll see if I can state more precisely the cause of the problem. - Davor --- XFree86 Version 4.2.0 (Unofficial Build: 4.2.0-0.2) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-pre6 i686 [ELF] Build Host: eniac Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Sun Jan 27 21:34:03 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Rage 128 (generic) (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout la (**) XKB: layout: la (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 02 class 06,80,00 hdr 00 (II) PCI: 00:0d:0: chip 1282,9102 card 4554,434e rev 31 class 02,00,00 hdr 00 (II) PCI: 00:0e:0: chip 9004,5078 card 9004,7850 rev 03 class 01,00,00 hdr 00 (II) PCI: 00:10:0: chip 1102,0002 card 1102,0020 rev 05 class 04,01,00 hdr 80 (II) PCI: 00:10:1: chip 1102,7002 card 1102,0020 rev 05 class 09,80,00 hdr 80 (II) PCI: 01:00:0: chip 1002,5246 card 1002,0008 rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x -
Re: [Xpert]Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sunday 27 January 2002 21:59, you wrote: On Sun, 27 Jan 2002, Davor Buvinic wrote: [...] Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI drivers sources. No more messages in the kernel log like the following: [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't appears to help... Please try latest GATOS CVS - main branch - and let me know if it works better. Vladimir Dergachev With the latest GATOS CVS - the one with changes from Peter Surda at the files radeon_driver.c, radeon_reg.h, fi1236.c, fi1236.h, msp3430.c, r128_dri.c, theatre.h and theatre_reg.h - the problem (apparently) is the same one that at first: corruption at login screen (xdm, kdm), the messages [drm:r128_cce_indirect] in the kernel log, and X crashes. With only the patch from Peter Surda to the file r128_dri.c no corruption at login screen, no messages in the kernel log but X crash with both mplayer and glxgears running, or only with mplayer after a while playing a video. BTW, which is the appropriate mailing list to discuss this stuff? I think that we're CC: to too many places... At this step we'll finish CC: to the linux kernel mailing list :) - Davor ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sat, Jan 26, 2002 at 05:22:17PM +0100, Michel Dnzer wrote:
On Sam, 2002-01-26 at 06:13, Peter Surda wrote:
Sorry that I'm not sending a patch, but I don't know if my solution is
correct.
A patch might help to make a judgement. ;)
Ok, here goes:
--- drm-kernel/r128_state.c Thu Dec 13 02:26:00 2001
+++ drm-kernel-shurdeek/r128_state.cSat Jan 26 05:36:10 2002
@@ -626,7 +626,7 @@
ADVANCE_RING();
- buf-pending = 1;
+ buf-pending = 0;
buf-used = 0;
/* FIXME: Check dispatched field */
buf_priv-dispatched = 0;
@@ -686,7 +686,7 @@
ADVANCE_RING();
- buf-pending = 1;
+ buf-pending = 0;
buf-used = 0;
/* FIXME: Check dispatched field */
buf_priv-dispatched = 0;
@@ -769,7 +769,7 @@
ADVANCE_RING();
- buf-pending = 1;
+ buf-pending = 0;
/* FIXME: Check dispatched field */
buf_priv-dispatched = 0;
}
@@ -831,12 +831,12 @@
buf = dma-buflist[blit-idx];
buf_priv = buf-dev_private;
- if ( buf-pid != current-pid ) {
+ if ( buf-pid 0 buf-pid != current-pid ) {
DRM_ERROR( process %d using buffer owned by %d\n,
current-pid, buf-pid );
return -EINVAL;
}
- if ( buf-pending ) {
+ if ( buf-pid 0 buf-pending ) {
DRM_ERROR( sending pending buffer %d\n, blit-idx );
return -EINVAL;
}
@@ -1334,12 +1334,12 @@
buf = dma-buflist[vertex.idx];
buf_priv = buf-dev_private;
- if ( buf-pid != current-pid ) {
+ if ( buf-pid 0 buf-pid != current-pid ) {
DRM_ERROR( process %d using buffer owned by %d\n,
current-pid, buf-pid );
return -EINVAL;
}
- if ( buf-pending ) {
+ if ( buf-pid 0 buf-pending ) {
DRM_ERROR( sending pending buffer %d\n, vertex.idx );
return -EINVAL;
}
@@ -1397,12 +1397,12 @@
buf = dma-buflist[elts.idx];
buf_priv = buf-dev_private;
- if ( buf-pid != current-pid ) {
+ if ( buf-pid 0 buf-pid != current-pid ) {
DRM_ERROR( process %d using buffer owned by %d\n,
current-pid, buf-pid );
return -EINVAL;
}
- if ( buf-pending ) {
+ if ( buf-pid 0 buf-pending ) {
DRM_ERROR( sending pending buffer %d\n, elts.idx );
return -EINVAL;
}
@@ -1552,12 +1552,12 @@
buf = dma-buflist[indirect.idx];
buf_priv = buf-dev_private;
- if ( buf-pid != current-pid ) {
+ if ( buf-pid 0 buf-pid != current-pid ) {
DRM_ERROR( process %d using buffer owned by %d\n,
current-pid, buf-pid );
return -EINVAL;
}
- if ( buf-pending ) {
+ if ( buf-pid 0 buf-pending ) {
DRM_ERROR( sending pending buffer %d\n, indirect.idx );
return -EINVAL;
}
So I looked at the code: pid 0 doesn't exist, and r128 driver seems to be
using it for optimizing searches for free buffer. So I added a
buf-pid 0
[cut]
Further investigations showed r128 and radeon where the only driver that
actually did a buf-pending = 1, so I changed it to 0 and now the symptoms
aren't ocurring anymore.
Your changes sound dangerous. :) You're basically removing the tests for
the errors, or am I missing something?
The first one definitely wasn't correct. A process of pid 0 doesn't exist, but
it has been handled as if it existed. As for the second one, I too am not
sure I'm not breaking something, but it fixed the problem and as I said, r128
and radeon are the only drivers that actually set buf-pending to 1, no other
drivers EVER do that. So I'm assuming r128 and radeon were trying to implement
something new, but it hasn't been completed and is broken.
I've also experienced the problem with gdm, when I log out of a GNOME
session. I suspect something (the freelist apparently?) doesn't get
properly reset when starting a new X server generation.
Hmm yes indeed I think you are right.
Let's investigate more.
Well it's fixed for me, but you are free to go :-).
Supplemental question: I noticed that while watching videos X often takes lot
of CPU EVEN when DMACopyblahblah is working (I added a xDrvMsg to the
driver to test). The funny thing is that e.g. with mplayer X eats about 6%,
and ON THE SAME FILE, with aviplay X eats about 25%. What could be causing
this? BTW this doesn't happen always, just mostly and I am unable to
reproduce a situation when this doesn't happen, it simply sometimes fixes
itself.
No idea about this, could you do some profiling to see where the time is
wasted?
I could
[Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
Hi! Sorry that I'm not sending a patch, but I don't know if my solution is correct. Problem description (both with dri from CVS dri and CVS gatos): on r128 when I KDE is starting, display is corrupt and lots of: Jan 26 04:38:38 ten kernel: [drm:r128_cce_indirect] *ERROR* process 15795 using buffer owned by 0 's appear (I reported this several months ago already). So I looked at the code: pid 0 doesn't exist, and r128 driver seems to be using it for optimizing searches for free buffer. So I added a buf-pid 0 into r128_state.c into all tests where it was tested. This fixed most corruption, but then Jan 26 05:03:28 ten kernel: [drm:r128_cce_indirect] *ERROR* sending pending buffer 0 's started appearing. Further investigations showed r128 and radeon where the only driver that actually did a buf-pending = 1, so I changed it to 0 and now the symptoms aren't ocurring anymore. As for radeon, I assume as the code is very similar to r128 including what I just fixed, it could help there too. Supplemental question: I noticed that while watching videos X often takes lot of CPU EVEN when DMACopyblahblah is working (I added a xDrvMsg to the driver to test). The funny thing is that e.g. with mplayer X eats about 6%, and ON THE SAME FILE, with aviplay X eats about 25%. What could be causing this? BTW this doesn't happen always, just mostly and I am unable to reproduce a situation when this doesn't happen, it simply sometimes fixes itself. Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- They say when you play that M$ CD backward you can hear satanic messages. That's nothing. If you play it forward it will install Windows. msg02537/pgp0.pgp Description: PGP signature
