With modesetting issues, always attach a drm.debug=0xe [at least] dmesg, so we know what we are dealing with. I suspect this will be another eDP, probably PCH_eDP, for which KMS is under active development.

Downgrading priority based on my eDP presumption and the likelihood that it will not get fixed within until we have eDP solid in -next and can start looking to backport fixes.

Created attachment 38958 [details]
dmesg with drm.debug=0xe 

The output type we used is VGA.

[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] probed modes :
[drm:drm_mode_debug_printmodeline], Modeline 24:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 22:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 21:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 23:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 20:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa

Ok, they look like the default set of modes, so I guess an EDID read failure and we never apply a modeline the monitor can use.

This should restore the probing:

commit cb8ea7527b813dd6e19fb07328f7867a5f0a8d0a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 28 13:35:47 2010 +0100

    drm/i915: Use i2c bit banging instead of GMBUS
    
    There are several reported instances of GMBUS failing to successfully
    read the EDID, so revert back to bit banging until the issue is
    resolved.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30371
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Using [SNB] as the tag for bugs specific to Sandybridge hardware.

I guess this is the -next regression mentioned by Zhenyu?

Promoting to P1, since SNB testing is moving to -next. It works with .36-rc7.

The issue still there. The screen turns to black when KMS step.

(In reply to comment #4)
> This should restore the probing:
> commit cb8ea7527b813dd6e19fb07328f7867a5f0a8d0a
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Tue Sep 28 13:35:47 2010 +0100
>     drm/i915: Use i2c bit banging instead of GMBUS
>     There are several reported instances of GMBUS failing to successfully
>     read the EDID, so revert back to bit banging until the issue is
>     resolved.
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30371
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Chris, any update?

I can say that the SNB machine here successfully probed the EDID on the VGA. I will have to endure the noise to actually see whether the screen is no longer blank... But I suspect that it will require some of Zhenyu's FDI patches first.

We tried the latest kernel on drm-intel-next branch. The blank issue is fixed. But the KMS doesn't work. The KMS issue just likes the one on Piketon described by bug 31282.

Marking this bug as closed for the time being. We can come back to this if fixing 31282 is not sufficient.

The KMS doesn't work. Just VGA mode after kernel boot up. The dmesg information is:
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 00000000 head 00000000 tail 00000000 start 00000000
[drm:i915_driver_load] *ERROR* failed to init modeset

(In reply to comment #12)
> The KMS doesn't work. Just VGA mode after kernel boot up. The dmesg information
> is:
> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 00000000
> head 00000000 tail 00000000 start 00000000
> [drm:i915_driver_load] *ERROR* failed to init modeset

That's a completely different bug, so please file it separately and include an lspci. I am being evil and just seeing how many people had SNB machines that only ever returned 0 from the ring registers and forgot to mention it.

Ok,so verified it and file a new bug to track it.

Closing old verified.