Ubuntu

8086:0162 [Intel DQ77MK] Multiple Displays not working

Reported by Rodney Dawes on 2012-07-06
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
X.Org X server
Confirmed
Medium
linux (Ubuntu)
Medium
Unassigned
Precise
Medium
Unassigned

Bug Description

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.

Also, on the daily live image for Quantal, the system appears to freeze when X starts, and I am left with the primary screen being black, and the secondary screen being full red. The plymouth framebuffer is a fuzzy green image, and everything turns black when X comes up.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xorg 1:7.6+12ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic-pae 3.2.18
Uname: Linux 3.2.0-25-generic-pae i686
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
CompizPlugins: [core,bailer,detection,composite,opengl,decor,gnomecompat,regex,animation,snap,grid,compiztoolbox,move,vpswitch,resize,place,imgpng,mousepoll,workarounds,expo,session,resizeinfo,ezoom,wall,fade,scale,unityshell]
CompositorRunning: None
Date: Fri Jul 6 16:11:55 2012
DistUpgraded: 2012-01-12 17:06:50,933 DEBUG enabling apt cron job
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus:
 nvidia-current, 295.53, 3.2.0-25-generic-pae, i686: installed
 virtualbox, 4.1.12, 3.2.0-25-generic-pae, i686: installed
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 Intel Corporation Ivy Bridge Graphics Controller [8086:0162] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Intel Corporation Device [8086:2035]
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-25-generic-pae root=UUID=e3ff1788-609f-430f-b0e6-f696b2a2e06d ro quiet splash vt.handoff=7
SourcePackage: xorg
UnitySupportTest:
 Error: command ['/usr/lib/nux/unity_support_test', '-p', '-f'] failed with exit code 5: Xlib: extension "GLX" missing on display ":0.0".
 Error: GLX is not available on the system
UpgradeStatus: Upgraded to precise on 2012-01-12 (175 days ago)
dmi.bios.date: 03/20/2012
dmi.bios.vendor: Intel Corp.
dmi.bios.version: MKQ7710H.86A.0034.2012.0320.2026
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: DQ77MK
dmi.board.vendor: Intel Corporation
dmi.board.version: AAG39642-301
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrMKQ7710H.86A.0034.2012.0320.2026:bd03/20/2012:svn:pn:pvr:rvnIntelCorporation:rnDQ77MK:rvrAAG39642-301:cvn:ct3:cvr:
version.compiz: compiz 1:0.9.7.8-0ubuntu1
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3.1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3.1
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1.2
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

Rodney Dawes (dobey) wrote :
Maarten Lankhorst (mlankhorst) wrote :

Sorry, installing nvidia is not going to work for now. I'm working with airlied on prime support for it though, so if lucky it lands in quantal or 12.04.2. Things will probably start working in x1.13 but it will probably still need manual configuration then.

Changed in xorg (Ubuntu):
milestone: none → ubuntu-12.04.2
importance: Undecided → Wishlist
Rodney Dawes (dobey) wrote :

Sorry, there is no Nvidia hardware in this system now. The binary drivers were left around from previous hardware (recently upgraded to this current system). After purging them, and rebooting, the same secondary screen issue ensues, and GL things are very crashy. Also, taking a screenshot does result in the secondary display contents appearing correctly in the PNG.

Maarten Lankhorst (mlankhorst) wrote :

glxgears started working again after nvidia was purged, the colord crash doesn't seem to be important.

Rodney Dawes (dobey) wrote :

Also, I am seeing some drawing problems in GTK+ apps now. I'm not sure if it's a driver or theme problem, though. It was working fine before the nvidia purge. Have mostly noticed it in pidgin as it's always running, visible and mostly idle.

Rodney Dawes (dobey) wrote :

Also, I've enabled the xorg-edgers PPA and upgraded Xorg. The theme issue mentioned in comment #5 may be due to this, but I'm unsure. I also tried kernel 3.5 from that PPA, but when booting that kernel, Xorg locks up the system in some manner such that there is no keyboard or mouse input, nor does the soft power button work to shut down correctly. The cursor in the lightdm screen for password entry continued to blink though, and during one attempt to use 3.5, I did notice on the lightdm screen, there appeared to be a framebuffer vt cursor blinking in the upper left as well.

I would be very happy to have this fixed, and even install Quantal on this machine, but I can't install it while the system just freezes at the end of the boot sequence (as it also does on the daily live images now).

Rodney Dawes (dobey) wrote :

The weird graphics artifacts in the apps I've noticed seem to have gotten worse than when I made that comment. It does seem to be driver related, though, as a large portion of the background was also having issues at one point, when a redraw happened, and several rectangular sections were just black until a window was moved over top of it. Looked like possibly an issue with the frame buffer, and is likely a driver issue. That was with current 12.04 3.2.0 kernel, and xorg-edgers Xorg server.

Maarten Lankhorst (mlankhorst) wrote :

can you try the lts-quantal kernel on precise? https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport

Rodney Dawes (dobey) wrote :

