|
Description
Bryce Harrington
2012-04-13 09:07:20 UTC
Created attachment 59911 [details]
XorgLog.working.txt
Log from a working session with both monitors fired up.
Created attachment 59912 [details]
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
Created attachment 59913 [details]
dmesg.working.txt
dmesg from a working session
Created attachment 59914 [details]
BootDmesg.txt
Created attachment 59915 [details]
CurrentDmesg.txt
dmesg from broken system.
Nothing interesting in these files.
Created attachment 59916 [details]
xrandr.working.txt
xrandr output from working system
Created attachment 59917 [details]
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
"""
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. Created attachment 59920 [details] [review] Separate the PLL from the pipes Something to test. Against what kernel should i test? I tryed vanilla master HEAD, v3.3, v3.2 and intel-next-fixes HEAD. "git am" always fails. 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). Created attachment 59957 [details] 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. Looks like the sequence itself is inconsistent triggering the WARN. Jesse? Can you set drm.debug=0xe and grab a fresh dmesg of the fail? Do you mean oops of bug48652 tree, or working kernel with current display bug? For the OOPS presently. I'm looking at whether it is a regression from the PLL patch or elsewhere. Found the cause, patch on its way. 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. This seems more likely to be the dithering bug, have you tried with: commit c4867936474183332db4c19791a65fdad6474fd5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 10 10:42:36 2012 +0200 drm/i915: properly compute dp dithering for user-created modes Created attachment 60147 [details] 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 note: i do not need to attach external display to reproduce this oops. I'm slightly confused, I don't see any OOPS in the new attachment ... or does the machine die right away? 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. s/i right/you was right/ 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. 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 Created attachment 60168 [details] 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. 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.) 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. Should i do this two tests? I think the bug is not completely fixed :( Created attachment 60171 [details]
dmesg with crash
this dmesg was taken after crush. but it looks like there is no oopses...
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. 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. 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 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 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... 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. 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. This testing looks like Battleship game on paper. You: "Can you test A5?". Me "Crashed!" :) (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. 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? (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... 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. 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) 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? 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) 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) > --- Comment #46 from Oleksij Rempel <bug-track@fisher-privat.net> 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.
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. 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 <jbarnes@virtuousgeek.org> Date: Fri Apr 13 18:24:38 2012 +0100 drm/i915: manage PCH PLLs separately from pipes 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 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. Created attachment 60444 [details] [review] Check combined VBT/register delays 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. ;) with this patch xrandr show eDP, but it wont fix the problem with black screen. Or you know it? Some clues as to which may not be zero may be found in: commit f01eca2e52169eaf3a485cbd9752435489fbfba9 Author: Keith Packard <keithp@keithp.com> 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 delay of over 200ms and a power-down delay of over 600ms. It all works now, but we're frobbing these power controls several times during mode setting, making the whole process take an awfully long time. Signed-off-by: Keith Packard <keithp@keithp.com> (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. 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. A patch referencing this bug report has been merged in Linux v3.4-rc4: commit c291be9dba370ba696a0d482249a212cf5c15f45 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 16 15:16:42 2012 +0100 drm/i915: Hold mode_config lock whilst changing mode for lastclose() 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. 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... Just to make sure. Are you about bug: no image on eDP if VGA was attached before poweron? 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. Created attachment 62393 [details]
reg_dump_vga_at_boot_modeset
regdump: VGA was attached before boot. eDP is not recognized. modeset used by default.
Created attachment 62395 [details]
reg_dump_vga_at_boot_nomodeset
regdump: same like previous. only difference - nomodeset was used.
Created attachment 62396 [details]
reg_dump_vga_after_boot
regdump: VGA was attached after boot. eDP and VGA are recognized and working.
Can you please give us specific details about your monitors make&model and serial number? 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. 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. 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. No, there is no such option. 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? (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. i also tested nomodeset and blacklist.drm both without any positive result. (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. 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). Note to self: I've pointed Daniel Wagner at the wrong bug report, so his comment is unrelated. 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. 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 ... 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. 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. Forgot to say, my grub version is 0.97-29ubuntu66 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? Created attachment 66158 [details]
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.
Created attachment 66159 [details]
regdump bad, without workaround
here i started with vga screen, so only vga is recognized.
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 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 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. 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 :)? 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 ... 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". 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!!! 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! 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. Thanks for the update, adjusting the comment to reflect that this is now only an issue on an ivb asus UX32A. This one is fixed now, isn't it Daniel? 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. 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. Created attachment 71397 [details]
dmesg 3.7.0-rc7-00595-g3b8c67a
(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. I guess it's either fixed or the reporter gave up... Hmm... looks like i missed last message. I'll do some tests tomorrow. 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. 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. Created attachment 81446 [details]
dmesg-3.10.0-rc6-00406-g73bc88c
dmesg from current nightly git.
(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 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?
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. Created attachment 82263 [details]
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?
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). yes, intel_iommu=igfx_off helps too. Thanks! (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? 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". Created attachment 82344 [details] [review] 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. Yes, it works. (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")? (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 <chris@chris-wilson.co.uk> 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 <imre.deak@intel.com> 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. Please retest with latest drm-intel-fixes, specifically commit 2e6efddd203c15ca5c4700511f717c0e9a3ea31a Author: Imre Deak <imre.deak@intel.com> Date: Fri Aug 23 23:50:23 2013 +0300 drm/i915: ivb: fix edp voltage swing reg val 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. 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. Created attachment 87402 [details]
dmesg-3.12.0-rc4-00468-g16b4e9b
Created attachment 87403 [details]
dmesg-3.12.0-rc4-00468-g16b4e9b
(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. 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.
(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. No, intel_iommu=igfx_off do not fix it any more. Created attachment 87451 [details]
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.
Hi, tested yesterdays drm-intel-nightly with hope this patch will fix it: commit 52e1e223456e3aa747e9932f95948381f04b3b26 Author: Jani Nikula <jani.nikula@intel.com> 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? 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. Status update, tested on latest git nightly. No changes. 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 Is this still a problem? We've landed some fixes that could affect this, though the X thing still confuses me. No, it is not fixed :( I think time to ask again for a retest on drm-intel-nightly, just to keep the bug up-to-date. Still same issue. Internal display enabled, backlight is on, but no image. 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? I'm ok with it. Should i open new bug, you open it with needed description? (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. New Bug is 89578 (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 *** |
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.