On Sat, Jan 26, 2002 at 05:22:17PM +0100, Michel Dänzer 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.c Sat 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 but I'm lazy :-)
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
Hello, this is Bill Gates and I pronounce Monopoly, er, Windows as Windows.
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
