[REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Sitsofe Wheeler]

Hi,

With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu
10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC
900 with an i915.

Attempts to bisect the issue are not successful - most kernels in
between rc1 and rc2 just make the system come up with a black screen
which takes minutes between showing messages (rather than finishing in
two seconds). bc584c5107bfd97e2aa41c798e3b213bcdd4eae7 seems to be good
but 45d7f32c7a43cbb9592886d38190e379e2eb2226 is not.

Warnings like:

[   64.227046] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 31.
[   82.953011] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.

appear frequently in the dmesg and the stalls are most visible when
playing fullscreen video. The first warning message (Insufficient
FIFO...) is present in 2.6.36-rc1 but not 2.6.35.

One additional quirk is that a more recent X userspace
(xserver-xorg-video-intel
2:2.12.0+git20100810.19c48d3b-0ubuntu0sarvatt2~lucid, libdrm-intel1
2.4.21+git20100804.431f7f00-0ubuntu0sarvatt~lucid,
xorg 1:7.5+6ubuntu1) now has major tearing (when watching video) and
refresh (in general at least when using compiz) issues which were not
seen with 2.6.36-rc1.

-- 
Sitsofe | http://sucs.org/~sits/

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Chris Wilson]

On Tue, 24 Aug 2010 00:35:51 +0100, Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> Hi,
> 
> With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu
> 10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC
> 900 with an i915.

>From the error message, I'd suggest we'd tackle hangcheck - it simply
shouldn't be firing at all under normal circumstances. (Looking at it we
don't handle the introduction of the BSD ring correctly, but that is
irrelevant on the EeePC 900.)

Do the stalls and tearing go away with:

diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index e4d42a7..dc5fb4f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1305,8 +1305,7 @@ void i915_hangcheck_elapsed(unsigned long data)
                dev_priv->hangcheck_count = 0;
 
                /* Issue a wake-up to catch stuck h/w. */
-               if (dev_priv->render_ring.waiting_gem_seqno |
-                   dev_priv->bsd_ring.waiting_gem_seqno) {
+               if (0) {
                        DRM_ERROR("Hangcheck timer elapsed... GPU idle, missed IRQ.\n");
                        if (dev_priv->render_ring.waiting_gem_seqno)
                                DRM_WAKEUP(&dev_priv->render_ring.irq_queue);

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Sitsofe Wheeler]

On Tue, Aug 24, 2010 at 01:12:22AM +0100, Chris Wilson wrote:
> 
> From the error message, I'd suggest we'd tackle hangcheck - it simply
> shouldn't be firing at all under normal circumstances. (Looking at it we
> don't handle the introduction of the BSD ring correctly, but that is
> irrelevant on the EeePC 900.)
> 
> Do the stalls and tearing go away with:

The stalls became a bit better with the patch but there were still very
small pauses but the tearing with more recent X bits is definitely still
there. Additionally videos in totem would play as a tiny one pixel high
row about a quarter of the screen across at the top left of the screen.
It also seems that X has started having trouble refreshing itself so
sometimes new windows are invisible (especially with compiz).

I've also noticed a couple of other things. Sometimes (but without any
pattern) an extra display is detected even though no external display is
plugged in. Here's an example of the xrandr output:
Screen 0: minimum 320 x 200, current 2384 x 768, maximum 4096 x 4096
LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x600       59.5*+
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     72.8     75.0     59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
VGA1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)
  1360x768 (0xbc)   84.8MHz
        h: width  1360 start 1432 end 1568 total 1776 skew    0 clock   47.7KHz
        v: height  768 start  771 end  781 total  798           clock   59.8Hz

Sometimes the output is TV1 sometimes it is VGA1 and sometimes these
extra outputs will disappear. Another issue is that switching from X to
a console for the first time causes a LCD "blooming" effect.

-- 
Sitsofe | http://sucs.org/~sits/

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Chris Wilson]

