Created attachment 116302 [details] dmesg info ==System Environment== ----------------------------------------------------- Regression: Yes Non-working platforms: HSW GT2 ==Kernel== -------------------------------------------------- commit 0761e2d5d55e8311950514fda1ec414838525985 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Jun 4 16:19:46 2015 +0300 drm-intel-nightly: 2015y-06m-04d-13h-19m-27s UTC integration manifest ==Bug detailed description== -------------------------------------------------- Black screen after boot up machine on the latest nightly and next-queued kernel, It does not exists on drm-intel-fixes branch. ==Reproduce steps== ---------------------------- 1, boot up machine
This might be related to the latest round of atomic patches that went in. A dmesg with 'drm.debug=0x1e buf_log_len=4M" would probably help. Note the extra '1' in drm.debug for atomic. Also please bisect. If this is indeed caused by that latest series, nightly from a few days ago should be a good starting point.
(In reply to Ander Conselvan de Oliveira from comment #1) > dmesg with 'drm.debug=0x1e buf_log_len=4M" would probably help. Sorry, I meant 'drm.debug=0x1e log_buf_len=4M' .
By bisected, shows the first bad commit is 3bae26e. commit 3bae26eb2991c00670df377cf6c3bc2b0577e82a Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> AuthorDate: Mon Jun 1 12:50:03 2015 +0200 Commit: Jani Nikula <jani.nikula@intel.com> CommitDate: Thu Jun 4 11:43:36 2015 +0300 drm/i915: Read hw state into an atomic state struct, v2. To make this work we load the new hardware state into the atomic_state, then swap it with the sw state. This lets us change the force restore path in setup_hw_state() to use a single call to intel_mode_set() to restore all the previous state. As a nice bonus this kills off encoder->new_encoder, connector->new_enabled and crtc->new_enabled. They were used only to restore the state after a modeset. Changes since v1: - Make sure all possible planes are added with their crtc set, so they will be turned off on first modeset. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Created attachment 116309 [details] dmesg info with drm.debug=0x1e log_buf_len=4M
Boot latest nightly 06-05 on BSW with eDP and DP connected, and both eDP and DP are black screen. If only eDP connected, It can works well. This issue also exists on SKL.
Could you test with http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=unify-flip-modeset ? If it doesn't work, drm.debug=0x1f please. :-)
*** Bug 90875 has been marked as a duplicate of this bug. ***
Created attachment 116324 [details] dmesg with drm.debug=0x1f log_buf_len=4M Didn't work for me.
Could you try booting with i915.fastboot=1 ?
Created attachment 116333 [details] dmesg with drm.debug=0x1e log_buf_len=4M i915.fastboot=1 No change. I should note that I took the your branch's additional commits and applied them to nightly.
This issue also exist on SNB.
Can I get the log with the commit before 3bae26eb2991c00670df377cf6c3bc2b0577e82a, and on 3bae26eb2991c00670df377cf6c3bc2b0577e82a ? So I can compare the differences.
Created attachment 116351 [details] dmesg good info (d57981d) with drm.debug=0x1f log_buf_len=4M
Created attachment 116352 [details] dmesg bad info (3bae26eb2) with drm.debug=0x1f log_buf_len=4M
Created attachment 116355 [details] [review] Copy hw settings to adjusted mode Examining things more closely I noticed this as the first difference.. Bad: [drm:intel_dump_pipe_config] requested mode: [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x0 0x5 [drm:intel_dump_pipe_config] adjusted mode: [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x5 Good: [drm:intel_dump_pipe_config] requested mode: [drm:drm_mode_debug_printmodeline] Modeline 0:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 [drm:intel_dump_pipe_config] adjusted mode: [drm:drm_mode_debug_printmodeline] Modeline 0:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 Could you test if this fixes the bug? If not attach a new log?
(In reply to Andreas Reis from comment #7) > *** Bug 90875 has been marked as a duplicate of this bug. *** Did you bisect and find the same culprit as this one? If not, please do so.
(In reply to Maarten Lankhorst from comment #15) > Created attachment 116355 [details] [review] [review] > Copy hw settings to adjusted mode > > Examining things more closely I noticed this as the first difference.. > > Bad: > [drm:intel_dump_pipe_config] requested mode: > [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 108000 1280 1328 1440 > 1688 1024 1025 1028 1066 0x0 0x5 > [drm:intel_dump_pipe_config] adjusted mode: > [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x5 > > Good: > [drm:intel_dump_pipe_config] requested mode: > [drm:drm_mode_debug_printmodeline] Modeline 0:"1280x1024" 60 108000 1280 > 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 > [drm:intel_dump_pipe_config] adjusted mode: > [drm:drm_mode_debug_printmodeline] Modeline 0:"1280x1024" 60 108000 1280 > 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 > > > Could you test if this fixes the bug? If not attach a new log? Test it on latest nightly kernel with the patch, This issue does not exists. But It will cause somes errors. please see the dmesg log. "[drm:check_crtc_state [i915]] *ERROR* mismatch in fdi_lanes (expected 2, found 4)" BTW, This issue does not exists on HSW with the latest nightly kernel.(rc6_drm-intel-nightly_d4f412_20150606+)
Created attachment 116356 [details] dmesg info with the patch
Created attachment 116359 [details] [review] Update more hw state when reading out. Slightly improved patch. I've noticed that vblank wasn't being setup correctly either, could you test this patch too? To get rid of the fdi_lanes warning you could try to apply the patch on top of http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=unify-flip-modeset ?
Created attachment 116364 [details] dmesg with drm.debug=0x1f log_buf_len=4M @Jani Nikula: Verified by bisection that it's indeed the same commit causing issues on my 4200U. The patch does not work for me, neither applied to current nightly + unify-flip-modeset (attached dmesg) nor applied to unify-flip-modeset only. NB: My 4770 (HDMI 1080p + HDMI 1440p on IGP) has a new minor issue: Now at boot only one screen shows the tty. If I start X and switch back to tty, both again show the same tty output. Since it's minor, nothing wrong in dmesg and for lack of time I won't test further if it's due to the same cause.
Created attachment 116365 [details] dmesg warnings Here's some warnings I only get on my 4200U when DRM&co. as are present as modules rather than compiled-in. nightly + unify-flip-modeset + patch, so dunno if actually related. With the modules I briefly see the tty, presumably until the driver takes over. An attached HDMI monitor works fine.
Also I just noticed by accident that if DPMS turns of the eDP screen (ie. manually: xset dpms force off) and turns it back on again, it just works…
(In reply to Maarten Lankhorst from comment #19) > Created attachment 116359 [details] [review] [review] > Update more hw state when reading out. > > Slightly improved patch. > > I've noticed that vblank wasn't being setup correctly either, could you test > this patch too? > > To get rid of the fdi_lanes warning you could try to apply the patch on top > of > http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=unify-flip-modeset ? Test it on the latest nightly with the patch. BSW: passed, does not have dmesg *ERROR* SNB: passed, still have demsg *ERROR*, pleae see the dmesg info. [drm:check_crtc_state [i915]] *ERROR* mismatch in pch_pfit.enabled (expected 0, found 1) SKL: Failed. please see the dmesg info.
Created attachment 116378 [details] dmesg info on SNB
Created attachment 116381 [details] dmesg info on SKL
(In reply to Andreas Reis from comment #22) > Also I just noticed by accident that if DPMS turns of the eDP screen (ie. > manually: xset dpms force off) and turns it back on again, it just works… Me too.
Yes, what's happening is that we preserve the initial mode as long as possible. It isn't always the best possibly mode, things like panel fitter may be needlessly enabled or too many fdi lanes are used wasting power. But please test on unify-flip-modeset, I've added a workaround that should force a modeset on initial hw readout if we believe optimal sw state doesn't match hw state. http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=unify-flip-modeset Does that fix things?
Created attachment 116394 [details] dmesg warnings with workaround Unfortunately not. No change except the warnings read a little differently.
Should be fixed by commit aee5624f3158be1aecd808351607d7a6ded09643 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed Jun 10 10:24:19 2015 +0200 Revert "drm/i915: Make intel_display_suspend atomic, v2." commit f662af8c5c1619b91e3834fff103e7423e20df81 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed Jun 10 10:24:20 2015 +0200 Revert "drm/i915: Read hw state into an atomic state struct, v2." please retest current drm-intel-nightly.
drm-intel-nightly: 2015y-06m-10d-13h-55m-57s 4770: The second HDMI monitor now shows the tty again & dmesg is clean. 4200U: Still black screen and worse, it now instantly enters an apparent livelock (boot freezes & cooling jumps to max) once the driver module loads.
More precisely: The display now freezes at whatever has already been printed when the driver inits, which is nothing if compiled-in and otherwise (as module) whatever systemd had printed to the tty.
Created attachment 116425 [details] dmesg warnings It's indeed the revert of the faulty "Read hw state" commit that causes the livelock. If reapplied I can boot again, though with attached dmesg warnings and the HDMI output now stays quiet entirely. Reapplying the other commit, both separately or in addition, does not make the latter work again.
Created attachment 116426 [details] archive, dmesg warnings If I'd seen the new commits in I could have spared you the prev three comments and instead reported that things are now – somewhat – working again. dmesg warnings in all cases: 4770: tty again not shown on boot on second HDMI, but when switching from X 4200U: eDP only: working as intended HDMI before boot: both screens black again, DPMS works HDMI after boot&X: working with different warnings See archive for dmesg excerpts.
(In reply to Jani Nikula from comment #29) > Should be fixed by > > commit aee5624f3158be1aecd808351607d7a6ded09643 > Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Date: Wed Jun 10 10:24:19 2015 +0200 > > Revert "drm/i915: Make intel_display_suspend atomic, v2." > > commit f662af8c5c1619b91e3834fff103e7423e20df81 > Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Date: Wed Jun 10 10:24:20 2015 +0200 > > Revert "drm/i915: Read hw state into an atomic state struct, v2." > > please retest current drm-intel-nightly. Test it on the latest nightly kernel (4.1.0-rc7_drm-intel-nightly_bae303_20150611), SNB/BDW/BSW/SKL can not boot up. we have file a bug 90929 tracking it.
(In reply to ye.tian from comment #34) > (In reply to Jani Nikula from comment #29) > > Should be fixed by > > > > commit aee5624f3158be1aecd808351607d7a6ded09643 > > Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Date: Wed Jun 10 10:24:19 2015 +0200 > > > > Revert "drm/i915: Make intel_display_suspend atomic, v2." > > > > commit f662af8c5c1619b91e3834fff103e7423e20df81 > > Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Date: Wed Jun 10 10:24:20 2015 +0200 > > > > Revert "drm/i915: Read hw state into an atomic state struct, v2." > > > > please retest current drm-intel-nightly. > > > Test it on the latest nightly kernel > (4.1.0-rc7_drm-intel-nightly_bae303_20150611), SNB/BDW/BSW/SKL can not boot > up. we have file a bug 90929 tracking it. SNB can boot up well.
Fixed on following kernel. http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=topic/bug-90929
Verified latest drm-intel-nightly branch kernel on BSW and SKL, this issue has been fixed, so closed.
Closing old verified.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.