Created attachment 76961 [details] Results of git bisect From 3.2.20 until now (3.5), booting in a MacBookAir5,1 will consistently result in a blank (as empty, not as power off) screen. Trying to start X does not make any difference. I did a git bisect and found the line causing me problems. Reverting that line fixes the problem, but I don't think it's a solution, as it generates a lot of warnings about "eDP powered off while attempting aux channel communication".
Created attachment 76971 [details] Output of lspci -nn
Created attachment 76981 [details] Patch which solves the problem but generates lots of warnings
Created attachment 76991 [details] dmesg of kernel 3.5 before patching
Created attachment 77001 [details] dmesg of kernel 3.5 after patching
For reference, is the below patch (respectively the backport of it to 3.2) the one causing your regression? commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel We have one bug report from a validation team that we get the eDP panel sequencing still somewhat wrong: We need to enable VDD while switching off the panel and backlight. Unfortunately that reporter seems to have fallen off the earth :( For another reporter this actually fixes a black panel issue because without this the backlight/panel gets confused and doesn't light up again. v2: I've forgotten to remove the vdd_off call in panel_off which is now bogus. This essentially reverts commit 17038de5f16569a25343cf68668f3b657eafb00e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 16 22:43:42 2012 +0100 drm/i915/dp: Flush any outstanding work to turn the VDD off v3: the current panel_off code forces off the vdd power, too. Which is bogus and resulted in some funny warnings later on when we've tried to do aux channel communications with just the vdd forced on. Fix this, too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163 Tested-by: Vincent Frentzel <zcecc22@gmail.com> Cc: stable@kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Another thing: Does a modeset sequence resurrect the screen? E.g. crtc switching with $ xrandr --output eDP1 --auto crtc 1 $ xrandr --output eDP1 --auto crtc 0
Also, can you please boot with drm.debug=0xe added to your kernel cmdline (doesn't matter whether with patch or without) on 3.5 and attach the full dmesg?
Created attachment 77031 [details] edp panel off after dp sink off ... and a quick patch for you to test (instead of the FORCE_VDD hack).
btw, if the above patch doesn't work, please also test it together with your FORCE_VDD hack.
(In reply to comment #6) > Another thing: Does a modeset sequence resurrect the screen? E.g. crtc > switching with > > $ xrandr --output eDP1 --auto crtc 1 > $ xrandr --output eDP1 --auto crtc 0 These commands gave me error, so I tried with: $ xrandr --output eDP1 --auto --crtc 0 $ xrandr --output eDP1 --auto --crtc 1 That worked, but not always. I did some tests and I think it is time-related. Waiting over a minute after the machine boots to run these commands generally does the trick.
While you go through all the variations for testing: Can you please also test the modeset-rework branch from git://people.freedesktop.org/~danvet/drm ? That git branch fixes a modeset sequence issue for ivb cpu edp (which is rather likely what you have, but I need the drm.debug dmesg to confirm).
(In reply to comment #5) > For reference, is the below patch (respectively the backport of it to 3.2) > the > one causing your regression? > > commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Sun May 20 17:14:50 2012 +0200 > > drm/i915: enable vdd when switching off the eDP panel > > We have one bug report from a validation team that we get the eDP > panel sequencing still somewhat wrong: We need to enable VDD while > switching off the panel and backlight. Unfortunately that reporter > seems to have fallen off the earth :( > > For another reporter this actually fixes a black panel issue because > without this the backlight/panel gets confused and doesn't light up > again. > > v2: I've forgotten to remove the vdd_off call in panel_off which is > now bogus. This essentially reverts > > commit 17038de5f16569a25343cf68668f3b657eafb00e > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Mon Apr 16 22:43:42 2012 +0100 > > drm/i915/dp: Flush any outstanding work to turn the VDD off > > v3: the current panel_off code forces off the vdd power, too. Which is > bogus and resulted in some funny warnings later on when we've tried to > do aux channel communications with just the vdd forced on. Fix this, > too. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312 > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163 > Tested-by: Vincent Frentzel <zcecc22@gmail.com> > Cc: stable@kernel.org > Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> > Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Yes, it is. Reverting this patch on a 3.5 kernel makes the screen work again.
Created attachment 77041 [details] dmesg of kernel 3.5 with drm.debug=0xe
(In reply to comment #13) > Created an attachment (id=77041) [details] > dmesg of kernel 3.5 with drm.debug=0xe Yep, cpu edp.
(In reply to comment #8) > Created an attachment (id=77031) [details] > edp panel off after dp sink off > > ... and a quick patch for you to test (instead of the FORCE_VDD hack). The screen goes blank with this patch.
(In reply to comment #11) > While you go through all the variations for testing: Can you please also test > the modeset-rework branch from git://people.freedesktop.org/~danvet/drm ? > > That git branch fixes a modeset sequence issue for ivb cpu edp (which is > rather > likely what you have, but I need the drm.debug dmesg to confirm). With this kernel the screen goes also blank, but in this case, it goes blank as in power off. I'm going to attach a dmesg with drm.debug=0xe for this kernel, maybe it is useful.
Created attachment 77081 [details] dmesg of kernel 3.5, branch modeset_rework with drm.debug=0xe
Created attachment 77101 [details] new trial at reordering the edp off sequence Please test this new patch, thanks.
(In reply to comment #9) > btw, if the above patch doesn't work, please also test it together with your > FORCE_VDD hack. Just for the record, I tried your first patch with my FORCE_VDD hack and it worked without warnings. I'm going to attach a dmesg with drm.debug=0xe, just in case.
Created attachment 77141 [details] dmesg of kernel 3.5 with first patch and FORCE_VDD hack
(In reply to comment #18) > Created an attachment (id=77101) [details] > new trial at reordering the edp off sequence > > Please test this new patch, thanks. Tried this patch, and works, but generates warnings about "Need VDD to turn off panel". I'm going to attach a dmesg with drm.debug=0xe about it.
Created attachment 77151 [details] dmesg of kernel 3.5 with second patch
Created attachment 77161 [details] reorder edp panel off Hopefully final patch, please test. Unfortunately the reporter of the other bug is travelling, so we can't test that. But since this here is a regression, it has priority. I've we're unlucky, I need to bugger you again if this patch here breaks the other machine again, but I'm hopeful that that won't happen.
(In reply to comment #23) > Created an attachment (id=77161) [details] > reorder edp panel off > > Hopefully final patch, please test. Unfortunately the reporter of the other > bug > is travelling, so we can't test that. But since this here is a regression, it > has priority. I've we're unlucky, I need to bugger you again if this patch > here > breaks the other machine again, but I'm hopeful that that won't happen. Sorry, but it seems this patch makes the screen blank again like when I reported the bug (as in empty, not as in power off). I'm going to attach a dmesg with drm.debug=0xe, just in case.
Created attachment 77251 [details] dmesg of kernel 3.5 with third patch
Created attachment 77271 [details] reorder edp panel off v2 ok, the clearing of force_vdd seems to be the crucial thing here ... please test.
(In reply to comment #26) > Created an attachment (id=77271) [details] > reorder edp panel off v2 > > ok, the clearing of force_vdd seems to be the crucial thing here ... please > test. This one works, but unfortunately generates warnings. The warnings say "eDP powered off while attempting aux channel communication". This is the same warning it generated when I applied only my hack. I'm going to attach another dmesg. I'm not sure if the dmesg are useful, please tell me if they are not.
Created attachment 77351 [details] dmesg of kernel 3.5 with fourth patch
Created attachment 77381 [details] patch v3 New patch, v2 assumed that the panel is left behind by the Apple in an enabled state. The new patch hopefully rectifies that. Please test. Fyi, dmesg with drm.debug=0xe is perfect in case something in the edp panel power code blows up.
I have tested patch v3 but it doesn't work. Unfortunately, at this point I am not able to add the dmesg. The remote login doesn't work yet.
(In reply to comment #29) > Created an attachment (id=77381) [details] > patch v3 > > New patch, v2 assumed that the panel is left behind by the Apple in an > enabled > state. The new patch hopefully rectifies that. Please test. > > Fyi, dmesg with drm.debug=0xe is perfect in case something in the edp panel > power code blows up. This one seems to work perfectly. Boots correctly with no warnings. Thanks you a lot for all your efforts! Out of curiosity, why did you discard the combination of your first patch (edp panel off after dp sink off) and the FORCE_VDD hack? It appeared to work, without warnings. It could create problems to other users? Also, sometimes, after suspending the laptop, when I try to wake it up after a few hours, it comes back, but the screen remains blank as in power off. May it be related? Should I fill another bug report?
I got it working now too. In my previous post I did apply it on top of drm-intel-next with the default platform configuration from the kernel. In the working configuration, I applied it on top of Linus' tree with the Fedora configuration. I'll rebuild the drm-intel-next tree with the Fedora configuration to rule out some problems with the settings.
(In reply to comment #31) > This one seems to work perfectly. Boots correctly with no warnings. Thanks > you > a lot for all your efforts! Thanks for testing! I'll wait with applying the patch until Daniel confirmed that it works on -next, too. > Out of curiosity, why did you discard the combination of your first patch > (edp > panel off after dp sink off) and the FORCE_VDD hack? It appeared to work, > without warnings. It could create problems to other users? The new patch _is_ the first one + hack, but (hopefully) done right. > Also, sometimes, after suspending the laptop, when I try to wake it up after > a > few hours, it comes back, but the screen remains blank as in power off. May > it > be related? Should I fill another bug report? We have other issues with cpu edp on ivb, could be that you're hitting those. Can you still ssh into the machine once the screen comes up black after resume?
(In reply to comment #33) > (In reply to comment #31) > > This one seems to work perfectly. Boots correctly with no warnings. Thanks > you > > a lot for all your efforts! > > Thanks for testing! I'll wait with applying the patch until Daniel confirmed > that it works on -next, too. > > > Out of curiosity, why did you discard the combination of your first patch > (edp > > panel off after dp sink off) and the FORCE_VDD hack? It appeared to work, > > without warnings. It could create problems to other users? > > The new patch _is_ the first one + hack, but (hopefully) done right. > > > Also, sometimes, after suspending the laptop, when I try to wake it up > after a > > few hours, it comes back, but the screen remains blank as in power off. May > it > > be related? Should I fill another bug report? > > We have other issues with cpu edp on ivb, could be that you're hitting those. > Can you still ssh into the machine once the screen comes up black after > resume? Yes, I can. It happened a few hours ago and I logged in and saw a dmesg with a drm.debug=0xe (that I forgot to save, damn). It showed no warnings. I can add that option to GRUB, wait until it happens again and mail you that dmesg (or other info), if you want.
(In reply to comment #34) > Yes, I can. It happened a few hours ago and I logged in and saw a dmesg with > a > drm.debug=0xe (that I forgot to save, damn). It showed no warnings. I can add > that option to GRUB, wait until it happens again and mail you that dmesg (or > other info), if you want. Ok, then please grab the latest git tree of intel-gpu-tools at http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ and grab the output of intel_reg_dumper after the screen has stuck to black. Then please open a new bug report (together with the debug dmesg) at bugs.freedesktop.org.
patch v3 on top of drm-linux-next with Fedora configuration: The backlight is not on, but I see that contents is drawn, e.g. the KDM is started and drawn. Now I might be able to retrieve the dmsg. Just a sec.
I have troubles to create the log. I am able to login to the box but after a short time it freezes or crashes. I can't tell. I'll retry to get the log, I need to be fast enough.
Created attachment 77461 [details] patch v3 on top of drm-intel-next This is the dmesg with patch "drm/i915: reorder edp disabling to fix ivb MacBook Air" on top of drm-linux-next (drm/i915: don't grab dev->struct_mutex for userspace forcewak) The system boots and X is started though the back light is missing. After a while the system either hangs or panics and the screen goes blank. No network connection at this point.
Hm, drm-linux-next is at a totally different baseline atm (3.5-rc4 compared to to Linux tree at 3.6-rc1) so this could be anything. Also, not all i915 fixes in Linus' tree are included in -next. So I think the patch is good, and you're crashes something else. Thanks to everyone for reporting this issue.
A patch referencing this bug report has been merged in Linux v3.6-rc2: commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air