On Wed, 2004-06-02 at 00:38, Arjan van de Ven wrote:
> > In [c] and [d] I'm applying an additional latency patch to the drm
> > kernel driver that affects radeon, r128 and mga based cards. The patch
> > is old and _illegal_ as it does reschedules with a lock on. So far the
> > computer has not locked up but I guess it is a matter of time :-)
>
> can you send me that patch (or point at an URL) ?
Sure, find them attached... If you apply the patches and enable the
kernel option that detects scheduling with locks held you will get an
oops.
I had a private thread with Andrew Morton, Takashi Iwai and Dave Airlie
about this issue. Dave floated it in the dri list and did some research
but there was no firm conclusion (a few suggestions but no patch to
test). I should contact them again. The dri list apparently thought that
things like this would cause stuttering in the video card. Goes without
saying that probably they think that dropouts and clicks in the audio
can be ignored :-) ;-) :-) I suggested maybe a runtime kernel option
could be used to satisfy both camps.
> > A real test with the Jack low latency server reveals that something else
> > is creating latency hits.
>
> do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap
module to grant non-root users those privileges (compiled as a module in
the kernel).
Just occured to me, is there anything else in FC2 that may be running
SCHED_FIFO?? I'll try to find out.
> > So, latencytest is happy but a real test with real applications is not.
>
> it might be an application artifact/interaction
It might be, but do we find out with what? See below for why I think it
may be the video output.
> > Other important data points:
> >
> > - xruns seem to be related to graphics activity
> > - booting FC2 into 2.4.26 with the low latency and preempt patches gives
> > me similar results (latency hits when running jack and jack apps)
> > - booting FC1 into 2.4.26 (same hardware, just replace the hard disk)
> > gives me a rock solid system (no xruns whatsoever, down to 128x2).
> >
> > So, it would seem to me that it is not (only) the kernel..........
> >
> > Things I could not make work:
> > - testing 2.6.6-1.391.x in FC1. For some reason init does not get
> > executed, probably a library problem somewhere...
>
> you need to pass vdso=0 to the kernel there.
Great, thanks, I'll test this later, it could help determine if the
problem is in the kernel or not...
> > Any ideas on what could cause this????
>
> try disabling DRI.
I tried almost every combination of xorg parameters I could think of.
Disabling DRI makes matter much _worse_! This is one of the reasons why
I think the culprit is xorg or something in the video rendering chain.
With DRI on I get fewer xruns, with DRI off I get tons of them (I think
they were shorter). I could rationalize this by thinking that the "high
end" primitives get broken down into smaller chunks of more basic
graphic primitives and then each one of them is doing something that
causes an xrun. No facts to support this, of course.
> DRI sometimes can "hold" the pci bus for quite some time, which by
> definition causes latency since no IO can be done
Yes. I also tried changing the bus latency for the different "cards" in
the laptop using setpci. No change. I could get better overall
performance (ie: the screen would update faster with the xrun
information :-)
-- Fernando
--- linux-2.6.4/drivers/char/drm/mga_dma.c~ 2004-03-10 18:55:44.000000000 -0800
+++ linux-2.6.4/drivers/char/drm/mga_dma.c 2004-03-23 11:22:31.682896672 -0800
@@ -59,6 +59,7 @@
MGA_WRITE8( MGA_CRTC_INDEX, 0 );
return 0;
}
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -78,6 +79,7 @@
for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
status = MGA_READ( MGA_STATUS ) & MGA_DMA_IDLE_MASK;
if ( status == MGA_ENDPRDMASTS ) return 0;
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -166,6 +168,7 @@
for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
status = MGA_READ( MGA_STATUS ) & MGA_ENGINE_IDLE_MASK;
if ( status == MGA_ENDPRDMASTS ) break;
+ cond_resched();
DRM_UDELAY( 1 );
}
--- linux-2.6.4/drivers/char/drm/r128_cce.c~ 2004-03-10 18:55:22.000000000 -0800
+++ linux-2.6.4/drivers/char/drm/r128_cce.c 2004-03-23 11:31:46.627532264 -0800
@@ -124,6 +124,7 @@
if ( !(R128_READ( R128_PC_NGUI_CTLSTAT ) & R128_PC_BUSY) ) {
return 0;
}
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -140,6 +141,7 @@
for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
int slots = R128_READ( R128_GUI_STAT ) & R128_GUI_FIFOCNT_MASK;
if ( slots >= entries ) return 0;
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -161,6 +163,7 @@
r128_do_pixcache_flush( dev_priv );
return 0;
}
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -221,6 +224,7 @@
return r128_do_pixcache_flush( dev_priv );
}
}
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -871,6 +875,7 @@
return buf;
}
}
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -904,6 +909,7 @@
r128_update_ring_snapshot( ring );
if ( ring->space >= n )
return 0;
+ cond_resched();
DRM_UDELAY( 1 );
}
--- linux-2.6.4/drivers/char/drm/radeon_cp.c~ 2004-03-10 18:55:23.000000000 -0800
+++ linux-2.6.4/drivers/char/drm/radeon_cp.c 2004-03-22 18:28:05.544607016 -0800
@@ -608,6 +608,7 @@
for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
if ( !(RADEON_READ( RADEON_RB2D_DSTCACHE_CTLSTAT )
& RADEON_RB2D_DC_BUSY) ) {
+ cond_resched();
return 0;
}
DRM_UDELAY( 1 );
@@ -631,6 +632,7 @@
int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
& RADEON_RBBM_FIFOCNT_MASK );
if ( slots >= entries ) return 0;
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -656,6 +658,7 @@
radeon_do_pixcache_flush( dev_priv );
return 0;
}
+ cond_resched();
DRM_UDELAY( 1 );
}
@@ -1586,6 +1589,7 @@
}
if (t) {
+ cond_resched();
DRM_UDELAY( 1 );
dev_priv->stats.freelist_loops++;
}
@@ -1669,6 +1673,7 @@
i = 0;
last_head = head;
+ cond_resched();
DRM_UDELAY( 1 );
}
