I suspect this a dup of bug 90839. Do you see the regression remain on master or the 10.6 branch?

On:
mesa-git 10.7.0_devel.71031
mesa-libgl-git 10.7.0_devel.71031
(compiled from git master)
this problem still exists same as 10.6 and 10.6.1

If I go back this two packages to version 10.5.7 it works correctly.

How can I help locate the source of the problem?

You have two end points, a bisection would be very useful and only take a few minutes (maybe an hour at most?).

I made a test the bisection method, here's the result:

0e0e23ef537c9add672ff322f34e129a07edc55e is the first bad commit
commit 0e0e23ef537c9add672ff322f34e129a07edc55e
Author: Jordan Justen <jordan.l.justen@intel.com>
Date:   Wed Apr 22 11:43:50 2015 -0700

    i965/state: Emit pipeline select when changing pipelines
    
    Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

:040000 040000 725572870b90c40592e3d382faef748469403f67 ae158c5c1fc9c0487dbfad8b338ebdb27300c0a1 M      src


It will be helpful?

This confirmed yet by compiling 10.6.1 of reverse patch:
https://git.thm.de/tjkl80/mesa/commit/0e0e23ef537c9add672ff322f34e129a07edc55e.patch

It works correctly.
Do you expect the correction in the next version?

*** Bug 91343 has been marked as a duplicate of this bug. ***

