only external screen is working with asus zenbook ux31e [eDP1]

[Oleksij Rempel]

This is regression after some recent (2-3 weeks) xorg? update.

I also tested newest kernel v3.3.0-rc6 with no changes, so we can exclude kernel.

This ultrabook is intensively used. So if you need some testing, i can do it only on weekends.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xorg 1:7.6+10ubuntu1
Uname: Linux 3.3.0-rc6 x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.93-0ubuntu2
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,compiztoolbox,grid,gnomecompat,imgpng,mousepoll,regex,place,vpswitch,move,animation,snap,resize,session,expo,wall,ezoom,fade,workarounds,scale,unityshell]
CompositorRunning: compiz
Date: Sun Mar 4 13:56:04 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:1427]
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120201.1)
MachineType: ASUSTeK Computer Inc. UX31E
ProcEnviron:
 TERM=xterm
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.3.0-rc6 root=UUID=ab2e9ae5-a032-44f5-b956-3223de09edff ro oops=panic panic=10 quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/20/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX31E.211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX31E
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX31E.211:bd01/20/2012:svnASUSTeKComputerInc.:pnUX31E:pvr1.0:rvnASUSTeKComputerInc.:rnUX31E:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: UX31E
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:0.9.7.0~bzr2995-0ubuntu5
version.ia32-libs: ia32-libs 20090808ubuntu33
version.libdrm2: libdrm2 2.4.30-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.1-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.1-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.99.901+git20120126-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[Timo Aaltonen (tjaalton)]

You can't rule out the kernel if the bug happens on an upstream development kernel, since there might be commits backported to the stable queue that cause regressions.

Boot an older kernel to see if they work.

[Oleksij Rempel (olerem)]

here is aditional info:
xrandr --output eDP1 --auto --output VGA1 --auto --same-as eDP1

i get this error:
xrandr: cannot find crtc for output eDP1

in Xorg.og i get this:
[ 1656.684] (WW) intel(0): flip queue failed: Device or resource busy
[ 1656.684] (WW) intel(0): Page flip failed: Device or resource busy

[Oleksij Rempel (olerem)]

I also tested kernel wich worked befor (3.2.0-12-generic), but it is not working now. so i assum it is not kernel

[Bryce Harrington (bryce)]

Boot an alpha-2 livecd (http://cdimage.ubuntu.com/releases/12.04/alpha-2/) and assuming that works properly, collect the Xorg.0.log, xrandr --verbose, and dmesg from that, to compare with. It's odd that it doesn't show an LVDS output, I wonder if it did previously.

Also, just so I understand your report, are you trying to connect the external display to the VGA port or to the eDP port?

[Oleksij Rempel (olerem)]

alpha2 is working. There is no LVDS too. External port is VGA1, the internal display is eDP1

[Adrien Cunin (adri2000)]

Same problem here: can't display both on the laptop screen and on an external monitor. Laptop screen alone is ok; when plugging the external monitor with VGA, I can only use that external monitor.
It used to work. Dell Latitude E5410, i915 driver.

There are quite a lot of this in Xorg.0.log:
[ 614.160] (WW) intel(0): flip queue failed: Device or resource busy
[ 614.160] (WW) intel(0): Page flip failed: Device or resource busy

When using xrandr:
% xrandr --output eDP1 --auto --output VGA1 --auto --same-as eDP1
xrandr: cannot find crtc for output eDP1

When using gnome-control-center display, dmesg says:
[ 107.800350] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3]

I can test experimental packages or workarounds if needed. :-)

[Chris Wilson (ickle)]

I'm wondering if this is related to bug 44039. The issue would appear to be that it is unable to find a free PLL (or the like) for the eDP after it is turned off. eDP isn't limited to the first pipe, so it should be happy to attach to the second CRTC, just a puzzle as to why it did not.

[Chris Wilson (ickle)]

Created attachment 59920
Separate the PLL from the pipes

Something to test.

[Oleksij Rempel (olerem)]

Against what kernel should i test? I tryed vanilla master HEAD, v3.3, v3.2 and intel-next-fixes HEAD. "git am" always fails.

[Chris Wilson (ickle)]

http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=bug48652 will provide the context you need to apply it. However Jesse mentioned that the ux31e is a CPU eDP and so doesn't use a PCH PLL anyway (and in theory not affected by the patch).

[Bryce Harrington (bryce)]

Ah, I didn't catch it before; this is one of those laptops that uses eDP1 for the laptop display itself. These have been wonky.

Thanks, I think you've collected enough info; we need to forward it upstream.

[Bryce Harrington (bryce)]

Forwarding this bug from Ubuntu reporter Oleksij Rempel:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/946311

[Problem]
Uses eDP1 rather than LVDS1 for the laptop panel. When an external monitor is attached via VGA1 and RANDR used to tweak the config, the laptop panel loses its crtc and can't be enabled.

[Original Description]
This is regression after some recent (2-3 weeks) xorg? update.

I also tested newest kernel v3.3.0-rc6 with no changes.
I also tested kernel which worked before (3.2.0-12-generic), but it is not working now.

I tried beta1 : actually it works until I change the display configuration to disable one screen and try to re-enable both of them. Then I can't get both screens to work again.
I tried beta 1 because IIRC back with beta 1 I didn't have any problem. but maybe it's just that I was lucky and didn't mess enough with the display configuration...

DistroRelease: Ubuntu 12.04
Package: xorg 1:7.6+10ubuntu1
Uname: Linux 3.3.0-rc6 x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.93-0ubuntu2
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,compiztoolbox,grid,gnomecompat,imgpng,mousepoll,regex,place,vpswitch,move,animation,snap,resize,session,expo,wall,ezoom,fade,workarounds,scale,unityshell]
CompositorRunning: compiz
Date: Sun Mar 4 13:56:04 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:1427]
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120201.1)
MachineType: ASUSTeK Computer Inc. UX31E
ProcEnviron:
TERM=xterm
LANG=de_DE.UTF-8ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.3.0-rc6 root=UUID=ab2e9ae5-a032-44f5-b956-3223de09edff ro oops=panic panic=10 quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/20/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX31E.211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX31E
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX31E.211:bd01/20/2012:svnASUSTeKComputerInc.:pnUX31E:pvr1.0:rvnASUSTeKComputerInc.:rnUX31E:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: UX31E
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:0.9.7.0~bzr2995-0ubuntu5
version.ia32-libs: ia32-libs 20090808ubuntu33
version.libdrm2: libdrm2 2.4.30-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.1-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.1-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.99.901+git20120126-0ub...

[Bryce Harrington (bryce)]

Created attachment 59911
XorgLog.working.txt

Log from a working session with both monitors fired up.

[Bryce Harrington (bryce)]

Created attachment 59912
XorgLog.txt