Using the 3.5.0-3.3 kernel from the q-lts-backport archive, and xorg from precise, the system boots and appears usable, but still the same issue with the second display being 100% red. It also appears the quantal daily image from today sort of works again, after a few toggles of the mirror display option, and a few clicks of the apply button, in the display prefs. Before that toggling, the screen was very fuzzy and blinky. After a few cycles of that, it settled down to draw appropriate colors and seemed stable, though the second screen was still 100% red on today's daily image, as well. So this bug definitely seems to affect both quantal and precise.

Maarten Lankhorst (mlankhorst) wrote :

1280x800 on both screens at the same time work, both screens at 2048x1152 fails, regardless of whether mirrored is enabled in Xorg.

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.

affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
tags: added: rls-q-incoming

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

Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Incomplete

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.

Regarding the comment and time remaining before the quantal release, putting this one the not fixing list for 12.10. But if Maarten has the time to look at it, please go for it :)

tags: added: rls-q-notfixing
removed: rls-q-incoming

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. :)

Changed in xorg-server:
status: Incomplete → Confirmed

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed

Same issue on a Thinkpad W530 (with Nvidia Optimus + Intel HD4000). Uses Intel driver by default. Second screen is not detected. On Quantal 12.10 x64. Also tested xorg-edgers (with no success and messy graphics as mentioned in this thread) and ubuntu-x-swap/x-updates (which is currently off-line it seems, so I have no idea whether I actually have those updates or not yet).

Aaron Culich (aculich) wrote :

Same issue on a Thinkpad T430s (with Intel HD4000 only, no Nvidia Optimus).

Output from:

lspci -v -s 00:02.0

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device 21fb
 Flags: bus master, fast devsel, latency 0, IRQ 46
 Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
 Memory at c0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at 5000 [size=64]
 Expansion ROM at <unassigned> [disabled]
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Capabilities: [d0] Power Management version 2
 Capabilities: [a4] PCI Advanced Features
 Kernel driver in use: i915
 Kernel modules: i915

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 ...).

Changed in xorg-server:
status: Confirmed → Fix Released

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.

Moved this to the kernel package, as it's a kernel drm driver issue with FDI link train failures on IvyBridge. I reset the priority to undecided, as I'm not sure wishlist is appropriate, but not sure what other one is. This is definitely a kernel bug, though.

