Created attachment 74461 [details] messages.log booted with drm.debug=0xe Hi, i was advised to create a new report for my issue, so here it is: I have a problem booting the new Macbook Air 5,2 (Mid 2012). When udev runs and loads the i915 driver the screen flickers short and then turns black (two seconds without backlight, than the backlight turns on again, but the screen remains black) If i disable kms (by adding an unkown module option, like i915.diescreaming=1) it boots and with xf86-video-fbdev i'm also able to start X. I also noted that if i plug an external monitor to the thunderbolt/minidisplay port that (booting with enabled kms) the display gets on, right after the internal display turned off, but with the resolution of the internal display. I already tested this with the 3.4.4 kernel (default archlinux kernel) and the 3.5 mainline kernel. I don't know if it matters, but i'm starting linux with grub2 efi, i also needed to add noapic to the kernel line, because otherwise the screen turns instantly black after grub finished. I think the reason for that is a interrupt related kernel panic. Thanks for your Help!
Created attachment 74471 [details] output of lspci -vvvnn
Can you please test with my cpu_edp-abomination branch from my personal git repo at http://cgit.freedesktop.org/~danvet/drm ? That one fixes a few edp issues I've seen on my own ivb laptop, and I suspect your new MBA has a similar panel output config (and hence might suffer from similar issues). Branch is based on 3.5-rc4 + a few patches from drm-intel
Created attachment 74501 [details] messages.log with cpu_edp-abomination unfortunately does not work, but there is no screen flickering, it instantly got black. Is there some additional information, i could provide?
I think this is an eDP related issue. The new Macbook Air's internal display is plugged in via an embedded DisplayPort, the old Macbook Air still via LVDS. When i wait until the System booted and blindly login in X, then start a Terminal and then type: $ xrandr --output eDP1 --off $ xrandr --output eDP1 --auto After that the screen works as desired. I'll attach the Xorg.log and a xrandr --verbose. I'm currently using your drm-intel-fixes branch, but the mainline should also work (i'm going to confirm this later).
Created attachment 74531 [details] Xorg.log started with the intel driver
Created attachment 74541 [details] output of xrandr --verbose
On Mon, Jul 2, 2012 at 8:29 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > --- Comment #4 from Dominik Meissner <dominik.meissner@uni-ulm.de> > 2012-07-02 06:29:13 --- > I think this is an eDP related issue. The new Macbook Air's internal display > is > plugged in via an embedded DisplayPort, the old Macbook Air still via LVDS. Yeah, eDP is pain :( Can you please do some further tests, just to confirm that what you're seeing on your eDP machine is similar to what I'm seeing here on mine. Please switch the crtc of the panel with (after it's working) xrandr --output eDP1 --auto --crtc 1 take a note of how well this works and then switch back xrandr --output eDP1 --auto --crtc 0 If switching to crtc 1 doesn't work the first time around, please try again (it should work then). Afterwards, please grab the output of the intel_reg_dumper tool from the intel-gpu-tools git at: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Created attachment 74551 [details] output of intel_reg_dumper after executing both commands after executing "xrandr --output eDP1 --auto --crtc 1" my screen turned black (but the cursor remained), after switching back, everything was normal again.
> --- Comment #8 from Dominik Meissner <dominik.meissner@uni-ulm.de> > 2012-07-02 10:33:29 --- > Created an attachment (id=74551) > --> (https://bugzilla.kernel.org/attachment.cgi?id=74551) > output of intel_reg_dumper after executing both commands > > after executing "xrandr --output eDP1 --auto --crtc 1" my screen turned black > (but the cursor remained), after switching back, everything was normal again. Exact same symptoms as I have. Unfortunately the git branch is a decent hack and not quite correct in all corner cases, so I guess your machine is stumbling over a few issues still. To confirm this a bit more, can you please try the cpu_edp branch again, do the crtc switching as above and then grab another intel_reg_dumper afterwards?
Created attachment 74561 [details] output of intel_reg_dumper after switching to crtc 1
Created attachment 74571 [details] output of intel_reg_dumper after switching back to crtc 0 This time switching to crtc 1 worked, or at least my display worked as with crtc 0.
> --- Comment #11 from Dominik Meissner <dominik.meissner@uni-ulm.de> > 2012-07-02 12:18:27 --- > This time switching to crtc 1 worked, or at least my display worked as with > crtc 0. ... and the reg dump also confirms the story ;-) Thanks for testing. Real patches to really fix this might take a while, it's a rather fundamental issue with our current code.
Please test the ivb-edp-fixpile from my personal git repo. That contains the modeset rewrite, which includes the ivb cpu edp bugfix. At least on my ivb machine, this works now rather well. http://cgit.freedesktop.org/~danvet/drm/ Testing feedback highly welcome, especially whether there are any corner cases left. Also please check dmesg, the new code has grown tons of WARNs to cross check the modeset state tracking with the actual hw state.
Actually that branch has broken dpms handling, so once the screens suspends it won't wake up. Please use the modeset-rework branch instead, that is fixed up ...
Created attachment 75261 [details] messages.log with modeset-rework branch I've now tried your modeset-rework branch. Screen flickers, then turns black (but this time, also the backlight turns off) Should I try the ivb-edp-fixpile, too?
Hm, that's disappointed. ivb-edp-fixpile is the same code, just as wip before I've integrated it into the modeset rework. Can you please do the crtc switching dance again on the modeset-rework branch and then again grab an intel_reg_dump? Also, do any of the old tricks (--off --auto) still help?
Created attachment 75391 [details] dmesg with modeset-rework branch
Created attachment 75401 [details] intel_reg_dump before switching crtc
Created attachment 75411 [details] intel_reg_dump after switching to crtc 1
Created attachment 75421 [details] intel_reg_dump after switching back to crtc 0
Now I had enough time to perform all tests. While booting the eDP turns off, but all external monitors turned on. All crtc switching and off and on turning, turned the backlight off and on again, but without showing anything on the screen. At all I wasn't able to get the internal screen working. The only thing changed in the output of the intel_reg_dumper was the RC6p_RESIDENCY_TIME: before: RC6p_RESIDENCY_TIME: 0x05b9080b crtc_1: RC6p_RESIDENCY_TIME: 0x07b924af after: RC6p_RESIDENCY_TIME: 0x08f63033 I hope the information help further.
Can you please retest on latest drm-intel-next-queued from http://cgit.freedesktop.org/~danvet/drm-intel/ There's an additional patch from Dave Airlie in there (on to of the ivb cpu edp fixes which are required afaict, too) which should help.
A patch referencing this bug report has been merged in Linux v3.7-rc1: commit 3739850b46f560a2be29287c3e5c29999d1a7e0e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Sep 6 22:15:44 2012 +0200 drm/i915: disable the cpu edp port after the cpu pipe
Ping for the retest (you can test on 3.7-rc1, too). If you retest, please attach a full dmesg with drm.debug=0xe added to your kernel cmdline, thanks.
Ok, in addition to testing 3.7 kernels, you should also test the latest drm-intel-next-queued branch from http://cgit.freedesktop.org/~danvet/drm-intel it contains some additional improvements for the eDP backlight code, which might also help.
Dominik, any chance to test the latest bits? Daniel fixed a lot of IVB eDP issues in the past release, hopefully your issue is fixed as well.
Ping. Dominik, please try the latest kernels and report back.
No word from reporter in 9 months, plenty of fixes merged since. Assuming fixed, please reopen if the problems persist.