Log from a broken session, where only the external monitor fires up.

Of note is this error following RANDR log messages, which is not present in the other log:

[ 55.743] (EE) intel(0): failed to set mode: Invalid argument

[Bryce Harrington (bryce)]

Created attachment 59913
dmesg.working.txt

dmesg from a working session

[Bryce Harrington (bryce)]

Created attachment 59914
BootDmesg.txt

[Bryce Harrington (bryce)]

Created attachment 59915
CurrentDmesg.txt

dmesg from broken system.

Nothing interesting in these files.

[Bryce Harrington (bryce)]

Created attachment 59916
xrandr.working.txt

xrandr output from working system

[Bryce Harrington (bryce)]

Created attachment 59917
Xrandr.txt

Broken system's xrandr.

Note that both VGA1 and eDP1 are shown as connected, but no crtc is registered for eDP1.

The user attempted using both the gnome settings capplet, and the xrandr command line tool. For the latter he adds:

"""
here is aditional info:
xrandr --output eDP1 --auto --output VGA1 --auto --same-as eDP1

i get this error:
xrandr: cannot find crtc for output eDP1

in Xorg.og i get this:
[ 1656.684] (WW) intel(0): flip queue failed: Device or resource busy
[ 1656.684] (WW) intel(0): Page flip failed: Device or resource busy
"""

[Bryce Harrington (bryce)]

Oleksij Rempel - I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=48652 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

[Oleksij Rempel (olerem)]

Created attachment 59957
dmesg bug48652

I tested the source from your link and it seems to be completely broken for me. The kernel with latest commit: "drm/i915: manage PCH PLLs separately from pipes". will produce oops on the start. Se attached dmesg. I also tryed to reset the source to HEAD~1, but this kernel will start with black screen.

[Adrien Cunin (adri2000)]

I'm attaching a more detailed kernel log (using drm.debug=999 at boot) of what's happening when using xrandr, in case it could be useful.

[Chris Wilson (ickle)]

Looks like the sequence itself is inconsistent triggering the WARN. Jesse?

[Chris Wilson (ickle)]

Can you set drm.debug=0xe and grab a fresh dmesg of the fail?

[Oleksij Rempel (olerem)]

Do you mean oops of bug48652 tree, or working kernel with current display bug?

[Chris Wilson (ickle)]

For the OOPS presently. I'm looking at whether it is a regression from the PLL patch or elsewhere.

[Chris Wilson (ickle)]

Found the cause, patch on its way.

[Chris Wilson (ickle)]

Branch updated at http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=bug48652, can you please attach a drm.debug=0xe for the modesetting failure.

[Jesse Barnes (jbarnes-virtuousgeek)]

This seems more likely to be the dithering bug, have you tried with:
commit c4867936474183332db4c19791a65fdad6474fd5
Author: Daniel Vetter <email address hidden>
Date: Tue Apr 10 10:42:36 2012 +0200

    drm/i915: properly compute dp dithering for user-created modes

[Bryce Harrington (bryce)]

@kernel team: This one is still in progress upstream, but they're proposing some kernel patches to test.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Oleksij Rempel (olerem)]

Created attachment 60147
dmesg bug48652 (3.4.0-rc2-00197-gba8f6a2)

here is new dmesg bug48652 three, kernel v3.4.0-rc2-00197-gba8f6a2
there is oops with drm.debug=0xe

[Oleksij Rempel (olerem)]

note: i do not need to attach external display to reproduce this oops.

[Daniel-ffwll (daniel-ffwll)]

I'm slightly confused, I don't see any OOPS in the new attachment ... or does the machine die right away?

[Oleksij Rempel (olerem)]

ouch... i right. every time i see call trace i think it is oops :( and some thing really bad happened. I'll be careful next time. There are only warnings will call traces in this dmesg.
But any way, x server fails to start on this kernel and goes to save mode.

[Oleksij Rempel (olerem)]

s/i right/you was right/

[Chris Wilson (ickle)]

Spotted the other side of the missing mutex (new code, so Daniel need not worry yet) and rebased upon dinq which now includes fixes upto -rc3.

Hopefully this will kill the spurious warning, and give us a clean drm.debug=0xe dmesg for the bug.

[Daniel-ffwll (daniel-ffwll)]

Ok, I'm unconfused ;-) Given that it WARNs about vdd state change issues, maybe this is related to:

https://bugs.freedesktop.org/show_bug.cgi?id=46312

[Oleksij Rempel (olerem)]

Created attachment 60168
dmesg bug48652 (3.4.0-rc3-00591-g046ae93)

new dmesg with latest source. Now both screens are working.
But it looks like motion on external screen (vga) looks a bit slower. For example if i move some window or watch video with lots of motion, part of it is one or two frame later.

[Chris Wilson (ickle)]

Due to differing output latency between encoders, connectors, and outputs, one display may indeed be a frame or two behind another. Though people usually hold VGA as the gold standard and measure latency compared to a fast CRT.

Thanks for persevering through my branch, your testing was invaluable. Can I ask you test one more? (Possibly two.)

1. http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-fixes
Our fixes branch to make sure that we have the right patch on its way to Linus for the stable kernel.

Failing that,
2. http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued
to see if the fix is in my pending queue vs the patches Daniel has already picked up. (So we can get the fix into stable asap.)

[Oleksij Rempel (olerem)]

update:
if was some minutes of line due one interesting bug, a new one :)
After i tryed to use gui tool to change position of displays, x crashed with some strange artifacts on internal display. Then the gui tool got time out and recovered a least one, internal display.
I tried to reboot, _but_ i was not able to use this kernel any more. it crushed every time i started it, the older one (3.2.0-23-generic) worked ok. I also tryed to poweroff and use other kernel to recover working environment for testing kernel (3.4.0-rc3-00591-g046ae93) with no luck. Then i started windows, and went back to testing kernel and it works now again.

So.. i assume this kernel triggered some register which stay configured even after reboot, and only windows able to set it back.

[Oleksij Rempel (olerem)]