affects: xserver-xorg-video-intel (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
milestone: ubuntu-12.04.2 → none
importance: Wishlist → Undecided

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.

Changed in xorg-server:
status: Fix Released → Incomplete

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.8 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc2-raring/

Changed in linux (Ubuntu):
importance: Undecided → Medium
Changed in linux (Ubuntu Quantal):
importance: Undecided → Medium
Changed in linux (Ubuntu Precise):
importance: Undecided → Medium
status: New → Confirmed
Changed in linux (Ubuntu Raring):
status: Confirmed → Incomplete
tags: added: raring
Changed in linux (Ubuntu Quantal):
status: New → Confirmed

Created attachment 72641
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?

Download full text (3.5 KiB)

(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...

Read more...

Changed in xorg-server:
status: Incomplete → Confirmed

@Joseph, it's still not fixed in current raring as evidenced by my last comment on the upstream bug. And it's also not working any better with the current kernel build (3.8.0-4).

Changed in linux (Ubuntu Raring):
status: Incomplete → Confirmed
Rodney Dawes (dobey) wrote :

This is still an issue on the 3.8.0-12-generic kernel as well.

Rodney Dawes (dobey) wrote :

And with the 3.8.0-13.23 version as well. However, the second display is stuck on brown, instead of red or black now. The link train failures are still occurring though.

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

Changed in xorg-server:
status: Confirmed → Incomplete

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?

Changed in xorg-server:
status: Incomplete → Confirmed

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.

Rodney Dawes, as per https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Desktop+Boards&ProductLine=Intel%C2%AE+7+Series+Chipset+Boards&ProductProduct=Intel%C2%AE+Desktop+Board+DQ77MK an update is available for your BIOS (0060). If you update to this, does it change anything?

If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful.

Thank you for your understanding.

tags: added: bios-outdated-0060 needs-upstream-testing regression-potential
tags: added: quantal
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Rodney Dawes (dobey) wrote :

The BIOS update did not help. Here is the new information:

MKQ7710H.86A.0060.2013.0618.1012
06/18/2013

I am now also running on Ubuntu Saucy 13.10, with kernel 3.10.0-6-generic.

The second display is entirely red, and the fdi link train failures are still occurring:

[ 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!

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.

Rodney Dawes, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

tags: added: latest-bios-0060
removed: bios-outdated-0060
tags: added: saucy
summary: - Multiple Displays not working on Core i7 3770S + Intel DQ77MK
- motherboard
+ 8086:0162 [Intel DQ77MK] Multiple Displays not working
Rodney Dawes (dobey) wrote :

Is there a specific version I should test? I see 3.11-rc5 mentioned, but 3.11.0-1-generic was installed as an update when I did a dist-upgrade earlier today, and the bug is still present there. Given that, I would also expect the bug to be present in upstream 3.11-rc5.

Also, this is not trivial to test. The machine is mounted in a rack, with little space to access the DVI ports, and it's a production use workstation PC. Every time I test this, I have to stop any work I may be doing, power off the machine, wedge myself in to be able to adjust the cables, and on occasion have to muck about in BIOS so that the right driver is used (internal vs. nvidia pcie), reboot with whatever kernel, and then muck about in settings to see if it triggers everything. It's not a test system I can just upgrade, reboot, and check new kernels at will. So unless there is some specific set of changes in a new kernel which points to the possibility of the issue being fixed, I'd prefer not to waste my time, or the kernel developers', trying to test things that won't work.

no longer affects: linux (Ubuntu Quantal)
no longer affects: linux (Ubuntu Raring)
tags: added: kernel-unable-to-test-upstream
removed: needs-upstream-testing quantal raring rls-q-notfixing
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Rodney Dawes (dobey) wrote :

I've also removed the Quantal and Raring tasks, as they are non-LTS releases, and I don't see the chance of this being fixed in them because of that.

tags: added: needs-upstream-testing quantal raring rls-q-notfixing
tags: added: bios-outdated-0061
removed: latest-bios-0060
tags: removed: kernel-unable-to-test-upstream
Rodney Dawes (dobey) wrote :

The BIOS update rev 0061 lists no changes in its release notes file, that would be potentially related to this issue.

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 are approaching release and would like to confirm if this bug is still present. Please test again with the latest development 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.

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

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.11.0-7.14
Rodney Dawes (dobey) wrote :

This is still an issue, even on the 13.10 RC kernel:

$: dmesg|grep link_train && uname -r
[ 9.766419] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
[ 9.768562] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
[ 118.902507] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
[ 118.904671] [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
3.11.0-12-generic

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Rodney Dawes (dobey) wrote :

I've removed the i386 tag as well as the tag for requesting test on an older kernel than is currently available. I was running 12.04 32-bit when originally filing this bug, but have long since upgraded to a 64-bit only system, after installing a new hard drive.

tags: removed: i386 kernel-request-3.11.0-7.14

Rodney Dawes, as per https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Desktop+Boards&ProductLine=Intel%C2%AE+7+Series+Chipset+Boards&ProductProduct=Intel%C2%AE+Desktop+Board+DQ77MK an update is available for your BIOS (0064). If you update to this following https://help.ubuntu.com/community/BiosUpdate , does it change anything?

If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful.

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

tags: added: i386
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: bios-outdated-0064
removed: bios-outdated-0061
Rodney Dawes (dobey) wrote :

Christopher, must I really waste our time by updating the BIOS every time a fix for the Q77 chip set comes out? It's a pain to do the BIOS update, and it's a pain to test this bug specifically, because it requires several reboots and shifting cables behind a rack.

If you read the Release Notes for the BIOS update, which are at http://downloadmirror.intel.com/23256/eng/MK_0064_ReleaseNotes.pdf , you can see that none of the fixes are directly related to the integrated graphics support, and that the integrated graphics option ROM version has not changed in quite some time.

I understand if the option ROM was updated as well, or there was a fix mentioned that was specifically related to the graphics support, but updating every time there's an update available, is a waste of time.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

Rodney Dawes, this BIOS update would still need to occur. For more on this, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Rodney Dawes (dobey) wrote :

Christopher, while I appreciate your passion for triaging bugs, and wishing to strictly adhere to process or protocol, a BIOS update that will not fix anything is unnecessary, and a waste of time. One can easily see by looking at the release notes of the BIOS update that it will not affect this issue, and one can also see by looking at the history of this report (including of the upstream report which is linked from this bug), that it has been accepted by upstream as a bug in the kernel, by a developer who works directly on the Intel drivers, for Intel.

Unless the Graphics Option ROM version in the BIOS update has changed, it is going to be an irrelevant update, in relation to this bug. So please don't waste my time (and anyone else who may be watching this bug), by insisting that a BIOS update be applied, where the Graphics Option ROM version has not changed.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

Rodney Dawes, as you may know, and previously documented to you, not everything that is addressed in a BIOS update has a comment to it. As well, the notes don't make comments to the results of testing in linux. Hence, one wouldn't know if this would have an impact or not, as one hasn't updated it yet.

What is unfortunate is you insisting on having a valid report, when you have outdated hardware firmware, and then arguing about it.

Rodney Dawes (dobey) wrote :

Christopher, no, making the assumption that something may be "fixed" by a BIOS update, which contains no documentation relevant to the issue, is exactly that; an assumption. There is no evidence that suggests a BIOS update would fix something that is not documented in the release notes for the update.

This is a bug report against the Linux kernel, not against the Intel MQ77 BIOS. There is no reason to assume it is a problem with the BIOS. The bug has existed for well over a year now, and assuming that it is going to be magically fixed with a BIOS update is nonsense. The history of the report clearly shows it has been accepted as a valid bug report by upstream (whom as I already stated, is an Intel device driver developer, working for Intel), against the kernel.

I am not going to waste time trying to update to a new BIOS and performing the tedious procedure of testing the issue, when there is absolutely zero evidence that it could have any impact on the issue at all.

(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.

tags: added: trusty

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.

Changed in xorg-server:
status: Confirmed → Incomplete

Created attachment 93418
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).

Changed in xorg-server:
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.