On Tue, 24 Aug 2010 08:57:41 +0100, Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> The stalls became a bit better with the patch but there were still very
> small pauses but the tearing with more recent X bits is definitely still
> there. Additionally videos in totem would play as a tiny one pixel high
> row about a quarter of the screen across at the top left of the screen.
> It also seems that X has started having trouble refreshing itself so
> sometimes new windows are invisible (especially with compiz).

Ok, I'm a little happier that the hangcheck could be just another symptom
of the problem...

I think it is safe to assume that the bug is in i915, so restricting the
bisect to just drm seems plausible:

git bisect start drivers/gpu/drm
git bisect good 2.6.36-rc1
git bisect bad 2.6.36-rc2

And yes, it does apppear that the false detection rate for TV has changed.
The suspicion is that the change to intel_wait_for_vblank() is actually
causing issues here.

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Sitsofe Wheeler]

On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
> 
> Ok, I'm a little happier that the hangcheck could be just another symptom
> of the problem...
> 
> I think it is safe to assume that the bug is in i915, so restricting the
> bisect to just drm seems plausible:
> 
> git bisect start drivers/gpu/drm
> git bisect good 2.6.36-rc1
> git bisect bad 2.6.36-rc2

I should mention that I ran a similar bisect yesterday but it led to a dead
end:

# bad: [9ee47476d6734c9deb9ae9ab05d963302f6b6150] Merge branch 'radix-tree' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev
# good: [da5cabf80e2433131bf0ed8993abc0f7ea618c73] Linux 2.6.36-rc1
git bisect start 'HEAD' 'v2.6.36-rc1'
# good: [d1126ad907ce197ff45fbc2369fbeaf8ae6f75a8] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git bisect good d1126ad907ce197ff45fbc2369fbeaf8ae6f75a8
# bad: [4fefe435626758b14e6c05d2a5f8d71a997c0ad6] drm/i915,intel_agp: Add support for Sandybridge D0
git bisect bad 4fefe435626758b14e6c05d2a5f8d71a997c0ad6
# bad: [2e88e40bed136a7b7cb1c77d8dc6bd181d0d2732] drm/i915/sdvo: Markup a few constant strings.
git bisect bad 2e88e40bed136a7b7cb1c77d8dc6bd181d0d2732
# bad: [6146b3d61925116e3fecce36c2fd873665bd6614] drm/i915: i8xx also doesn't like multiple oustanding pageflips
git bisect bad 6146b3d61925116e3fecce36c2fd873665bd6614
# bad: [e044218a8ecb560b6fad65912a4e7e509db40414] drm/i915/sdvo: Add dot crawl property
git bisect bad e044218a8ecb560b6fad65912a4e7e509db40414
# bad: [45d7f32c7a43cbb9592886d38190e379e2eb2226] Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
git bisect bad 45d7f32c7a43cbb9592886d38190e379e2eb2226

All the bad kernels above boot EXTREMELY slowly and it's not clear why. Using
the results above to run your tests produced the following:

Bisecting: a merge base must be tested
[45d7f32c7a43cbb9592886d38190e379e2eb2226] Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
git bisect bad 45d7f32c7a43cbb9592886d38190e379e2eb2226
The merge base 45d7f32c7a43cbb9592886d38190e379e2eb2226 is bad.
This means the bug has been fixed between 45d7f32c7a43cbb9592886d38190e379e2eb2226 and [da5cabf80e2433131bf0ed8993abc0f7ea618c73].

As mentioned in the first mail, c584c5107bfd97e2aa41c798e3b213bcdd4eae7
seems to be good but 45d7f32c7a43cbb9592886d38190e379e2eb2226 does
not...

Any ideas?

> And yes, it does apppear that the false detection rate for TV has changed.
> The suspicion is that the change to intel_wait_for_vblank() is actually
> causing issues here.

OK.

-- 
Sitsofe | http://sucs.org/~sits/

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Chris Wilson]