Should i do this two tests? I think the bug is not completely fixed :(

[Oleksij Rempel (olerem)]

Created attachment 60171
dmesg with crash

this dmesg was taken after crush. but it looks like there is no oopses...

[Chris Wilson (ickle)]

Can you look for an old Xorg.log (or xdm/gdm/kdm.log) for the crash?

If you can start by switching to drm-intel-fixes and confirm that at least brings the CPU eDP back up, that would be a great start. If that survives, can you then try drm-intel-next-queued to see if that has the new glitch. Hopefully that too will survive and the problem is in my tree.

[Daniel-ffwll (daniel-ffwll)]

Just an fyi: If the vga connected monitor is an lcd panel, they're known to sometimes hold onto a few frames to control overdrive ... If the difference in lag between the external screen and the laptop panel is big, that could be it.

Otherwise I don't think our scanout hw introduces an entire frame of lag, and X doesn't pageflip with multiple outputs, so that's no the issue.

[Chris Wilson (ickle)]

This is the pipe death:
[ 762.845891] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x100
[ 762.845899] [drm:gen6_fdi_link_train], FDI train 1 done.
[ 762.846560] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x200
[ 762.846566] [drm:gen6_fdi_link_train], FDI train 2 done.
[ 762.846571] [drm:gen6_fdi_link_train], FDI train done.
[ 762.847592] ------------[ cut here ]------------
[ 762.847626] WARNING: at /home/inna/tmp/linux-2.6/drivers/gpu/drm/i915/intel_display.c:942 ironlake_crtc_enable+0x682/0x8e8 [i915]()
[ 762.847633] Hardware name: UX31E
[ 762.847638] PCH PLL state assertion failure (expected on, current off)
[ 762.847642] Modules linked in: tun batman_adv snd_hda_codec_hdmi snd_hda_codec_realtek rfcomm bnep binfmt_misc arc4 ath9k snd_hda_intel snd_hda_codec mac80211 ath3k btusb snd_hwdep bluetooth i915 snd_pcm_oss snd_mixer_oss snd_pcm uvcvideo snd_seq_dummy videobuf2_core videodev snd_seq_oss videobuf2_vmalloc snd_seq_midi videobuf2_memops asus_nb_wmi snd_rawmidi ath9k_common ath9k_hw asus_wmi snd_seq_midi_event drm_kms_helper sparse_keymap snd_seq drm coretemp crc32c_intel ath snd_timer aesni_intel snd_seq_device cryptd snd cfg80211 psmouse serio_raw intel_agp rfkill intel_gtt soundcore agpgart snd_page_alloc wmi ehci_hcd xhci_hcd
[ 762.847735] Pid: 1854, comm: Xorg Tainted: G W 3.4.0-rc3-00591-g046ae93 #22
[ 762.847740] Call Trace:
[ 762.847756] [<ffffffff8102f893>] warn_slowpath_common+0x83/0x9b
[ 762.847765] [<ffffffff8102f94e>] warn_slowpath_fmt+0x46/0x48
[ 762.847791] [<ffffffffa02457ea>] ironlake_crtc_enable+0x682/0x8e8 [i915]
[ 762.847814] [<ffffffffa0245a5e>] ironlake_crtc_commit+0xe/0x10 [i915]
[ 762.847827] [<ffffffffa00bf6a8>] drm_crtc_helper_set_mode+0x32c/0x3fa [drm_kms_helper]
[ 762.847845] [<ffffffffa00c033f>] drm_crtc_helper_set_config+0x6bc/0x93d [drm_kms_helper]
[ 762.847868] [<ffffffffa0122091>] ? drm_mode_object_find+0x5f/0x6f [drm]
[ 762.847887] [<ffffffffa01244f5>] drm_mode_setcrtc+0x416/0x456 [drm]
[ 762.847898] [<ffffffff8144561f>] ? __schedule+0x540/0x557
[ 762.847915] [<ffffffffa01178c0>] drm_ioctl+0x2e6/0x3c3 [drm]
[ 762.847923] [<ffffffff810efd77>] ? lookup_object+0x3b/0x87
[ 762.847939] [<ffffffffa01240df>] ? drm_mode_setplane+0x2f1/0x2f1 [drm]
[ 762.847950] [<ffffffff81100e3f>] do_vfs_ioctl+0x45d/0x49e
[ 762.847959] [<ffffffff810d27b4>] ? remove_vma+0x72/0x7a
[ 762.847967] [<ffffffff810d387d>] ? do_munmap+0x2f2/0x30b
[ 762.847976] [<ffffffff81100ed6>] sys_ioctl+0x56/0x7c
[ 762.847984] [<ffffffff81446c52>] system_call_fastpath+0x16/0x1b
[ 762.847990] ---[ end trace a43d303f89df4f63 ]---
[ 762.949064] [drm:intel_enable_transcoder] *ERROR* failed to enable transcoder 0
[ 762.949077] [drm:intel_update_fbc],
[ 762.949083] [drm:intel_update_fbc], more than one pipe active, disabling compression
[ 762.961064] [drm:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck

[Oleksij Rempel (olerem)]

My two cents about external vga :)
i tested it with windows now, and it seems not to have this issue.
In linux motion on vga looks like:
---i---i
---i---i
--i---i
--i---i

on internal display
---i---i
---i---i
---i---i
---i---i

[Chris Wilson (ickle)]

Ok, that's just the known vsync issue. I presume Windows is using per-crtc pixmaps and so can individually pageflip output, along with using a compositor that allows for pageflips...

[Oleksij Rempel (olerem)]

Branch http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-fixes 3.4.0-rc3-00002-gc291be9 works.
I get only this error after attaching external screen:
[drm:pch_irq_handler] *ERROR* PCH poison interrupt

changing different setting and display locations was ok too, no crashes.

[Oleksij Rempel (olerem)]

I also tested http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued
it has no problems at start, but crashes if i switch modes, or if i switch external display off...

i also accidentally fond other problem, if i start this latop with external display attached, then only external display is working. The is no chance to turn it on. With drm-intel-next-queued, the internal will be not recognized. With drm-intel-next nothing displayed (blackscreen), but xserver use it, i mean desktop is configured with two screens.

[Oleksij Rempel (olerem)]

This testing looks like Battleship game on paper. You: "Can you test A5?". Me "Crashed!" :)

[Chris Wilson (ickle)]

(In reply to comment #39)
> This testing looks like Battleship game on paper. You: "Can you test A5?". Me
> "Crashed!" :)

Sometimes we play bingo as well.

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok so now we're seeing new bugs.

Can you open a bug for the crash at modeset with drm-intel-next-queued and attach the dmesg if you can with the oops or panic output?

[Chris Wilson (ickle)]

