I have an Intel DQ77MK motherboard, which has 2 DVI connectors, and a Core i7 3770S IvyBridge CPU. Under Ubuntu 12.04, the multiple display support does not work, and I am stuck with a single display. The second screen only shows all pixels as 100% red. Enabling the second screen in Displays in System Settings does allow me to move windows and the mouse cursor to that screen, though I cannot actually see anything on it, as everything is red. For now I have had to force it to mirror displays, to avoid moving things to the second screen. Both screens at 1280x800 works, but both screens at 2048x1152 fails, regardless of whether using mirrored mode in Xorg.
Smells like fdi b/c link train fail again. Can you check whether you can switch places of the monitors by switching crtcs (with the xrandr --crtc option). But don't try to use both crtc 1&2, that will run into a hw limit that we currently don't check ... Also, please retest on latest 3.6-rc kernels just to check, and please attach dmesg with drm.debug=0xe and xrandr --verbose
Sorry I haven't had more time to try and debug this. Just posted on G+ asking for anyone with the same CPU/Motherboard and multiple displays to help out if possible. That said, I tried switching crtc on the outputs just now, and I can get the main screen to switch between the two, but the secondary always stays black now (it's no longer red, though not sure why). I'm trying to find a 3.6-rc kernel package for Ubuntu, to test with. The current 12.10 kernel is I think based on 3.5.3, and I don't know if it has the Intel video code back-ported from 3.6 or not.
This appears in dmesg: [ 21.891791] i915 0000:00:02.0: setting latency timer to 64 [ 21.892354] i915 0000:00:02.0: irq 50 for MSI/MSI-X [ 21.892364] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 21.892365] [drm] Driver supports precise vblank timestamp query. [ 21.892690] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 22.029166] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [ 22.654318] fbcon: inteldrmfb (fb0) is primary device [ 22.654395] Console: switching to colour frame buffer device 256x72 [ 22.654441] fb0: inteldrmfb frame buffer device [ 22.654442] drm: registered panic notifier [ 22.656484] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 22.656611] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 23.490221] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 23.492366] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! The last 2 messages appear to match Daniel's suggestion of fdi train fail. Is this enough information to go on for now? I installed a 3.6-rc5 kernel, but upon booting it, my mouse and keyboard were not working under X, so I was unable to log in, switch to a console, or even reboot without using the hardware reset button.
Daniel, does having these messages from drm indicate this is likely a kernel issue rather than an Xorg issue, at this point?
Yep, this is an issue with the kernel modeset code in the drm/i915.ko driver. But this bug is in the right bugzilla, we also handle the kernel issues for the intel driver here.
Daniel, is there any more information you need to be able to solve the bug? Would like to be able to get this fixed soon. My monitor is getting lonely without the twin working. :)
Time for some testing on drm-intel-next-queued. Right, Daniel?
drm-intel-fixes from http://cgit.freedesktop.org/~danvet/drm-intel has fixes for all known fdi link issues. I'll lean out the window a bit here and claim that this is fixed now, thanks for reporting this bug an please reopen if you still have issues (I wouldn't be too surprised by that ...).
Daniel, is this the commit that fixes the issue? http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=248138b59880a3cc69e9b7f0e06fb0caedd58305 If not, can you please point at the commit which does? There have been a few 3.5 kernel updates recently on Ubuntu 12.10 with several i915 fixes mentioned in the changelog, and I'd like to check that the commit is included in there before trying to build or use a different kernel with the change. Thanks.
I'm reopening this, as I'm still seeing link train fail, and cannot use both monitors at 2048x1152 with IVB yet. I'm seeing this with the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc2-raring/ which appears to include your changes from the intel-fixes branch, per the CHANGES file in that directory. I can however, now use the second screen at 1360x768 (1366x768 or higher fails), even with the primary screen at 2048x1152, now. Of course, there are still link train failure messages in dmesg: [ 7.921088] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 7.923231] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [ 100.486195] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 100.488353] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [ 110.702834] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 110.704998] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [ 122.606258] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 122.608423] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
Please attach full dmesg from boot with drm.debug=0xe module parameter, up to exhibiting the problem. Thanks.
Created attachment 72641 [details] dmesg data for drm.debug=0xe
(In reply to comment #12) > Created attachment 72641 [details] > dmesg data for drm.debug=0xe Just to check: Is that dmesg from 3.8-rc2?
(In reply to comment #13) > (In reply to comment #12) > > Created attachment 72641 [details] > > dmesg data for drm.debug=0xe > > Just to check: Is that dmesg from 3.8-rc2? BOOT_IMAGE=/vmlinuz-3.8.0-030800rc2-generic in the dmesg suggests so... but there's no FDI link train errors and I don't spot another monitor there either. Are you using HDMI for both monitors? Or something else? Any adapters in between?
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Created attachment 72641 [details] > > > dmesg data for drm.debug=0xe > > > > Just to check: Is that dmesg from 3.8-rc2? > > BOOT_IMAGE=/vmlinuz-3.8.0-030800rc2-generic in the dmesg suggests so... but > there's no FDI link train errors and I don't spot another monitor there > either. > > Are you using HDMI for both monitors? Or something else? Any adapters in > between? It is the 3.8-rc2 kernel which I linked to earlier, yes. I think the drm.debug is perhaps causing them to either not get logged, or there is just too much information from drm.debug, and they end up not appearing. The output of running 'dmesg' and looking at /var/log/dmesg are not consistent. I am not using HDMI for any monitors. The board doesn't even have HDMI. It has 2 DVI ports, and one Displayport. I'm using DVI for both monitors. No adapters for anything. Monitors are both Samsung 2343BWX. When trying to configure the second display to a working resolution (1280x800), then back to the native resolution, and finally back to mirroring, I get this from "dmesg|grep fdi" : [85024.350500] [drm:ironlake_check_fdi_lanes], checking fdi config on pipe 1, lanes 1 [85024.573818] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR before link train 0x0 [85024.574471] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x100 [85024.574474] [drm:ivb_manual_fdi_link_train], FDI train 1 done, level 0. [85024.575126] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x600 [85024.575129] [drm:ivb_manual_fdi_link_train], FDI train 2 done, level 0. [85024.575131] [drm:ivb_manual_fdi_link_train], FDI train done. [85072.643845] [drm:ironlake_check_fdi_lanes], checking fdi config on pipe 1, lanes 2 [85072.867168] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR before link train 0x0 [85072.867821] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.868322] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.868824] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.869325] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.869329] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [85072.869982] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.870481] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.870984] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.871484] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85072.871486] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [85072.871487] [drm:ivb_manual_fdi_link_train], FDI train done. [85089.743424] [drm:ivb_modeset_global_resources], disabling fdi C rx [85089.745990] [drm:ironlake_check_fdi_lanes], checking fdi config on pipe 1, lanes 2 [85089.745995] [drm:cpt_enable_fdi_bc_bifurcation], enabling fdi C rx [85089.911413] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR before link train 0x0 [85089.912066] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.912567] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.913068] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.913569] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.913573] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [85089.914225] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.914724] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.915230] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.915730] [drm:ivb_manual_fdi_link_train], FDI_RX_IIR 0x0 [85089.915732] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [85089.915733] [drm:ivb_manual_fdi_link_train], FDI train done.
Is this (In reply to comment #15) Can you still reproduce this? Could you give a go the following patch from Jesse? Might be still somewhat WIP: http://lists.freedesktop.org/archives/intel-gfx/2013-March/026247.html
Also please test Paulo's patch from bug #60039 https://bugs.freedesktop.org/attachment.cgi?id=77018
With the two mentioned patches, and the Ubuntu Raring 3.8.0-16.26 kernel, I am no longer seeing the link train errors in dmesg when trying to use the second display. Instead, I am now getting a lot of traces in dmesg, all very similar to this one: [ 506.787670] ------------[ cut here ]------------ [ 506.787700] WARNING: at /tmp/buildd/linux-3.8.0/drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0xe2/0x1a0 [i915]() [ 506.787703] Hardware name: [ 506.787704] pipe_off wait timed out [ 506.787705] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) vboxdrv(OF) parport_pc ppdev rfcomm bnep bluetooth binfmt_misc nls_iso8859_1 kvm_intel kvm ghash_clmulni_intel aesni_intel aes_x86_64 xts lrw gf128mul ablk_helper cryptd microcode joydev snd_hda_intel snd_usb_audio snd_hda_codec snd_usbmidi_lib snd_hwdep snd_pcm snd_page_alloc tpm_tis snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer lpc_ich i915 snd soundcore video drm_kms_helper mei drm i2c_algo_bit w83627ehf hwmon_vid mac_hid coretemp lp parport hid_generic usbhid hid usb_storage firewire_ohci firewire_core ahci crc_itu_t libahci e1000e [ 506.787750] Pid: 1700, comm: Xorg Tainted: GF W O 3.8.0-16-generic #26 [ 506.787752] Call Trace: [ 506.787759] [<ffffffff810587df>] warn_slowpath_common+0x7f/0xc0 [ 506.787762] [<ffffffff810588dc>] warn_slowpath_fmt+0x4c/0x50 [ 506.787777] [<ffffffffa0196d22>] intel_wait_for_pipe_off+0xe2/0x1a0 [i915] [ 506.787790] [<ffffffffa0196ef6>] intel_disable_pipe+0x116/0x190 [i915] [ 506.787801] [<ffffffffa019769b>] ironlake_crtc_disable+0xdb/0x880 [i915] [ 506.787816] [<ffffffffa010995c>] ? drm_mode_create+0x4c/0x80 [drm] [ 506.787830] [<ffffffffa019f34b>] intel_set_mode+0x36b/0xa30 [i915] [ 506.787844] [<ffffffffa01a0126>] intel_crtc_set_config+0x716/0x950 [i915] [ 506.787856] [<ffffffffa010bc21>] drm_mode_setcrtc+0x121/0x5a0 [drm] [ 506.787867] [<ffffffffa00fc559>] drm_ioctl+0x4e9/0x5b0 [drm] [ 506.787878] [<ffffffffa010bb00>] ? drm_mode_setplane+0x370/0x370 [drm] [ 506.787883] [<ffffffff811a5849>] do_vfs_ioctl+0x99/0x570 [ 506.787887] [<ffffffff811a5db1>] sys_ioctl+0x91/0xb0 [ 506.787892] [<ffffffff816d32dd>] system_call_fastpath+0x1a/0x1f [ 506.787894] ---[ end trace 383823ffb51e7397 ]---
(In reply to comment #18) Setting as fixed based on the above. The issue related to the WARN is tracked in bug#54687.
Nope, the pipe off timeout in bug #54687 is for ilk, this here is an ivb. Until proven otherwise we need to presume that they're different bugs.
Also, even with the link train issue "resolved" and the new crash appearing, the multiple displays still don't work, so I wouldn't consider this "fixed" until both outputs work correctly at the same time, as they are supposed to.
What new crash? You didn't actually mention that the screen was still blank...
The trace I posted which gets logged to dmesg, obviously. And if both monitors were working, I would have not even noticed said trace, and marked the bug as fixed, given I'd have two working monitors with the built-in graphics, rather than having to buy a low-end Nvidia card that breaks my audio setup, to get my second screen back because I've gotten tired of having my monitor not being usable. Bug is "multiple displays not working". Must I restate that they still do not work in every single post, rather than the implicit fact that they don't given that I haven't changed the bug status or said "this works great now, thanks for fixing it, please change to fix once this patch is landed," or similar?
Considering that the only failure in the previous dmesg was the FDI link failure, and that implies the displays would be blank, that it was fixed it was natural for to presume the bug was fixed. Now we find ourselves without uptodate information on what your bug is, so please do attach the full dmesg from the failure case.
I have upgraded to a new version of Ubuntu now, which is using 3.10.0-6, as well as the latest version of the BIOS for this board, from Intel. The second screen is completely red, and link train errors are occurring: : dmesg|grep drm [ 7.281683] [drm] Initialized drm 1.1.0 20060810 [ 7.336154] [drm] Memory usable by graphics device = 2048M [ 7.363067] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 7.363068] [drm] Driver supports precise vblank timestamp query. [ 7.518730] fbcon: inteldrmfb (fb0) is primary device [ 7.967035] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 7.969178] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [ 7.999397] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 8.010650] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 8.498526] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 8.498527] [drm] No driver support for vblank timestamp query. [ 8.526924] [drm] Cannot find any crtc or sizes - going 1024x768 [ 8.559688] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 1 [ 8.772839] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [ 57.936050] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 57.938196] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! [ 58.207998] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [ 58.210144] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! The bug is certainly not fixed. There is no new information, because no further information has been asked for until now, and I've purchased a cheap PCIe NVidia card, so that I could get both monitors working in the meantime, as being able to use both of my monitors is necessary. I didn't buy a second one to never use it.
(In reply to comment #24) > Now we find ourselves without uptodate information on what your bug is, so > please do attach the full dmesg from the failure case. Rodney, please post the full dmesg from the failure case. Since plenty of time has passed, please use a later kernel. Thanks.
(In reply to comment #26) > Rodney, please post the full dmesg from the failure case. Since plenty of > time has passed, please use a later kernel. Thanks. I've just upgraded the machine to Ubuntu Trusty development series, which has kernel 3.12.0-7.15. The second display is still blank, but there are no link train errors showing up in the dmesg output.
Now running 3.13.0-1 on Ubuntu, and second display still not working, and no link train errors in dmesg. Second screen remains black. I can use both screens only when I set them to an extremely low resolution of 1280x800 each. Any higher resolution, and the second screen remains black. If I run "xrandr --output HDMI3 --crtc 2" the second screen displays the mirrored copy of the first screen, but I don't seem to be able to disable mirroring with that. Disabling mirroring results in the second screen returning to black.
Playing with xrandr some more, I have gotten "xrandr --output HDMI1 --crtc 0 --output HDMI3 --crtc 2 --right-of HDMI1" to work. I can use both screens at full resolution, with this command. I don't know if it will stick after a reboot, but I will comment here as soon as I do reboot.
After getting the second monitor working properly with xrandr faffing, the settings do not stick after a reboot, unfortunately. How can I get it to work correctly by default, every time?
Can you please attach a new dmesg when trying to set up the output configuration on 3.13? Please boot with drm.debug=0xe. Also please do the manual xrandr dance which makes things work and again grab the complete dmesg. You might need to increase the dmesg buffer with log_buf_len if messages start to spill.
Created attachment 93418 [details] dmesg|grep drm output for drm.debug=0xe on 2014-02-04 Here is a drm.debug log with the 3.13.0-6-generic kernel in Ubuntu Trusty. It includes all the drm output from the boot command up to the second display failure when lightdm comes up, another failure for the display to come up after logging in, and it being fixed with the xrandr command (which I've set up to be run automatically 10 seconds after log in).
This is still an issue as of 2014-06-20 on 3.13.0-29-generic in Ubuntu 14.04, however I have now upgraded to a single 4K monitor and a Haswell CPU, so I won't be able to test any further possible fixes for this issue. One thing of note though, is that when X came up on 3.13.0-29, the second monitor did display the correct content for a few hundred milliseconds. The image would flash in and then away very quickly, as the screen turned to a giant solid colored area. Running "xrandr --output HDMI1 --crtc 0 --output HDMI3 --crtc 2 --right-of HDMI1" on log-in did make the second screen usable again.
Since the error reported cannot be reproduced anymore by reporter of reopen let's close this as invalid. Anyone able to reproduce again it feel free to re-reopen. But remind to test on latest drm-intel-nightly.
(In reply to Rodrigo Vivi from comment #34) > Since the error reported cannot be reproduced anymore by reporter of reopen > let's close this as invalid. > Anyone able to reproduce again it feel free to re-reopen. But remind to test > on latest drm-intel-nightly. Well, it's still an issue. I just no longer am using the motherboard/cpu where I was having the problem, and no longer am using multiple displays (I have a single 4K display now, which has a different set of problems on Linux). Closing it as Invalid seems like an inappropriate resolution to the problem. As the motheboard and CPU are both from Intel, I would think it should have been fairly easy for Intel employees working on drivers to get access to them for testing. If the end result is that this isn't going to be fixed at all, then at least have the guts to resolve it WONTFIX rather than insulting me by claiming it is somehow INVALID.
I didn't mean to insult you. But unless we can reproduce or have someone to test latest kernel it is useless to let this entry open. So, it is WORKSFORME until we find a tester for it.
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.