On Tue, 24 Aug 2010 09:49:02 +0100, Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
> > 
> > Ok, I'm a little happier that the hangcheck could be just another symptom
> > of the problem...
> > 
> > I think it is safe to assume that the bug is in i915, so restricting the
> > bisect to just drm seems plausible:
> > 
> > git bisect start drivers/gpu/drm
> > git bisect good 2.6.36-rc1
> > git bisect bad 2.6.36-rc2
> 
> I should mention that I ran a similar bisect yesterday but it led to a dead
> end:
[snip]
> All the bad kernels above boot EXTREMELY slowly and it's not clear why. Using
> the results above to run your tests produced the following:

I was hoping that git would be more intelligent than that. Is there a way
to simply bisect down one side of a merge?

The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde.
A trivial patch you can apply on each step is:

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 33dbcc4..88f3b6c 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -837,7 +837,7 @@ static int hpet_clocksource_register(void)
         * cyc/sec = FSEC_PER_SEC/hpet_period(fsec/cyc)
         * cyc/sec = (FSEC_PER_NSEC * NSEC_PER_SEC)/hpet_period
         */
-       hpet_freq = FSEC_PER_NSEC * NSEC_PER_SEC;
+       hpet_freq = (u64) FSEC_PER_NSEC * NSEC_PER_SEC;
        do_div(hpet_freq, hpet_period);
        clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq);

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [REGRESSION, BISECTED, i915]: Periodic stalls with 2.6.36-rc2

[Sitsofe Wheeler]

On Tue, Aug 24, 2010 at 10:00:47AM +0100, Chris Wilson wrote:
> 
> I was hoping that git would be more intelligent than that. Is there a
> way to simply bisect down one side of a merge?

Seemingly not...

> The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde.
> A trivial patch you can apply on each step is:

Thanks that patch got it booting at normal speeds. Bisecting has now
narrowed the flickering/corruption with a newer X userspace down to
this:

commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Aug 18 13:20:54 2010 -0700

    drm/i915: wait for actual vblank, not just 20ms
    
    Waiting for a hard coded 20ms isn't always enough to make sure a vblank
    period has actually occurred, so add code to make sure we really have
    passed through a vblank period (or that the pipe is off when disabling).
    
    This prevents problems with mode setting and link training, and seems to
    fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
    on an HP 8440p instead.  Hopefully also fixes
    https://bugs.freedesktop.org/show_bug.cgi?id=29141.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

Reverting the above against HEAD seems to have fixed the misdetection of
displays and hangcheck warnings don't appear (although plenty of FIFO
warnings still). I notice that this commit also seemed to be the cause
of problems for Ivan and Pekka in http://lkml.org/lkml/2010/8/23/452 ...

-- 
Sitsofe | http://sucs.org/~sits/

[PATCH 1/2] drm/i915: Revert wait for vblank to prevent X refresh issues

[Sitsofe Wheeler]

In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were
converted into vblank waits. One of these caused tearing, mode detection
and redraw issues on an EeePC 900 with a more recent intel userspace (
http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves
the issue.
---
 drivers/gpu/drm/i915/intel_display.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 23157e1..116d938 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4539,7 +4539,7 @@ struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder *intel_encoder,
 		encoder_funcs->commit(encoder);
 	}
 	/* let the connector get through one full cycle before testing */
-	intel_wait_for_vblank(dev, intel_crtc->pipe);
+	msleep(20);
 
 	return crtc;
 }
-- 
1.7.1

[PATCH 1/2] drm/i915: Revert wait for vblank to prevent X refresh issues

[Sitsofe Wheeler]

In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were
converted into vblank waits. One of these caused tearing, mode detection
and redraw issues on an EeePC 900 with a more recent intel userspace (
http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves
the issue.

Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
---
 drivers/gpu/drm/i915/intel_display.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 23157e1..116d938 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4539,7 +4539,7 @@ struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder *intel_encoder,
 		encoder_funcs->commit(encoder);
 	}
 	/* let the connector get through one full cycle before testing */
