on failed kernel, if disable psr feature via "i915.enable_psr=0" parameter, x can start successfully.

This is surprising. Assigning to Rodrigo.

Anything special in the logs?

Wendy, can you please attach Xorg logs and dmesg with drm.debug=0x6?

Also FWIW, I can't reproduce this locally.

Created attachment 96080 [details]
Xorg log

Attached Xorg.o.log and dmesg log file.

Created attachment 96081 [details]
dmesg log file

Issue cannot reproduce on another more re-worked BDW system(Rework ID: R09,R11,R12,F29, R14,R15), so this is should be single old non-worked BDW board failure, so can close this issue as not kernel code bug.

I checked tested two BDW system difference as below:

The good system CPU is x-bdw05 with GT2
x-bdw05 : stepping 3(BIOS stepping D) (id=0x1606 (rev 06)), Lynx Point 01 (B0 stepping) and Host bridge id=0x1604 (rev 06) 2Cores/4Thread, CPU Genuine Intel(R) CPU 0000 @ 1.80GHz, GT2 200MHz; BIOS version: V67.R01; KSC version: V1.16; BDW_ULT_PremiumBDW U_Preprod_acm2661_VME_1.5MB_Unified_BIOS-67.1_ME-10.0.20.1198(Spi Full) 


The fail system CPU is x-bdw04 with GT1
x-bdw04: stepping 3 (BIOS stepping D)(id=0x1606 (rev 06)), Lynx Point 02 (B0 stepping) and Host bridge id=0x1604 (rev 06) 2Cores/4Thread, CPU Genuine Intel(R) CPU 0000 @ 1.60GHz, GT1 100MHz; BIOS version: V67.R01; KSC version: V1.13; 
BDW_ULT_PremiumBDW U_Preprod_acm2661_VME_1.5MB_Unified_BIOS-67.1_ME-10.0.20.1198(Spi Full)

Hi Wendy, could you please test if you can reproduce a similar issue on this machine with this branch: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=psr-baytrail

Thanks

Hi Rodrigo,
I verified your branch kernel:  http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=psr-baytrail, on my broken BDW SUT, cannot produce this issue, thanks.

Used kernel detail info: 
[root@x-bdw04 ~]# cat /proc/cmdline
BOOT_IMAGE=kernels//prts/d85f8b99bf0e8d218260e86de31b6b022acd4f18/bzImage_x86_64_debug root=/dev/sda4 drm.debug=0xe i915.enable_psr=1 modules_path=kernels//prts/d85f8b99bf0e8d218260e86de31b6b022acd4f18/modules_x86_64_debug/lib/modules/3.14.0-rc7_prts_d85f8b_20140326_debug acpi_rsdp=0xab7e1014 kexec_jump_back_entry=0x7a81015f

Hi Rodrigo,
Can you educate me why apply below patch, this issue can be fixed on my previous failed BDW SUT?

> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 6f767e5..89d5b41 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1608,7 +1608,7 @@ static void intel_edp_psr_enable_source(struct intel_dp *intel_dp)
>  	struct drm_device *dev = intel_dp_to_dev(intel_dp);
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  	uint32_t max_sleep_time = 0x1f;
> -	uint32_t idle_frames = 1;
> +	uint32_t idle_frames = 0xf;
>  	uint32_t val = 0x0;
>  	const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>  
> --
> 1.9.1
>

Wendy please don't just close a bug. Bugs should only be closed once a fix has landed in one of the usptream git repositories. Assigning back to Rodrigo.

Wendy do you still have any issue here? AFAIK, you have the one platform that failed.

This is not a regression, it's simple a bug with a specific panel when we enabled the PSR functionality. Lowering the importance, and renaming.

(In reply to comment #12)
> Wendy do you still have any issue here? AFAIK, you have the one platform
> that failed.

The failed platform still can reproduce this issue, used kernel is:
Linux x-bdw01 3.15.0-rc8_drm-intel-nightly_969b3c_20140610+ #3410 SMP Tue Jun 10 11:24:32 CST 2014 x86_64 x86_64 x86_64 GNU/Linux

(In reply to comment #13)
> This is not a regression, it's simple a bug with a specific panel when we
> enabled the PSR functionality. Lowering the importance, and renaming.

Yes, this is the single unit failure.

The issue remain as expect... 
Patches that fix that are still on review cycle :(

If features we have currently disabled cause issues when enabled, then this must be tracked as a regression.

That includes our entire driver btw, e.g. when vesa works but i915 doesn't load properly.

There are a rework with proper frontbuffer tracking landing, but I believe that the stuff that landed already fixed this bug already.

So, please verify if the issue is already fixed on -nightly

Then disable acceleration to simulate handling a GPU hang, and see that it is not.

Accurate frontbuffer render tracking should be upstream now, ready for testing.

I retest. It works well on latest -nightly

Closing verified+fixed.