Can you try an older kernel and see if it is a regression?  If so, can you bisect?

(In reply to Jesse Barnes from comment #1)
> Can you try an older kernel and see if it is a regression?  If so, can you
> bisect?

Test older kernel,system also hang
test commit: drm-intel-nightly/ea4bec8e96ea8b33b49a7892c1c7f20041a56da6(drm-intel-nightly: 2014y-10m-09d-07h-58m-45s), ctrl+c, it doesn't exit testing, run reboot,system is no response, 
output:
IGT-Version: 1.9-g9846e7f (x86_64) (Linux: 3.17.0_drm-intel-nightly_ea4bec_20141010+ x86_64)

^C^C^C^C^C^C^C^C^C^C

Test commit: 07d0c831d9207c937595f081c8fddbddbf53756f(drm-intel-nightly: 2014y-12m-30d-13h-01m-34s), system also hang.
output:
IGT-Version: 1.9-g9846e7f (x86_64) (Linux: 3.19.0-rc2_drm-intel-nightly_07d0c8_20150104+ x86_64)
Testing connector eDP-1 using pipe A
(kms_universal_plane:5213) CRITICAL: Test assertion failure function functional_test_pipe, file kms_universal_plane.c:270:
(kms_universal_plane:5213) CRITICAL: Failed assertion: igt_crc_equal(&test.crc_1, &test.crc_5)
Subtest universal-plane-pipe-A-functional: FAIL (2.434s)
Subtest universal-plane-pipe-A-sanity: SUCCESS (1.120s)

Created attachment 114146 [details]
dmesg log file

Re-test with latest drm-intel-nightly branch kernel:
Linux x-skly03 4.0.0-rc2_drm-intel-nightly_c2f6e5_20150307+ #238 SMP Sat Mar 7 09:01:15 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

IGT case kms_universal_plane will not cause system hang, but has call trace.
(dmesg log file attached.)


[   82.281340] Call Trace:
[   82.284867]  [<ffffffff8133ebf9>] ? vsnprintf+0x83/0x3b9
[   82.288441]  [<ffffffffa0080ceb>] ? skl_update_wm+0xfa/0x5cc [i915]
[   82.291981]  [<ffffffff8106f2f9>] ? print_time.part.10+0x50/0x54
[   82.295541]  [<ffffffff8106f89e>] ? print_prefix+0x81/0x89
[   82.299152]  [<ffffffffa00ca9bd>] ? intel_begin_crtc_commit+0x12e/0x165 [i915]
[   82.302749]  [<ffffffffa00527bf>] ? drm_plane_helper_commit+0xd6/0x224 [drm_kms_helper]
[   82.306370]  [<ffffffff810e4f8c>] ? kmemdup+0x18/0x2c
[   82.310003]  [<ffffffffa000f3db>] ? __setplane_internal+0x45/0x2b1 [drm]
[   82.313643]  [<ffffffffa00182f0>] ? drm_modeset_lock_all_crtcs+0x69/0x81 [drm]
[   82.317309]  [<ffffffffa000fa8c>] ? drm_mode_setplane+0x17f/0x1dc [drm]
[   82.321000]  [<ffffffffa00047d4>] ? drm_ioctl+0x344/0x3b3 [drm]
[   82.324688]  [<ffffffffa0006054>] ? drm_wait_one_vblank+0x14c/0x16d [drm]
[   82.328411]  [<ffffffffa000f90d>] ? drm_mode_cursor_common+0x140/0x140 [drm]
[   82.332112]  [<ffffffff8111fa82>] ? do_vfs_ioctl+0x360/0x424
[   82.335783]  [<ffffffff81112f13>] ? __sb_end_write+0x24/0x52
[   82.339430]  [<ffffffff81111331>] ? vfs_write+0x168/0x186
[   82.343109]  [<ffffffff8111fb8f>] ? SyS_ioctl+0x49/0x7a
[   82.346779]  [<ffffffff81798e92>] ? system_call_fastpath+0x12/0x17
[   82.350472] Code: 80 b0 00 00 00 89 45 04 48 8b 83 78 07 00 00 8b 80 98 00 00 00 c6 45 19 01 89 45                                                 08 48 8b 43 70 48 8b 80 38 02 00 00 48 8b 40 10 <8b> 80 84 00 00 00 99 f7 f9 88 45 18 48 8b 83 78 07 0                                                0 00 8b 80
[   82.354511] RIP  [<ffffffffa00804c5>] skl_update_pipe_wm+0x7c/0x507 [i915]
[   82.358393]  RSP <ffff880143bdf998>
[   82.362288] CR2: 0000000000000084

We just merged some SKL fixes that may affect all display-related tests. Please retest this bug against the latest drm-intel-nightly.

(In reply to wendy.wang from comment #4)
> Re-test with latest drm-intel-nightly branch kernel:
> Linux x-skly03 4.0.0-rc2_drm-intel-nightly_c2f6e5_20150307+ #238 SMP Sat Mar
> 7 09:01:15 EST 2015 x86_64 x86_64 x86_64 GNU/Linux
> 
> IGT case kms_universal_plane will not cause system hang, but has call trace.
> (dmesg log file attached.)

Can you test with the latest drm-intel-nightly, plus the patch from http://patchwork.freedesktop.org/patch/44302/ and see if it resolves the issue?

(In reply to Matt Roper from comment #6)
> (In reply to wendy.wang from comment #4)
> Re-test with latest
> drm-intel-nightly branch kernel:
> Linux x-skly03
> 4.0.0-rc2_drm-intel-nightly_c2f6e5_20150307+ #238 SMP Sat Mar
> 7 09:01:15
> EST 2015 x86_64 x86_64 x86_64 GNU/Linux
> 
> IGT case kms_universal_plane
> will not cause system hang, but has call trace.
> (dmesg log file attached.)
> Can you test with the latest drm-intel-nightly, plus the patch from
> http://patchwork.freedesktop.org/patch/44302/ and see if it resolves the
> issue?

Call trace issue still exist with this patch, maybe will not hapen first time you run this case after boot, maybe twice or more will reproduce this issue.

Created attachment 114193 [details]
dmesg with nightly branch 20150310

root@x-skly03:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# dmesg -r | egrep "<[1-4]>" |grep drm
<4>[  141.410057] WARNING: CPU: 0 PID: 5172 at drivers/gpu/drm/i915/intel_dp.c:658 intel_dp_aux_ch+0xaa/0x57f [i915]()
<4>[  141.410062] Modules linked in: dm_mod snd_hda_codec_realtek snd_hda_codec_generic ppdev snd_hda_intel snd_hda_controller i2c_i801 pcspkr snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore wmi battery parport_pc parport ac acpi_cpufreq i915 button video drm_kms_helper drm
<4>[  141.410241]  [<ffffffffa00515db>] ? drm_dp_dpcd_access+0x5b/0xed [drm_kms_helper]
<4>[  141.410250]  [<ffffffffa0051680>] ? drm_dp_dpcd_read+0x13/0x17 [drm_kms_helper]
<4>[  141.410336]  [<ffffffffa0051e88>] ? drm_helper_probe_single_connector_modes_merge_bits+0xc4/0x395 [drm_kms_helper]
<4>[  141.410354]  [<ffffffffa000ef5d>] ? drm_mode_getconnector+0xda/0x2aa [drm]
<4>[  141.410369]  [<ffffffffa00047d4>] ? drm_ioctl+0x344/0x3b3 [drm]
<4>[  141.410391]  [<ffffffffa000ee83>] ? drm_mode_getcrtc+0xfe/0xfe [drm]
<4>[  141.410405]  [<ffffffffa0003b60>] ? drm_gem_vm_close+0x2a/0x4b [drm]
root@x-skly03:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# dmesg -r | egrep "<[1-4]>" |grep call
<4>[  141.410424]  [<ffffffff81799972>] ? system_call_fastpath+0x12/0x17

Based on the dmesg's attached, it looks like we've actually fixed the original problem (a BUG() due to NULL pointer dereference) and the message you're seeing now is a WARN() caused by a completely different issue.

(In reply to Matt Roper from comment #9)
> Based on the dmesg's attached, it looks like we've actually fixed the
> original problem (a BUG() due to NULL pointer dereference) and the message
> you're seeing now is a WARN() caused by a completely different issue.

pls refer to(In reply to Matt Roper from comment #9)
> Based on the dmesg's attached, it looks like we've actually fixed the
> original problem (a BUG() due to NULL pointer dereference) and the message
> you're seeing now is a WARN() caused by a completely different issue.

submmit a new bug for this, pls refer to Bug 89552.

Old bug fixed, new bug filed. Thanks.

Closing old verified+fixed.