-	intel_wait_for_vblank(dev, intel_crtc->pipe);
+	msleep(20);
 
 	return crtc;
 }
-- 
1.7.1

[PATCH 2/2] drm/i915: Revert extra intel_wait_for_vblank to prevent stalls.

[Sitsofe Wheeler]

With the extra intel_wait_for_vblank added in commit
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being
triggered (which were detected by i915_hangcheck_elapsed). Partially
revert this change for now.

Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
---
 drivers/gpu/drm/i915/intel_display.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 116d938..534f1fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2379,8 +2379,10 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode)
 			I915_READ(dspbase_reg);
 		}
 
-		/* Wait for vblank for the disable to take effect */
-		intel_wait_for_vblank_off(dev, pipe);
+		if (!IS_I9XX(dev)) {
+			/* Wait for vblank for the disable to take effect */
+			intel_wait_for_vblank_off(dev, pipe);
+		}
 
 		/* Don't disable pipe A or pipe A PLLs if needed */
 		if (pipeconf_reg == PIPEACONF &&
-- 
1.7.1

Re: [PATCH 2/2] drm/i915: Revert extra intel_wait_for_vblank to prevent stalls.

[Jesse Barnes]

On Tue, 24 Aug 2010 16:56:16 +0100
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> With the extra intel_wait_for_vblank added in commit
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being
> triggered (which were detected by i915_hangcheck_elapsed). Partially
> revert this change for now.
> 
> Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 116d938..534f1fa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2379,8 +2379,10 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode)
>  			I915_READ(dspbase_reg);
>  		}
>  
> -		/* Wait for vblank for the disable to take effect */
> -		intel_wait_for_vblank_off(dev, pipe);
> +		if (!IS_I9XX(dev)) {
> +			/* Wait for vblank for the disable to take effect */
> +			intel_wait_for_vblank_off(dev, pipe);
> +		}
>  
>  		/* Don't disable pipe A or pipe A PLLs if needed */
>  		if (pipeconf_reg == PIPEACONF &&

Hm why would we be triggering the hangcheck timer due to this code?
I'd rather figure that out and fix it before covering it up like this.

Wait for vblank off will spin until the display line reg stops
incrementing, so it's important that we flush any previous writes to
shut off the pipe before waiting.  So adding a POSTING_READ() above it
might help?  But that still doesn't explain why it would cause the
hangcheck timer to notice a hang...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 2/2] drm/i915: Revert extra intel_wait_for_vblank to prevent stalls.

[Jesse Barnes]

On Tue, 24 Aug 2010 16:56:16 +0100
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> With the extra intel_wait_for_vblank added in commit
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being
> triggered (which were detected by i915_hangcheck_elapsed). Partially
> revert this change for now.
> 
> Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 116d938..534f1fa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2379,8 +2379,10 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode)
>  			I915_READ(dspbase_reg);
>  		}
>  
> -		/* Wait for vblank for the disable to take effect */
> -		intel_wait_for_vblank_off(dev, pipe);
> +		if (!IS_I9XX(dev)) {
> +			/* Wait for vblank for the disable to take effect */
> +			intel_wait_for_vblank_off(dev, pipe);
> +		}
>  
>  		/* Don't disable pipe A or pipe A PLLs if needed */
>  		if (pipeconf_reg == PIPEACONF &&

Hm why would we be triggering the hangcheck timer due to this code?
I'd rather figure that out and fix it before covering it up like this.

Wait for vblank off will spin until the display line reg stops
incrementing, so it's important that we flush any previous writes to
shut off the pipe before waiting.  So adding a POSTING_READ() above it
might help?  But that still doesn't explain why it would cause the
hangcheck timer to notice a hang...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 1/2] drm/i915: Revert wait for vblank to prevent X refresh issues

[Jesse Barnes]