(In reply to comment #41)
> Ok so now we're seeing new bugs.
>
> Can you open a bug for the crash at modeset with drm-intel-next-queued and
> attach the dmesg if you can with the oops or panic output?

No worries, we've already fixed that one. ;) Back to the blank eDP...

[Jesse Barnes (jbarnes-virtuousgeek)]

Based on comment #37 it sounds like the -fixes branch works ok, but then later we find out the -queued branch does not.

If only -queued were a superset of -fixes we could bisect it down to the regressing commit.

[Oleksij Rempel (olerem)]

i haw/had fallowing issue with this ultrabook:
- only external screen works on hotplug (fixed)
- crush if changing some screen setting on dual screen (happens only on fixes-queue, it didn't tested lates one)
- only external screen works on coldplug, attached before poweron (next-fixes and fixes-queue filed in different ways)

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok so if you have the monitor plugged in before you power on, the internal display doesn't come up, right?

How is the behavior different between -fixes and -queued?

[Oleksij Rempel (olerem)]

Update:
i tested latest git queue 3.4.0-rc3-00191-gb98e524, now problems 1 and 2 are fixed here too. The last one with plug before power on, is still there.

With queue tree eDP1 is not recognized at all:
here is the output of xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm
   1280x1024 60.0*+ 75.0
   1280x960 60.0
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)

[Oleksij Rempel (olerem)]

With -fixed eDP1 is recognized ans seems to be enabled, but the screen is complete black. I tried to check with flash light, if the image there but no back light. But with this screen i can't see it.
Here is xrandr:
Screen 0: minimum 320 x 200, current 1600 x 1924, maximum 8192 x 8192
eDP1 connected 1600x900+0+1024 (normal left inverted right x axis y axis) 293mm x 164mm
   1600x900 60.0*+
VGA1 connected 1280x1024+320+0 (normal left inverted right x axis y axis) 338mm x 270mm
   1280x1024 60.0*+ 75.0
   1280x960 60.0
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)

[Daniel-ffwll (daniel-ffwll)]

> --- Comment #46 from Oleksij Rempel <email address hidden> 2012-04-18 23:29:49 PDT ---
> i tested latest git queue 3.4.0-rc3-00191-gb98e524, now problems 1 and 2 are
> fixed here too. The last one with plug before power on, is still there.

This is very strange that eDP disappears for you on latest -queued. Can you
please do a bisect between -fixes and -queued to figure out which patch
caused this? I think this would be very interesting and could point us at
the root cause for why eDP doesn't work when you connect an external
display.

[Oleksij Rempel (olerem)]

I was able to reduce count of patches to this range:
dfc9ef2 drm/i915: set ring->size in common ring setup code
6a848cc drm/i915: rip out ring->irq_mask
1500f7e drm/i915: hide (seqno-1) in ringbuffer code
e3a5a22 drm/i915: fix for when semaphore updates fail
5816d64 drm/i915: i915_gem_object_sync must handle NULL
f82cfb6 drm/i915: allow PCH PWM override on IVB
b6834bd drm/i915: disable turbo on ValleyView for now
bfa3384 drm/i915: check PPS regs for sanity when using eDP
f817586 drm/i915: re-init modeset hw state after gpu reset
f841319 drm/i915: Allow concurrent read access between CPU and GPU domain
211c568 drm/i915: simplify ppgtt setup
e3aef17 drm/i915: make DP configuration vars less confusing in ironlake_crtc_mod
0136db5 drm/i915: rc6 in sysfs
d1686ae drm/i915: Ironlake shares the same video sprite controls as Sandybridge
e2ba4fb drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers
90e6b26 drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop
56f9eac drm/i915/intel_i2c: use INDEX cycles for i2c read transactions
72d66af drm/i915/intel_i2c: use WAIT cycle, not STOP
e646d57 drm/i915/intel_i2c: always wait for IDLE before clearing NAK
7a39a9d drm/i915/intel_i2c: use double-buffered writes
26883c3 drm/i915/intel_i2c: handle zero-length writes
3fdcf43 drm/i915: use register name when disabling VGA
2911a35 drm/i915: use semaphores for the display plane
9a5a53b drm/i915: Reorganise rules for get_fence/put_fence

Most of them like minefield. Some where before e3aef17 i get just black screen, and some where after it i get oops.

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok just tested drm-intel-next-queued on my wife's ux31 (I snuck it away without her looking, I'll probably hear screams soon though).

eDP works ok: the kernel comes up, I can see boot messages, then X starts and I see the desktop.

When I connect a mini-HDMI to my 25x16 monitor, it comes up at 19x12, which is expected, and the eDP stays on. I tried this about 5 times and it worked every time.

I don't have a dongle for VGA though, and it's remotely possible that VGA is somehow causing trouble for us, but it's more likely this is an issue with some other aspect of your configuration...

The top of the tree I was using is this commit (i.e. drm-intel-next-queued from this morning):

commit b98e5240b362e702355ffedba05aeb589dfbcbe2
Author: Jesse Barnes <email address hidden>
Date: Fri Apr 13 18:24:38 2012 +0100

    drm/i915: manage PCH PLLs separately from pipes

[Oleksij Rempel (olerem)]

Hi,
i got some more time to play with it too. You know, laptop of my wife :)

this difference was introduced by the patch:
bfa3384 drm/i915: check PPS regs for sanity when using eDP

here what i get on the place where it was called:
intel_dp_init:2488 pp_on:0, pp_off:0, pp_div:1599748

[Chris Wilson (ickle)]

Review fail. :(

So what happens is that we also check the VBT for eDP panel data and combine those with the register settings the BIOS was meant to make...

Thanks for the bisect.

[Chris Wilson (ickle)]

Created attachment 60444
Check combined VBT/register delays

[Chris Wilson (ickle)]

I leave it to Jesse to check whether this safeguards his broken SDV and also whether any of those 0 delays are in fact legal. ;)

[Oleksij Rempel (olerem)]

with this patch xrandr show eDP, but it wont fix the problem with black screen.
Or you know it?

[Chris Wilson (ickle)]

Some clues as to which may not be zero may be found in:

commit f01eca2e52169eaf3a485cbd9752435489fbfba9
Author: Keith Packard <email address hidden>
Date: Wed Sep 28 16:48:10 2011 -0700

    drm/i915: Correct eDP panel power sequencing delay computations

    Store the panel power sequencing delays in the dp private structure,
    rather than the global device structure. Who knows, maybe we'll get
    more than one eDP device in the future.

    From the eDP spec, we need the following numbers:

     T1 + T3 Power on to Aux Channel operation (panel_power_up_delay)

      This marks how long it takes the panel to boot up and
      get ready to receive aux channel communications.

     T8 Video signal to backlight on (backlight_on_delay)

      Once a valid video signal is being sent to the device,
      it can take a while before the panel is actuall
      showing useful data. This delay allows the panel
      to get something reasonable up before the backlight
      is turned on.

     T9 Backlight off to video off (backlight_off_delay)

      Turning the backlight off can take a moment, so
      this delay makes sure there is still valid video
      data on the screen.

     T10 Video off to power off (panel_power_down_delay)

      Presumably this delay allows the panel to perform
      an orderly shutdown of the display.

     T11 + T12 Power off to power on (panel_power_cycle_delay)

      So, once you turn the panel off, you have to wait a
      while before you can turn it back on. This delay is
      usually the longest in the entire sequence.

    Neither the VBIOS source code nor the hardware documentation has a
    clear mapping between the delay values they provide and those required
    by the eDP spec. The VBIOS code actually uses two different labels for
    the delay values in the five words of the relevant VBT table.

    **** MORE LATER ***

    Look at both the current hardware register settings and the VBT
    specified panel power sequencing timings. Use the maximum of the two
    delays, to make sure things work reliably. If there is no VBT data,
    then those values will be initialized to zero, so we'll just use the
    values as programmed in the hardware. Note that the BIOS just fetches
    delays from the VBT table to place in the hardware registers, so we
    should get the same values from both places, except for rounding.

    VBT doesn't provide any values for T1 or T2, so we'll always just use
    the hardware value for that.

    The panel power up delay is thus T1 + T2 + T3, which should be
    sufficient in all cases.

    The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
    for T11, which isn't available anywhere.

    For the backlight delays, the eDP spec says T6 + T8 is the delay from the
    end of link training to backlight on and T9 is the delay from
    backlight off until video off. The hardware provides a 'backlight on'
    delay, which I'm taking to be T6 + T8 while the VBT provides something
    called 'T7', which I'm assuming is s

    On the macbook air I'm testing with, this yields a power-up d...

