Created attachment 71070 [details]
gem_cpu_concurrent_blit faild dmesg

I bisect this failed case, and get the same bisect result.
So I conbine these two cases as the same bug.

Just to check: Does reverting

commit 7c7b4d55fb69f679c27f8ed056c6f304cd69c3b3
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Tue Dec 4 15:12:05 2012 +0200

    drm/i915: Set initial seqno value close to wrap boundary
    
    To gain confidence in the wrap handling, make it happen quite
    soon after the boot.
    
    Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Fix the issues again?

btw, when adding bisect results, please cite the commit that introduce the regression like above, since that's the most important thing for us. Only if the bisect turns out to not be stable do we look at the bisect log to figure out where the bisect might have gone wrong. I'll update BKMs.

Assigning to Mika ...

> btw, when adding bisect results, please cite the commit that introduce the
> regression like above, since that's the most important thing for us. Only if
> the bisect turns out to not be stable do we look at the bisect log to figure
> out where the bisect might have gone wrong. I'll update BKMs.

commit 7c7b4d55fb69f679c27f8ed056c6f304cd69c3b3 

Revert this commit at the top of the -next-queued branch, after test, I'm sure it's good.

See https://patchwork.kernel.org/patch/1844941/

(In reply to comment #5)
> See https://patchwork.kernel.org/patch/1844941/

I can't patch below in your given patch. which branch could I attach this patch? 

>>@@ -628,7 +634,7 @@  gen6_ring_sync(struct intel_ring_buffer *waiter,
>> 	BUG_ON(!waiter->outstanding_lazy_request);
>> 
>> 	/* If seqno wrap happened, omit the wait with no-ops */
>>-	if (likely(waiter->outstanding_lazy_request > seqno)) {
>>+	if (likely(i915_gem_next_seqno(waiter->dev) > seqno)) {
>> 		intel_ring_emit(waiter,
>> 				dw1 |
>> 				signaller->semaphore_register[waiter->id]);

case gem_gtt_concurrent_blit core dumped, has same bisect commit.
output:
gem_gtt_concurrent_blit: gem_gtt_concurrent_blit.c:72: cmp_bo: Assertion `*vaddr++ == val' failed.
Aborted (core dumped)

dmesg:
[   47.508457] [drm:i915_driver_open],
[   47.508472] [drm:intel_crtc_set_config], [CRTC:3] [FB:21] #connectors=1 (x y) (0 0)
[   47.508478] [drm:intel_modeset_stage_output_state], [CONNECTOR:17:HDMI-A-2] to [CRTC:3]
[   47.508480] [drm:intel_crtc_set_config], [CRTC:5] [NOFB]
[   47.508482] [drm:intel_modeset_stage_output_state], [CONNECTOR:17:HDMI-A-2] to [CRTC:3]
[   47.508484] [drm:intel_crtc_set_config], [CRTC:7] [NOFB]
[   47.508485] [drm:intel_modeset_stage_output_state], [CONNECTOR:17:HDMI-A-2] to [CRTC:3]
[   47.508490] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 9, cursor: 6
[   47.508495] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 9, cursor: 6
[   47.508500] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 9, cursor: 6
[   47.508505] [drm:i915_driver_open],
[   47.781840] [drm:intel_crtc_set_config], [CRTC:3] [FB:21] #connectors=1 (x y) (0 0)
[   47.781847] [drm:intel_modeset_stage_output_state], [CONNECTOR:17:HDMI-A-2] to [CRTC:3]
[   47.781849] [drm:intel_crtc_set_config], [CRTC:5] [NOFB]
[   47.781851] [drm:intel_modeset_stage_output_state], [CONNECTOR:17:HDMI-A-2] to [CRTC:3]
[   47.781853] [drm:intel_crtc_set_config], [CRTC:7] [NOFB]
[   47.781855] [drm:intel_modeset_stage_output_state], [CONNECTOR:17:HDMI-A-2] to [CRTC:3]
[   47.781859] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 9, cursor: 6
[   47.781864] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 9, cursor: 6
[   47.781869] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 9, cursor: 6

Chris patch is on top of the old tree (the broken one), latest -nightly has the offeding patch take out already, so should work again. Can you please retest?

(In reply to comment #8)
> Chris patch is on top of the old tree (the broken one), latest -nightly has
> the offeding patch take out already, so should work again. Can you please
> retest?

Yeah, I build a kernel with the top commit on -nightly branch, the case passed.

commit : 3fe1b3064d39c0930796aaae81c44f9e8a5264bd

Is this RESOLVED FIXED?

(In reply to comment #10)
> Is this RESOLVED FIXED?

Nope, offending patch was only taken out, we still need to fix up seqno wrapping for real. So I think we can keep this one here around as a reminder.

commit f72b3435c1a75406d82d6e252bb78f009efd4bd9
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Mon Dec 10 15:41:48 2012 +0200

and subsequent patches have landed, should be ok to close now?  Yangwei, can you confirm?

(In reply to comment #12)
> commit f72b3435c1a75406d82d6e252bb78f009efd4bd9
> Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Date:   Mon Dec 10 15:41:48 2012 +0200
> 
> and subsequent patches have landed, should be ok to close now?  Yangwei, can
> you confirm?

I have tested this commit, these two cases worked well.
We can close this bug now.

Closing old verified.