On Tue, 24 Aug 2010 16:53:59 +0100
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were
> converted into vblank waits. One of these caused tearing, mode detection
> and redraw issues on an EeePC 900 with a more recent intel userspace (
> http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves
> the issue.
> 
> Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 23157e1..116d938 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4539,7 +4539,7 @@ struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder *intel_encoder,
>  		encoder_funcs->commit(encoder);
>  	}
>  	/* let the connector get through one full cycle before testing */
> -	intel_wait_for_vblank(dev, intel_crtc->pipe);
> +	msleep(20);
>  
>  	return crtc;
>  }

Wow, tearing, mode detection and redraw problems all because of this
line?  Maybe because we wait for a longer period here now?  Can you
check and see if we're timing out in the wait_for_vblank function?

-- 
Jesse Barnes, Intel Open Source Technology Center

[REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Peter Stuge]

Hello, new on list but not to the kernel. I also have the issue on
ThinkPad X40.

00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA controller])
	Subsystem: IBM Device 0557
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Memory at d0000000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at 1800 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [d0] Power Management version 1
	Kernel driver in use: i915

I've been running KMS and drm-intel.git since around 2.6.30, roughly
the start of this year, and I've had lots of "fun" with KMS. :p I'm
very positive to the KMS concept but it's been a bumpy road so far.

In general, Xv performance with KMS leaves me with a feeling that
something is not quite right in terms of playback, both with mplayer
and vlc. But while movies are nice, this stalling issue is more
important.

drm-intel.git as of 07-21 has sortof worked for me, but could not
suspend. Later drm-intel.git would come up with the panel disabled,
so basically make the system unusable. I've been using 07-21 for
about a month, and just avoiding suspending.

I'm now running drm-intel.git/drm-intel-next (which seems to not get
the activity first?) and the latest commit is Linus 2.6.36-rc2. I've
merged wireless-testing.git on top of this for ath9k woes.

I get the stall precisely every 10 seconds. In VT mode the system
stalls for about a second (the cursor stops blinking) and if I'm
typing during the stall then my keypresses appear correctly after the
stall ends. No errors in dmesg. Should I set drm.debug to something?

If I'm running X (I've tried xf86-video-intel 2.12.0 and current .git
master) then my keypresses appear twice after the stall ends, but
honouring shift. If I hold shift, type X, release shift during a
stall then I'll get "Xx" after the stall ends. This makes X
practically unusable for me, so I'm at a plain VT for now.

Suspend works both in VT and in X, so some things have definately
improved for me since 07-21. :)

I've just upgraded my userspace and have xorg-server-1.8.2. No Xv
image with either xf86-video-intel driver. I haven't tried this
server with the 07-21 kernel to find out if Xv works there. The
stalling is more important.

Chris' patch to i915_irq.c disabling wake-ups has no effect on the
stalls in VT mode for me.

I haven't bisected, would that be a big help? I'll probably have to
spend a fair amount of time on that, since the latest previous kernel
I could get to start is over a month old. I've tried drm-intel.git a
couple of times over this month, but for long periods of time there
were no changes. (Should I look elsewhere?)

I also get intermittent FIFO errors, but I don't know how relevant
they are for this issue. It seems like the stalling is a very
distinct issue.

Please let me know how I can help fix this.


//Peter

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Peter Stuge]

Peter Stuge wrote:
> Hello, new on list but not to the kernel. I also have the issue on
> ThinkPad X40.

As another data point, it seems that there was a similar problem with
drm/radeon:

https://bugs.freedesktop.org/show_bug.cgi?id=28411
[Bug 28411] Output polling causes latency every 10 seconds


//Peter

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Chris Wilson]

On Wed, 25 Aug 2010 21:15:06 +0200, Peter Stuge <peter@stuge.se> wrote:
> In general, Xv performance with KMS leaves me with a feeling that
> something is not quite right in terms of playback, both with mplayer
> and vlc. But while movies are nice, this stalling issue is more
> important.

That should now be fixed in -intel, we allocating a fresh buffer for every
frame and incurring massive clflush overhead. However, we have we replaced
it with a worse bug...
 
