Bug 43163

Created attachment 73083 [details]
dmesg

Created attachment 73084 [details]
Kernel Configuration

Can you do a quick bisect between 3.3.1 and 3.3.3 to figure out which patch broke things for you please?

Also please boot with drm.debug=0xe attached to your kernel cmdline and attach the complete dmesg.

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

I am having issues recreating the problem. It seems that the black screen is
coming only when the computer is booted up (not restarted) and now even from a
cold start I cannot get it to appear.

Typically my computer is off overnight and I turn it on the next day, the
problem always appear in that case. I dont know how to interpret this, could it
be due to some RAM not being erased in between restart that allows the card to
work properly?

For information, I am starting the system with UEFI/GRUB 2.

So when you boot up and get a black screen, then immediately reboot, it works (for the rest of the day)?

That s how it seems to be. Maybe the bug is hard to reproduce and I'm so far unlucky but in the last couple days I got it on every cold boots.

Actually when I get a black screen i log in and start X, the screen then is fine. If I get a black screen and issue Ctrl alt del (immediate reboot) the black screen is still there.

Starting X once seems to fix it for the whole day. 

What baffles me is that if I power down the computer now and boot up the black screen is not appearing.

Does that make any sense?

Bugs never make sense until it's tracked down and fixed ...

I guess we first need to figure out how to reliably reproduce this, otherwise we wont know when it's fixed. I've got an idea though, I'll dig up a patch for you to try.

Well, just a link to the patch:

https://bugs.freedesktop.org/attachment.cgi?id=60102

Created attachment 73092 [details]
dmesg with edp power seq fix patch

No black screen seen during this step.

Created attachment 73100 [details]
black screen after switching display back to laptop screen at 17:31:41

I could nt reproduce the black screen on boot today. However it showed up at 17:31:41 when I switched from my external display back to the internal one. I had to switch back and forth several times with Xrandr (5+) before getting the internal display working again. The trick was to get back to tty with ctrl+alt+f1 with screen still black and then going back to X and switching screen again.

The screen is on at 17:34:38 in attached syslog.

Just to check: Is that with the patch or without it?

Without it.

I have been banging my head on how to reproduce the bug consistently and made some progress.

It seems that when I switch to external display only for some *time* then going back to the laptop display triggers the black screen. I emphasize time as going back immediately to the laptop display after external works without issue.

I believe that there is a connection between screen on/off, resolution changes that causes the black screen. Which would explain why I get it during boot and after switching display with XrandR.

I will test if the bug appears with the proposed patch. If you can find a way to reproduce the bug in a shorter timeframe (couple of hours currently)I can run the bisect.

So far proposed patch seems to do the trick. No black screens observed in the last day. dmesg (see attached) reports some warning with stack traces tho, but did not observe anything on screen.

Can you please attach the dmesg with these stacktraces? And please keep on testing the patch until you're sure that it indeed fixes the problem.

Already attached please see https://bugzilla.kernel.org/attachment.cgi?id=73092 starting at 2.425297 for drm init. I get them everytime I switch display with XRandR. I am not sure what those are as everything works fine.

[    2.661578] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1152 ironlake_edp_panel_off+0xd6/0xe0()
[    2.661581] Hardware name: Latitude E6410
[    2.661583] Cannot turn power off while VDD is on

Ok, these are expected because the debug patch doesn't update all the checks in the code with the new edp panel sequencing.

Everything clear on my end, I believe the patch proposed adresses the issue.

Reopen because the patch hasn't landed yet. And I need to clean it up so that it doesn't spew WARN noise into dmesg.

Please don't close this bug until a fix has landed in Linus' kernel tree (or is on track to get there), thanks.

Created attachment 73243 [details]
(hopefully) final patch

Ok, I've cleaned up the code and adjusted the WARN to be correct with the new logic. Please test quickly and check whether it still works and whether the WARN backtrace is indeed gone.

As soon as I have your tested-by, I can include the patch for 3.5, and when it's there it'll get backported.

I get a patch does not apply error.

I tried applying it against v3.3.3 and MASTER


git apply --check ../0001-drm-i915-enable-vdd-when-switching-off-the-eDP-panel.patch

> error: patch failed: drivers/gpu/drm/i915/intel_dp.c:1154
> error: drivers/gpu/drm/i915/intel_dp.c: patch does not apply

Am I missing something here?

Created attachment 73250 [details]
patch against 3.4-rc

Daniel, please, could you provide more information as to how to apply this patch correctly?

I am applying on 3.4-rc6 fresh tarball from kernel.org. No luck.

I am sure you used diff against something but I obviously dont have the same...

3.4-rc[1? 2? 3? 4?...]

patch -p1 --dry-run < 0001-drm-i915-enable-vdd-when-switching-off-the-eDP-panel.patch 
patching file drivers/gpu/drm/i915/intel_dp.c
Hunk #1 FAILED at 1154.
Hunk #2 succeeded at 1259 (offset -7 lines).
Hunk #3 succeeded at 1300 (offset -7 lines).
1 out of 3 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_dp.c.rej

Duh nevermind. Got the new attachment (did nt spot it). Apologies. Will come back after compilation.

Created attachment 73251 [details]
dmesg 3.4rc6 + patch

Still some noise in dmesg.


[    1.379799] ------------[ cut here ]------------
[    1.379811] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5e/0xb0()
[    1.379814] Hardware name: Latitude E6410
[    1.379816] eDP powered off while attempting aux channel communication.
[    1.379819] Modules linked in:
[    1.379824] Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc6-red34-p #1
[    1.379827] Call Trace:
[    1.379833]  [<ffffffff813108de>] ? intel_dp_check_edp+0x5e/0xb0
...

Can you please paste the entire backtrace?

Nevermind, I've noticed the attached dmesg ;-)

Created attachment 73335 [details]
patch against 3.4-rc, version 3

Ok, I've noticed something else that needs to be fixed, please test.

Created attachment 73343 [details]
dmesg for v3 patch

dmesg now looks clean. I attached it for review.

A patch referencing this bug report has been merged in Linux v3.5-rc1:

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

Created attachment 77111 [details]
new patch to test

Hi Vincent,

The patch that fixes your machine unfortunately breaks some MacBook Airs, so we need to find a different solution. Can you please test this patch (on top of the current fixes) to ensure that we don't break your system again?

Thanks, Daniel

Hi Daniel, no issue. I am currently on the road and can proceed with the test on the 20th of august.

Cheers,
V

Created attachment 77281 [details]
reorder edp panel off v2

Please test this patch instead of the older one, that didn't work out for the macbook air regression. Again, I'm hopeful that this won't blow up on your machine ...

Hi Daniel,

Could you let me know against which version to patch? 3.6rc2, 3.5.2, ... ?

Created attachment 77911 [details]
dmesg with proposed patch.

Everything is working fine nothing out of the ordinary.

The dmesg has some debug messages for your review.

V

Yeah, the final patch fixed the dmesg noise. If 3.6-rc2 works out for you, everthing's still good (since the new patch landed in -rc2).

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