[Chris Wilson (ickle)]

(In reply to comment #55)
> with this patch xrandr show eDP, but it wont fix the problem with black screen.
> Or you know it?

That patch will restore detection of the eDP panel right... Oh but then we are back to the original bug. Darn, I'd forgotten just how many regressions you were fighting.

[Jesse Barnes (jbarnes-virtuousgeek)]

Is there a BIOS update available for your machine? That may help... also we may need to take the VBT values and stuff them back into the regs at init time to give them reasonable values.

[W-florijn-k (w-florijn-k)]

A patch referencing this bug report has been merged in Linux v3.4-rc4:

commit c291be9dba370ba696a0d482249a212cf5c15f45
Author: Chris Wilson <email address hidden>
Date: Mon Apr 16 15:16:42 2012 +0100

    drm/i915: Hold mode_config lock whilst changing mode for lastclose()

[Oleksij Rempel (olerem)]

I updatet BIOS. Old version 211, new 212. But it make no difference.
I also made VBIOS dump of both version, the difference between them is:
diff <(xxd vbios_211) <(xxd vbios_212)
2c2
< 0000010: 3030 0c24 e925 2324 4000 b00a 3030 4942 00.$.%#$@...00IB
---
> 0000010: 3030 0c24 e925 23d8 4000 b00a 3030 4942 00.$.%#.@...00IB
3610,3611c3610,3611
< 000e190: 0000 0000 0300 f0f3 ee16 0194 7653 00c5 ............vS..
< 000e1a0: d37c 0054 6f74 616c 2074 696d 6520 666f .|.Total time fo
---
> 000e190: 0000 0000 0300 f0f3 ee16 01c1 ae56 0033 .............V.3
> 000e1a0: 4580 0054 6f74 616c 2074 696d 6520 666f E..Total time fo

if you need the dumps, i can upload it.

[Jesse Barnes (jbarnes-virtuousgeek)]

Can you attach the output from intel_reg_dumper when booting with nomodeset and in the broken case? I just want to confirm your eDP config...

[Oleksij Rempel (olerem)]

Just to make sure. Are you about bug:
no image on eDP if VGA was attached before poweron?

[Oleksij Rempel (olerem)]

i just grabbed latest queued branch and made some tests with external vga. Results are still same:
- if vga attached after boot. both displays are recognized VGA and eDP
- if vga attached before boot. only VGA is recognized.
- modeset vs nomodeset make no difference.

[Oleksij Rempel (olerem)]

Created attachment 62393
reg_dump_vga_at_boot_modeset

regdump: VGA was attached before boot. eDP is not recognized. modeset used by default.

[Oleksij Rempel (olerem)]

Created attachment 62395
reg_dump_vga_at_boot_nomodeset

regdump: same like previous. only difference - nomodeset was used.

[Oleksij Rempel (olerem)]

Created attachment 62396
reg_dump_vga_after_boot

regdump: VGA was attached after boot. eDP and VGA are recognized and working.

[Daniel-ffwll (daniel-ffwll)]

Can you please give us specific details about your monitors make&model and
serial number?

[Oleksij Rempel (olerem)]

External, attached on VGA port:
Iiyama ProLite E1700S
Model: PL1700
Serial: 05770 64900433

Internal, eDP. I have no idea. It is build in to laptop, Asus Zenbook ux31e.
Some more info can be found xrandr dump, see attachments.

[Oleksij Rempel (olerem)]

I was reading your "cache EDID eDP" discussion, one thought just visited me.

If VGA attached before poweron, BIOS post screen will aper on VGA, not on eDP.
eDP is completely turned off. This probably the reason why it is "lost" in this case.

[Jesse Barnes (jbarnes-virtuousgeek)]

Ah your BIOS may be doing something funky then, does it have options to control which output to use? Sometimes you can make it use the LFP (local flat panel) all the time.

[Oleksij Rempel (olerem)]

No, there is no such option.

[Jesse Barnes (jbarnes-virtuousgeek)]

Sorry this is taking so long, Oleksij. I wish I could reproduce it.

With the current drm-intel-next, do you see both outputs in xrandr even with the VGA plugged in at boot? Or does it still not enumerate at all if VGA is plugged in?

If you use the vesa driver are you able to get both displays going even with the VGA plugged in at boot?

[Oleksij Rempel (olerem)]

(In reply to comment #72)
> Sorry this is taking so long, Oleksij. I wish I could reproduce it.

no problem.

> With the current drm-intel-next, do you see both outputs in xrandr even with
> the VGA plugged in at boot? Or does it still not enumerate at all if VGA is
> plugged in?

no current drm-intel-next xrandr do not list eDP.

[Oleksij Rempel (olerem)]

i also tested nomodeset and blacklist.drm both without any positive result.

[Oleksij Rempel (olerem)]

(In reply to comment #73)
> (In reply to comment #72)
> > Sorry this is taking so long, Oleksij. I wish I could reproduce it.
>
> no problem.
>
> > With the current drm-intel-next, do you see both outputs in xrandr even with
> > the VGA plugged in at boot? Or does it still not enumerate at all if VGA is
> > plugged in?
>
> no current drm-intel-next xrandr do not list eDP.

no, with current drm-intel-next, xrander do not list eDP.

[Daniel Wagner (wagi)]

I have a new Macbook Air 2012 Model and it seems that I have the same problem as reported here.

An older kernel version 3.3 works fine, where as newer ones give me a black screen.

Daniel asked me to test the latest patch from here. I applied "Check combined VBT/register delay" on top of todays drm-intel-next (20d5a540 drm/i915: don't grab dev->struct_mutex for userspace forcewak).

Eventually the screen is black again. But there is a small difference: before it turns black I see kernel boot message (booted without the 'quiet' argument).

[Daniel-ffwll (daniel-ffwll)]

Note to self: I've pointed Daniel Wagner at the wrong bug report, so his comment is unrelated.

[Nick Coghlan (ncoghlan)]

I think I've hit basically the same problem Oleksij is reporting (blank eDP) when using the ASUS UX31E with an external HDMI monitor and leaving it plugged in while booting (https://bugzilla.redhat.com/show_bug.cgi?id=844985).

Aside from the fact Oleksij uses VGA and I use HDMI, it otherwise seems to be the same issue.

I ended up finding this bug report because one of the patches attached to this bug while searching for the "bad panel power sequencing delays, disabling panel" error message I found in dmesg.

I'm also still seeing the problem Bryce described way back in the original bug report: if I use Fn+F8 to disable the internal LCD, it doesn't come back unless I do a mode change on the internal monitor. That seems to be a very different problem though, as in that case eDP1 still shows up in the xrandr output.

[Daniel-ffwll (daniel-ffwll)]

My modeset-rework patchki has a few fixes for handling cpu eDP, please test the modeset-rework git branch at

http://cgit.freedesktop.org/~danvet/drm

Nick Coghlan: There's a decent chance you have a different issue, can you please file a separate bug with the usual information? Untangle this bug report here will otherwise be a disaster if it later on turns out that you don't have the same bug, but marking bugs as duplicates once they're fixed is easy ...

[Oleksij Rempel (olerem)]

Tested with latest commit "drm/i915: move encoder->mode_set calls to crtc_mode_set". Still same result. eDP is not detected or listed with xrandr.

[Oleksij Rempel (olerem)]

Hoho... i have a breakthrough. I think the grub makes problems.
I tried to reproduce this issue on each step: bios, grub and linux. And results are fallowing:
- bios (called with Fn+F2), no problems. I can normally switch between screen (Fn+F8)
- grub. first problems. If bios was switched to eDP, then grub can switch (Fn+F8) between VGA and eDP. If bios was switched to VGA, then grub knows only VGA and F8 switch goes after some blinking back to VGA. If i plug VGA display after grub was loaded then, i can switch between displays. In both situations, if two displays are recognized by grub, then image on vga screen is not clean, with some kind of distortions.
- linux. completely depends on grub.
- windows. can some how recover after grub.

[Oleksij Rempel (olerem)]

Forgot to say, my grub version is 0.97-29ubuntu66

[Daniel-ffwll (daniel-ffwll)]

Can you please get the latest git version of intel-gpu-tools and grab the another reg dump with the magic workaround done, so that everything works with i915.ko kms enabled?

[Oleksij Rempel (olerem)]

Created attachment 66158
regdump good, with workaround

reg dump with workaround.
I also was able to make grub work, just by blacklisting grub-vga module.

one more info. To compile latest intel_tools i need to upgrade to newest xorg and intel driver. I looks like it is in bad shape now. Some part for example text are not rerendered until it move mous pointer over it. cIt make me currently really hard to write.

[Oleksij Rempel (olerem)]

Created attachment 66159
regdump bad, without workaround

here i started with vga screen, so only vga is recognized.

[Oleksij Rempel (olerem)]

I got one more laptop with ivy bridge and same issue: Zunebook ux31a. CPU i5-3317U.
intel_stepping
Vendor: 0x8086, Device: 0x0166, Revision: 0x09 (??)
render clock: unknown sampler clock: unknown

[Daniel-ffwll (daniel-ffwll)]

Dave Airlie has found a little setup sequence issue for edp. Can you please test the latest drm-intel-nightly branch from http://cgit.freedesktop.org/~danvet/drm-intel

[Oleksij Rempel (olerem)]

It is not fixed, but at least eDP is recognized.
It is listed in xrandr and xserver enabled duals screen, but eDP screen is blank.

[Oleksij Rempel (olerem)]

i tested latest drm-intel-nightly. eDP is not listed now.
Are there any one working on this bug, or i just do testing keep myself busy :)?

[Daniel-ffwll (daniel-ffwll)]

Hm, it's rather strange that -nightly worked, then broke again for you. Do you still have the commits of the respective nigthly versions you've tested? We need to full commit since -nightly gets rebuilt every time I push a patch ...

[Oleksij Rempel (olerem)]

I do not have commit any more.
BUt it was between your comment at 2012-09-17 16:49:05 UTC and my comment 2012-09-17 18:58:06 UTC :)
The definition "it works" is not really good here. Currently i have two states of this bug:
- listed by xrandr, but not works
- not listed and not works

Now it "not listed and not works", on my test at 2012-09-17 it was "listed by xrandr, but not works".

[Martin Šácha (sachy)]

Also confirmed on Asus zenbook UX32A; LCD 1366x768; Ubuntu 12.10 64bit (newest build)

eDP can be used only with nomodeset, but motion is really slow.

[Martin Šácha (sachy)]

Workaround without nomodeset - boot up (eDP will be blank), suspend system (close ntb, Fn+F1) and after wakeup will be everything fine.

[Oleksij Rempel (olerem)]

I just tested latest testing branch.
There are some interesting changes:
- back light on eDP is now on.
- eDP is recognised but stays blank
- if i press Fn+F8 to change display, i get corrupt display on VGA. Then, after second press, both eDP and VGA work!!!

[Daniel-ffwll (daniel-ffwll)]

Sounds like we're making progress. Dropping the regression part, since that's now fixed. For the corrupted VGA issue, we're working on fixes for fdi/pch handling, so maybe that will be resolved soon. For eDP iself we're likely still missing some fixes somewhere, but it's rather awesome that you can kick it into working order with some vt switching!

[Oleksij Rempel (olerem)]

I did more testing.
The problem is fixed for Asus UX32E (SNB) - initial report.
Test from my previous post was made on Asus UX32A (IVB), it is partially fixed.

[Daniel-ffwll (daniel-ffwll)]

Thanks for the update, adjusting the comment to reflect that this is now only an issue on an ivb asus UX32A.

[Rémi Pannequin (remi-pannequin-gmail)]

I got a (probably) similar bug on Dell latitude E5510 (with the same intel IGC) : external monitors works, but internal panel stay blank.

 If using the Fn+F8 keys, the backlight of the internal screen ligth up, but the screen stay blank. The only (easy) way to get internal screen working is booting using failsafe mode (i.e. with nomodeset)

[Oleksij Rempel (olerem)]

you should report it upstream. Part of this bug was fixed for SandyBrdige. If you do not use SandyBridge of IvyBridge, then it is different bug.

[Jesse Barnes (jbarnes-virtuousgeek)]

This one is fixed now, isn't it Daniel?

[Daniel-ffwll (daniel-ffwll)]

We've certainly fixed tons of eDP bugs in recent kernels to warrant re-testing. Please test the latest drm-intel-nightly branch and report on what exactly is still broken on the ivb machine.

[Oleksij Rempel (olerem)]

It is not fixed on drm-intel-nightly (last commit cdb96764a45f87e). Same behaviour like before + xserver fails to start. SO i have two black screens instead of one.

[Oleksij Rempel (olerem)]

Created attachment 71397
dmesg 3.7.0-rc7-00595-g3b8c67a

[Timo Jyrinki (timo-jyrinki)]

This bug seems to be fixed for me on raring for Zenboox UX31E (sandy bridge). Earlier I didn't notice the bug at all since I only rarely used external monitor. The original reported also had SB, so if someone with Ivy Bridge still has this problem I think it's better to have a separate bug.

[Imre Deak (ideak)]

(In reply to comment #99)

Oleksij, could you please retest with the latest drm-intel-nightly? Since your last report there has been link training and IRQ handling fixes that could have solved your problem.

The WARN in your dmesg is the same as in bug#51983, so if that's the only remaining issue you see, I'll set this as a duplicate of that.

[Jesse Barnes (jbarnes-virtuousgeek)]

I guess it's either fixed or the reporter gave up...

[Bug-track-c (bug-track-c)]

Hmm... looks like i missed last message. I'll do some tests tomorrow.

[Daniel-ffwll (daniel-ffwll)]

Please reopen if it's still broken after retesting with the latest bits. We know that eDP is a bit flakey, but knowing which parts are still broken exactly is always helpful.

[Bug-track-c (bug-track-c)]

It still miserably fails :(

- on hotplug, after start - every thing is ok. vga screen will be recognised without problem.

- on coldplug. before power on - laptop screen is blank. vga - shows part of oops message. X is not started, but machine is accessible over ssh.

[Bug-track-c (bug-track-c)]

Created attachment 81446
dmesg-3.10.0-rc6-00406-g73bc88c

dmesg from current nightly git.

[Imre Deak (ideak)]

(In reply to comment #105)
> Created attachment 81446 [details]
> dmesg-3.10.0-rc6-00406-g73bc88c
>
> dmesg from current nightly git.

Could you locate the source line for the oops? With the same build you can trigger it, ideally with the latest -nightly:

$ gdb drivers/gpu/drm/i915/i915.ko
$ l *intel_crtc_set_config+0x216

[Bug-track-c (bug-track-c)]

So, i tasted with latest git 3.10.0-rc7-00854-gf19c9d3 - same result.

(gdb) l *intel_crtc_set_config+0x216
0x2bab0 is in intel_crtc_set_config (/home/lex/tmp/linux/drivers/gpu/drm/i915/intel_display.c:8678).
8673 int num_connectors)
8674 {
8675 int i;
8676
8677 for (i = 0; i < num_connectors; i++)
8678 if (connectors[i].encoder &&
8679 connectors[i].encoder->crtc == crtc &&
8680 connectors[i].dpms != DRM_MODE_DPMS_ON)
8681 return true;
8682

I noticed that in some circumstances i null pointer dereference on xhci driver. Interesting, are these errors connected? Or may be there is some memory region used by what ever, bios, efi?

[Bug-track-c (bug-track-c)]

Seems like disabling "Intel VT-d" solve this oops. I was able to boot with vga+laptop screen and both was working!

I'll do more testing to be sure.

[Bug-track-c (bug-track-c)]

Created attachment 82263
dmesg-3.10.0-rc7-00858-g2a74dfa

Here is dmesg from current git and boot with attached VGA display. Some notes:
- right now it works only with Intel VT-d disabled.
- there is some warnings abut pipe_off wait timed out
- i have only one login screen, on VGA. After login both displays are recognised. On SND both screens are working on already on login.
- what about "Intel VT-d" i use virtualisation intensively, is it possible to fix it?

[Daniel-ffwll (daniel-ffwll)]

Can you please reenable vt-d support and instead boot with intel_iommu=igfx_off? That should only disable vt-d for the intel integrated gfx device (and usually helps as well as turning it off completely).

[Bug-track-c (bug-track-c)]

yes, intel_iommu=igfx_off helps too. Thanks!

[Daniel-ffwll (daniel-ffwll)]

(In reply to comment #111)
> yes, intel_iommu=igfx_off helps too. Thanks!

Ok, that's proof that something _really_ fishy is going on here. Big WTF moment ... Imre do you have any ideas what this could be? Seen anything like this when you've done the sg conversion?

[Bug-track-c (bug-track-c)]

After your comment i did some more tests -- just in case.
Enabled VT-d and removed intel_iommu=igfx_off line. Result is really interesting:
I get oops only on second boot without igfx_off. First boot without igfx_off is ok, both displays are working, but after power off and new start with same configuration - without igfx_off kernel it will oops.

Other Zenbook had similar problem with suspend. After some suspend issue it wasn't able to boot. Reason - memory corruption. May be some thing similar is happening here. And some controller stay confused after power off with not setted "intel_iommu=igfx_off".

[Imre Deak (ideak)]

Created attachment 82344
disable sg compaction

> (In reply to comment #111)
> > yes, intel_iommu=igfx_off helps too. Thanks!
>
> Ok, that's proof that something _really_ fishy is going on here. Big WTF
> moment ... Imre do you have any ideas what this could be? Seen anything like
> this when you've done the sg conversion?

No, I haven't tested vt-d ... But yeah, it may be similar to the swiotlb limitation. Oleksij could you try if the attached patch fixes the problem? I can take a closer look tomorrow.

[Bug-track-c (bug-track-c)]

Yes, it works.

[Imre Deak (ideak)]

(In reply to comment #115)
> Yes, it works.

Thanks, it narrows it down. I looked through the Intel HW IOMMU code and haven't found anything obvious that could explain this.

OTOH, looking again at the dmesg with the crash (dmesg-3.10.0-rc6-00406-g73bc88c) I can't see the HW IOMMU being enabled. I'd expect "PCI-DMA: Intel(R) Virtualization Technology for Directed I/O". Instead I see SWIOTLB being enabled there. But if you are using SWIOTLB I don't understand why igfx_off makes any difference. Also the workaround in my patch should be already active for SWIOTLB, so that shouldn't make any difference either. Could you check if you had that workaround in your test kernel (1625e7e549 - "drm/i915: make compact dma scatter lists creation work with SWIOTLB backend")?

[Chris Wilson (ickle)]

(In reply to comment #107)
> So, i tasted with latest git 3.10.0-rc7-00854-gf19c9d3 - same result.
>
> (gdb) l *intel_crtc_set_config+0x216
> 0x2bab0 is in intel_crtc_set_config
> (/home/lex/tmp/linux/drivers/gpu/drm/i915/intel_display.c:8678).
> 8673 int num_connectors)
> 8674 {
> 8675 int i;
> 8676
> 8677 for (i = 0; i < num_connectors; i++)
> 8678 if (connectors[i].encoder &&
> 8679 connectors[i].encoder->crtc == crtc &&
> 8680 connectors[i].dpms != DRM_MODE_DPMS_ON)
> 8681 return true;
> 8682
>
>
> I noticed that in some circumstances i null pointer dereference on xhci
> driver. Interesting, are these errors connected? Or may be there is some
> memory region used by what ever, bios, efi?

This OOPS is fixed by

commit 2e57f47d317dd035b18634b0c602272529368fcc
Author: Chris Wilson <email address hidden>
Date: Wed Jul 17 12:14:40 2013 +0100

    drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off()

    In commit e3de42b68478a8c95dd27520e9adead2af9477a5
    Author: Imre Deak <email address hidden>
    Date: Fri May 3 19:44:07 2013 +0200

        drm/i915: force full modeset if the connector is in DPMS OFF mode

No idea why VT-d affects that at all.

[Daniel-ffwll (daniel-ffwll)]

Please retest with latest drm-intel-fixes, specifically

commit 2e6efddd203c15ca5c4700511f717c0e9a3ea31a
Author: Imre Deak <email address hidden>
Date: Fri Aug 23 23:50:23 2013 +0300

    drm/i915: ivb: fix edp voltage swing reg val

[Jani-nikula (jani-nikula)]

Oleksij, if I may ask for another test round with current drm-intel-nightly branch of git://people.freedesktop.org/~danvet/drm as there have been some relevant fixes since we last heard from you. Thanks.

[Bug-track-c (bug-track-c)]

Hi Jani.
If VGA attached on before power on:
only VGA has image. DP has backlight on, but no image.
xrandr list both displays.
After pressing Fn+F8, display switch button, both screens will work.
After this i get some warnings in dmesg.

If VGA attached after boot, both displays are working OK.

Now i able to test HDMI too. And there some issues as well. For example it is not automatically detected after cable was attached.

[Bug-track-c (bug-track-c)]

Created attachment 87402
dmesg-3.12.0-rc4-00468-g16b4e9b

[Bug-track-c (bug-track-c)]

Created attachment 87403
dmesg-3.12.0-rc4-00468-g16b4e9b

[Jani-nikula (jani-nikula)]

(In reply to comment #122)
> Created attachment 87403 [details]
> dmesg-3.12.0-rc4-00468-g16b4e9b

Please do the same with drm.debug=0xe module parameter. Sorry I forgot to mention this before. Thanks.

[Bug-track-c (bug-track-c)]

Created attachment 87441
dmesg-3.12.0-rc4-00468-g16b4e9b

Start with previously attached VGA. Both displays seems to be detected, and listed by xrandr. But DP is blank with backlight on.

[Jani-nikula (jani-nikula)]

(In reply to comment #124)
> Created attachment 87441 [details]
> dmesg-3.12.0-rc4-00468-g16b4e9b
>
> Start with previously attached VGA. Both displays seems to be detected, and
> listed by xrandr. But DP is blank with backlight on.

And does intel_iommu=igfx_off still fix this? If it does, please attach the dmesg for that too. Thanks.

[Bug-track-c (bug-track-c)]

No, intel_iommu=igfx_off do not fix it any more.

[Bug-track-c (bug-track-c)]

Created attachment 87451
dmesg-3.12.0-rc4-00468-g16b4e9b + switch in grub

Here is dmesg with other workaround.
I started laptop with attached VGA and switched it default screen in grub with Fn+F8 button. After it both displays work OK.

[Bug-track-c (bug-track-c)]

Hi, tested yesterdays drm-intel-nightly with hope this patch will fix it:

commit 52e1e223456e3aa747e9932f95948381f04b3b26
Author: Jani Nikula <email address hidden>
Date: Mon Oct 21 10:52:07 2013 +0300

    drm/i915/dp: workaround BIOS eDP bpp clamping issue

suddenly it is not.
Right now i found one more way to bring eDP up. After start i can open gnome-control-center, display setting and press save. No changes needed. It will reenable eDP. Output of xrnadr --verbose, before and after this action, differs only here:
< CRTCs: 1 0 2
---
> CRTCs: 0 1 2

will it help?

[Jesse Barnes (jbarnes-virtuousgeek)]

I'm not sure how X orders the CRTCs, but theoretically that's just the CRTC mask (i.e. which CRTCs can drive that connector). The order they're printed in shouldn't matter...

If moving the actual CRTC made a difference, that would make more sense, but that doesn't seem to be the case here.

[Bug-track-c (bug-track-c)]

Status update, tested on latest git nightly. No changes.

[Oleksij Rempel (olerem)]

Is it possible thet this bug has same oots as this one in acpi?
http://www.spinics.net/lists/kernel/msg1686042.html
https://bugzilla.kernel.org/show_bug.cgi?id=70241

[Jesse Barnes (jbarnes-virtuousgeek)]

Is this still a problem? We've landed some fixes that could affect this, though the X thing still confuses me.

[Oleksij Rempel (olerem)]

No, it is not fixed :(

[Daniel-ffwll (daniel-ffwll)]

I think time to ask again for a retest on drm-intel-nightly, just to keep the bug up-to-date.

[Oleksij Rempel (olerem)]

Still same issue. Internal display enabled, backlight is on, but no image.

[Jani-nikula (jani-nikula)]

Looking at this bug for the umpteent time, I would suggest closing this one, RESOLVED WESUCK, and starting with a clean slate by filing a new bug against v4.0-rc1 or drm-intel-nightly. There's too much baggage here for anyone to look at this with fresh eyes, or if they were fresh while starting they won't be fresh by comment #136.

The new bug can reference this one for historical perspective, but I think it would be best to narrow it down to describing the symptoms running the new kernels only.

How about it, Oleksij?

[Oleksij Rempel (olerem)]

I'm ok with it.

Should i open new bug, you open it with needed description?

[Jani-nikula (jani-nikula)]

(In reply to Oleksij Rempel from comment #137)
> I'm ok with it.
>
> Should i open new bug, you open it with needed description?

I would really appreciate you doing it, so you describe your symptoms, instead of me putting words in your mouth. Thanks.

[Oleksij Rempel (olerem)]

New Bug is 89578

[Jani-nikula (jani-nikula)]

(In reply to Oleksij Rempel from comment #139)
> New Bug is 89578

Many thanks Oleksij. I'm resolving this as dupe of the new one (usually we'd go about this the other way round) so we have links both ways.

*** This bug has been marked as a duplicate of bug 89578 ***