(In reply to Tomasz C. from comment #0)
> * config and/or log files etc.
> GLX Renderer: Mesa DRI Intel Ironlake Mobile GLX Version: 2.1 Mesa 10.6.0
> 
> The problem is on Intel Core i5 M 450 - first generation (Nehalem) of Intel
> Core, also tested on the i3-3220T - third generation (Ivy Bridge) and
> i3-4005U fourth generation (Haswell) and it works properly.
> I did not test for second-generation (Sandy Bridge).

To confirm, the issue only happens on Ironlake for you?

I was unable to reproduce on GM45 or Ivy Bridge using
10.6.0 or master.

I tried the 3, 5, 10 and 70 Mbps versions, with
this command line:

mpv --vo=opengl --hwdec=vaapi Jellyfish-3-Mbps.mkv

> To confirm, the issue only happens on Ironlake for you?
> 
> I was unable to reproduce on GM45 or Ivy Bridge using
> 10.6.0 or master.
> 
> I tried the 3, 5, 10 and 70 Mbps versions, with
> this command line:
> 
> mpv --vo=opengl --hwdec=vaapi Jellyfish-3-Mbps.mkv

Yes, the issue only happens on Intel Core i5 M 450. This is probably Ironlake Graphics.
On other processors listed by me everything is working properly.

With the bug report No. 91343 appears that the issue also occurs on an Intel Core i5 M 460. It also probably is Ironlake Graphics.

(In reply to Tomasz C. from comment #8)
> 
> Yes, the issue only happens on Intel Core i5 M 450. This is probably
> Ironlake Graphics.
> On other processors listed by me everything is working properly.
> 
> With the bug report No. 91343 appears that the issue also occurs on an Intel
> Core i5 M 460. It also probably is Ironlake Graphics.

yeah i5 M 460 is Ironlake too, this is what vainfo states:
vainfo: Driver version: Intel i965 driver for Intel(R) Ironlake Mobile - 1.5.1

Sadly I don't have any other CPU to test.

Can someone please look into this issue.
On every start of mpv my system freezes for some seconds and every instance of the flashplugin crashes in my browser.
I'm always using mpv for watching flashvideos since it hast vaapi support, so this bug is really annoying.

I'm on Ironlake.

In 10.6.4 this bug is still present
Can not you just go back patch that causes the problem?

In 10.6.5 this bug is still present.

I spent a few hours on it to find the commit that causes a problem. You have exactly indicated commit, and five versions are not able to fix the bug? Or maybe you do not care about the old card users, if so, is just tell.

(In reply to Tomasz C. from comment #12)
> I spent a few hours on it to find the commit that causes a problem. You have
> exactly indicated commit, and five versions are not able to fix the bug? Or
> maybe you do not care about the old card users, if so, is just tell.

I haven't been able to reproduce it, but like I mentioned,
I didn't try on Ironlake. I don't have one of those systems
right now.

Is there any possibility of getting a backtrace?

I looked again at the patch, and I couldn't determine a
code path that would have an issue. Therefore I can't
think of a patch to let you try out.

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c
index e9d9467..2751152 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -878,7 +878,8 @@ brw_upload_invariant_state(struct brw_context *brw)
 {
    const bool is_965 = brw->gen == 4 && !brw->is_g4x;
 
-   brw_select_pipeline(brw, BRW_RENDER_PIPELINE);
+   brw_emit_select_pipeline(brw, BRW_RENDER_PIPELINE);
+   brw->last_pipeline = BRW_RENDER_PIPELINE;
 
    if (brw->gen < 6) {
       /* Disable depth offset clamping. */
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 9de42ce..7577cfc 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -423,9 +423,6 @@ void brw_init_state( struct brw_context *brw )
 {
    struct gl_context *ctx = &brw->ctx;
 
-   /* Force the first brw_select_pipeline to emit pipeline select */
-   brw->last_pipeline = BRW_NUM_PIPELINES;
-
    STATIC_ASSERT(ARRAY_SIZE(gen4_atoms) <= ARRAY_SIZE(brw->render_atoms));
    STATIC_ASSERT(ARRAY_SIZE(gen6_atoms) <= ARRAY_SIZE(brw->render_atoms));
    STATIC_ASSERT(ARRAY_SIZE(gen7_render_atoms) <=

(In reply to Chris Wilson from comment #14)
> diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
> b/src/mesa/drivers/dri/i965/brw_misc_state.c
> index e9d9467..2751152 100644
> --- a/src/mesa/drivers/dri/i965/brw_misc_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
> @@ -878,7 +878,8 @@ brw_upload_invariant_state(struct brw_context *brw)
>  {
>     const bool is_965 = brw->gen == 4 && !brw->is_g4x;
>  
> -   brw_select_pipeline(brw, BRW_RENDER_PIPELINE);
> +   brw_emit_select_pipeline(brw, BRW_RENDER_PIPELINE);
> +   brw->last_pipeline = BRW_RENDER_PIPELINE;
>  
>     if (brw->gen < 6) {
>        /* Disable depth offset clamping. */
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 9de42ce..7577cfc 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -423,9 +423,6 @@ void brw_init_state( struct brw_context *brw )
>  {
>     struct gl_context *ctx = &brw->ctx;
>  
> -   /* Force the first brw_select_pipeline to emit pipeline select */
> -   brw->last_pipeline = BRW_NUM_PIPELINES;
> -
>     STATIC_ASSERT(ARRAY_SIZE(gen4_atoms) <= ARRAY_SIZE(brw->render_atoms));
>     STATIC_ASSERT(ARRAY_SIZE(gen6_atoms) <= ARRAY_SIZE(brw->render_atoms));
>     STATIC_ASSERT(ARRAY_SIZE(gen7_render_atoms) <=

brw_init_state calls brw_upload_initial_gpu_state
which calls brw_upload_invariant_state, which calls
brw_select_pipeline(brw, BRW_RENDER_PIPELINE), so
this should be the same, right?

I'm happy to see something happening here.
This might be helpful for reproducing this bug.

I don't use a compositing window manager. So for me 'mpv --vo=opengl --hwdec=vaapi' doesn't hang.
But if I first start any gl-program e.g. glxgears and then start mpv --vo=opengl --hwdec=vaapi my system freezes for a few seconds and glxgears crashes with this error "intel_do_flush_locked failed: Input/output error"

*** Bug 91382 has been marked as a duplicate of this bug. ***

Chris patch of comment # 14 is working properly.
I hope that it will enter into the next release.

I am happy that this has been resolved.
Thanks to Chris for helping to fix this bug.

commit 4e5752e2b78243a71766538f62ca0a80488047a7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Aug 23 09:24:57 2015 +0100

    i965: Always re-emit the pipeline select during invariant state emission
    
    On the older platforms where we don't have logical contexts preserving
    state across batches, we emit the invariant state setup on every batch
    using the brw_invariant_state atom. This includes the pipeline selection
    which is cached with the introduction of
    
    commit 0e0e23ef537c9add672ff322f34e129a07edc55e
    Author: Jordan Justen <jordan.l.justen@intel.com>
    Date:   Wed Apr 22 11:43:50 2015 -0700
    
        i965/state: Emit pipeline select when changing pipelines
    
    However, we do not reset the cache between batches on context-less
    platforms resulting in us not setting the pipeline selection and can
    cause GPU hangs if a media pipelined was loaded in the meantime (e.g.
    mixing mplayer/gstreamer using libva and gnome-shell). A simple solution
    is to just forcibly re-emit the pipeline select along with the invariant
    state and reset the cache at that point.
    
    Reported-and-tested-by: Tomasz C. <tomaszc@o2.pl>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91254
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jordan Justen <jordan.l.justen@intel.com>
    Cc: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

*** Bug 91651 has been marked as a duplicate of this bug. ***

Confirmed as resolved for me on IronLake with Mesa git. Thanks.