> drm-intel.git as of 07-21 has sortof worked for me, but could not
> suspend. Later drm-intel.git would come up with the panel disabled,
> so basically make the system unusable. I've been using 07-21 for
> about a month, and just avoiding suspending.
> 
> I'm now running drm-intel.git/drm-intel-next (which seems to not get
> the activity first?) and the latest commit is Linus 2.6.36-rc2. I've
> merged wireless-testing.git on top of this for ath9k woes.
> 
> I get the stall precisely every 10 seconds. In VT mode the system
> stalls for about a second (the cursor stops blinking) and if I'm
> typing during the stall then my keypresses appear correctly after the
> stall ends. No errors in dmesg. Should I set drm.debug to something?

This is caused by the hotplug polling code taking around 600ms to
determine that the VGA is not connected.

https://bugs.freedesktop.org/show_bug.cgi?id=29536

> If I'm running X (I've tried xf86-video-intel 2.12.0 and current .git
> master) then my keypresses appear twice after the stall ends, but
> honouring shift. If I hold shift, type X, release shift during a
> stall then I'll get "Xx" after the stall ends. This makes X
> practically unusable for me, so I'm at a plain VT for now.
> 
> Suspend works both in VT and in X, so some things have definately
> improved for me since 07-21. :)
> 
> I've just upgraded my userspace and have xorg-server-1.8.2. No Xv
> image with either xf86-video-intel driver. I haven't tried this
> server with the 07-21 kernel to find out if Xv works there. The
> stalling is more important.

https://bugs.freedesktop.org/show_bug.cgi?id=29574 (I think, Daniel
reported something closer to your issue on IRC, but I don't have an actual
bug for that.)

> Chris' patch to i915_irq.c disabling wake-ups has no effect on the
> stalls in VT mode for me.
> 
> I haven't bisected, would that be a big help? I'll probably have to
> spend a fair amount of time on that, since the latest previous kernel
> I could get to start is over a month old. I've tried drm-intel.git a
> couple of times over this month, but for long periods of time there
> were no changes. (Should I look elsewhere?)

No, sounds like you've hit almost all of the recent 855 regressions. But
you have a cursor, that is more than most people!
 
> I also get intermittent FIFO errors, but I don't know how relevant
> they are for this issue. It seems like the stalling is a very
> distinct issue.

Actually reporting the FIFO issue is new, the problem has been around for
a while though. The underlying issue is that we have a very pessimistic
guess for the memory fetch and so estimate that we require more FIFO
entries than is available on the hardware. The challenge is to build a
table of suitable memory latencies that we can use for a more accurate
guess, and save power.

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Peter Stuge]

Hi again,

Chris Wilson wrote:
> > In general, Xv performance with KMS leaves me with a feeling that
> > something is not quite right in terms of playback, both with mplayer
> > and vlc. But while movies are nice, this stalling issue is more
> > important.
> 
> That should now be fixed in -intel,

Sounds good! I'd love to test. Which branch/commit is that? I just
pulled and am using 68a5ad4.

mplayer -vo gl or gl2 works but uses sw rendering and is very slow.

Incidentally, apropos the backlight commit in xf86-video-intel, it
seems like the driver always sets the backlight to 0. Whenver I start
X, backlight goes to minimum. I can crank it up with Fn+Home, but if
I restart X then it goes back down again.

/proc/acpi/ibm/brightness is always accurate, showing 0 after X
starts.


> However, we have we replaced it with a worse bug...

Oh well..


> > I get the stall precisely every 10 seconds.
> 
> This is caused by the hotplug polling code taking around 600ms to
> determine that the VGA is not connected.

Ouch. Could it rely on DDC? Maybe a quick DDC query could be done
first, and if that seems to indicate that something is connected
only then do the heavy work reading the border color?


> https://bugs.freedesktop.org/show_bug.cgi?id=29536

Lovely! The patch works well for me, booting with
drm_kms_helper.poll=0 on the kernel command line, and I'm back in X
now. I need to sort out some keyboard issues, but they are unrelated.

The commit message mentions runtime switching of the polling - how is
that done? As I understand it I might have to do that in order to run
xrandr e.g. to set up a projector, or possibly after - or no?


> > I've just upgraded my userspace and have xorg-server-1.8.2. No Xv
> > image with either xf86-video-intel driver. I haven't tried this
> > server with the 07-21 kernel to find out if Xv works there. The
> > stalling is more important.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=29574 (I think, Daniel
> reported something closer to your issue on IRC, but I don't have an
> actual bug for that.)

Disabling polling made no difference for Xv. I will try to merge your
overlay branch.


> > drm-intel.git (Should I look elsewhere?)
> 
> No, sounds like you've hit almost all of the recent 855 regressions.

.36-rc2 is the first kernel in what seems like a long time that feels
like a solid improvement, even if there are still some issues.
Well done!


> But you have a cursor, that is more than most people!

Funny you should say that! :) Actually I *don't* have a cursor in X
on cold boot, but it shows up after suspend+resume.

The cursor I mentioned is the VT blinking one.


> very pessimistic guess for the memory fetch

Aha. Thanks for the explanation!


//Peter

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Chris Wilson]

On Thu, 26 Aug 2010 01:33:15 +0200, Peter Stuge <peter@stuge.se> wrote:
> Hi again,
> 
> Chris Wilson wrote:
> > > In general, Xv performance with KMS leaves me with a feeling that
> > > something is not quite right in terms of playback, both with mplayer
> > > and vlc. But while movies are nice, this stalling issue is more
> > > important.
> > 
> > That should now be fixed in -intel,
> 
> Sounds good! I'd love to test. Which branch/commit is that? I just
> pulled and am using 68a5ad4.
> 
> mplayer -vo gl or gl2 works but uses sw rendering and is very slow.

Master with -vo xv should be good, if it doesn't hang. 
 
> Incidentally, apropos the backlight commit in xf86-video-intel, it
> seems like the driver always sets the backlight to 0. Whenver I start
> X, backlight goes to minimum. I can crank it up with Fn+Home, but if
> I restart X then it goes back down again.
> 
> /proc/acpi/ibm/brightness is always accurate, showing 0 after X
> starts.

That wasn't meant to be pushed. :( I was working on rectifying lack of
backlight controls in on T61 and trying to reduce the number of pieces of
code trying to accomplish the same thing through different means. I
thought that work was contained on the T61...

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Peter Stuge]

Chris Wilson wrote:
> > > > Xv performance
> > > 
> > > That should now be fixed in -intel,
> > 
> > Sounds good! I'd love to test. Which branch/commit is that?
> 
> Master with -vo xv should be good, if it doesn't hang.

Doesn't hang, mplayer says:

X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)

over and over, with a window just showing the blue overlay keying.
I'm still working on the merge with your overlay branch.


> > Incidentally, apropos the backlight commit
> 
> That wasn't meant to be pushed. :( I was working on rectifying lack
> of backlight controls in on T61 and trying to reduce the number of
> pieces of code trying to accomplish the same thing through
> different means. I thought that work was contained on the T61...

It could be - the resetting backlight thing happened also before the
backlight commit. Before pulling I was using the directly preceding
commit.


//Peter

Re: [REGRESSION, i915]: Periodic stalls with 2.6.36-rc2

[Chris Wilson]

On Thu, 26 Aug 2010 02:15:20 +0200, Peter Stuge <peter@stuge.se> wrote:
> It could be - the resetting backlight thing happened also before the
> backlight commit. Before pulling I was using the directly preceding
> commit.

https://bugs.freedesktop.org/show_bug.cgi?id=29716

That patch isn't complete but is on the right lines. The first bug appears
to be that in the driver we have multiple bits of code to set the panel
backlight with different bugs.

-- 
Chris Wilson, Intel Open Source Technology Centre