[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel.
If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station).
Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of
https://bugs.freedesktop.org/show_bug.cgi?id=71267
Except the system isn't hanging; it's just not seeing the monitor at all.
Thanks,
- Ted
On 2 September 2014 14:05, Theodore Ts'o tytso@mit.edu wrote:
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel.
If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station).
Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of
https://bugs.freedesktop.org/show_bug.cgi?id=71267Except the system isn't hanging; it's just not seeing the monitor at all.
Have you the Dell 30" set to Displayport 1.2 enabled mode?
If so, then see if disabling that in the monitor menus helps.
This is probably due to the fact we now attempt to talk to new DP devices with the protocol they provide. So previously the monitor exposed DP 1.2 and we just didn't care, now if it exposes it we attempt to talk to it.
Dave.
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
On 2 September 2014 14:05, Theodore Ts'o tytso@mit.edu wrote:
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel.
If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station).
Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of
https://bugs.freedesktop.org/show_bug.cgi?id=71267Except the system isn't hanging; it's just not seeing the monitor at all.
Have you the Dell 30" set to Displayport 1.2 enabled mode?
No, it DP 1.2 was disabled. If I enable it, it breaks things when I try connecting via the MiniDP port (bypassing the dock), and it is still broken when I try to talk via the DisplayPort in the dock.
If I disable DP 1.2 again, it works via the MiniDP port, but if I try to connect through the dock (which has a DP Hub which I believe is MST/DP 1.2 capable), it is still broken.
It does seem that this might be related to 3.17-rc3 trying to talk DP 1.2 if it is available, since I can't control what the DP hub in the docking station advertises --- is there a commit or some kind of hack I can try to force talking to the DP hub using DP 1.1?
- Ted
On 2 September 2014 21:03, Theodore Ts'o tytso@mit.edu wrote:
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
On 2 September 2014 14:05, Theodore Ts'o tytso@mit.edu wrote:
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel.
If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station).
Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of
https://bugs.freedesktop.org/show_bug.cgi?id=71267Except the system isn't hanging; it's just not seeing the monitor at all.
Have you the Dell 30" set to Displayport 1.2 enabled mode?
No, it DP 1.2 was disabled. If I enable it, it breaks things when I try connecting via the MiniDP port (bypassing the dock), and it is still broken when I try to talk via the DisplayPort in the dock.
If I disable DP 1.2 again, it works via the MiniDP port, but if I try to connect through the dock (which has a DP Hub which I believe is MST/DP 1.2 capable), it is still broken.
It does seem that this might be related to 3.17-rc3 trying to talk DP 1.2 if it is available, since I can't control what the DP hub in the docking station advertises --- is there a commit or some kind of hack I can try to force talking to the DP hub using DP 1.1?
Interesting, I have the same combo of hw available on my desk at work, but it might be a couple of days before I can get to the office to debug it,
can you boot with drm.debug=6 and get me the dmesg?
The attached hack turns off mst so might be useful as a workaround, but I should be able to fix this once I sit down at my desk.
Dave.
On Tue, Sep 02, 2014 at 09:23:16PM +1000, Dave Airlie wrote:
Interesting, I have the same combo of hw available on my desk at work, but it might be a couple of days before I can get to the office to debug it,
can you boot with drm.debug=6 and get me the dmesg?
I'll do that when I get home. In the meantime, here's an additional data point. At work, I have the same model docking station connected to a 2011 Dell 2410f Rev A04 (max resolution 1920x1200, and I suspect not DP 1.2 capable; at least, it doesn't mention DP in monitor menu) --- and connecting through the docking station, it does work (connecting through either DVI or DisplayPort).
Here's the drm.debug=6 connecting to the docking station via DVI. I can get a drm.debug=6 connecting via the DP and the docking station if that would be helpful. Similarly, if you want, I can also try to get a debug run connecting to the HP ZRW30 monitor (either direct or via the docking station), since that's the monitor on the walkstation. :-)
Cheers,
- Ted
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
On 2 September 2014 14:05, Theodore Ts'o tytso@mit.edu wrote:
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel.
If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station).
Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of
https://bugs.freedesktop.org/show_bug.cgi?id=71267Except the system isn't hanging; it's just not seeing the monitor at all.
Have you the Dell 30" set to Displayport 1.2 enabled mode?
If so, then see if disabling that in the monitor menus helps.
This is probably due to the fact we now attempt to talk to new DP devices with the protocol they provide. So previously the monitor exposed DP 1.2 and we just didn't care, now if it exposes it we attempt to talk to it.
Hi Dave,
I've since upgraded to a newer X server, which may have been responsible for the symptoms somewhat. It now doesn't seem to matter whether the Dell 30" monitor is set to DP 1.2 or not. It now will find the Dell 30" monitor reliably when the system is freshly booted, attached to the Dock. If I then suspend the laptop, remove it from the dock, unsuspend it from the laptop, then resuspend the laptop, and return it to the dock, it can no longer see the monitor until I reboot.
I am currently running 3.17-rc4 based kernel, and I have the following X server components:
ii xserver-xorg 1:7.7+7 amd64 X.Org X server ii xserver-xorg-core 2:1.16.0.901-1 amd64 Xorg X server - core server ii xserver-xorg-video-intel 2:2.21.15-2+b2 amd64 X.Org X server -- Intel i8xx, i9xx display driver
Here is the dmesg file with drm.debug=6. Could you take a quick look and see if anything obvious jumps out at you?
Thanks,
- Ted
This is an update to a problem which I reported several months ago (see below). The symptoms have changed a bit since then, but they've stablized since 3.17 and 3.18-rcX, and while annoying, it's tolerable, so I've been living with it.
What I'm basically seeing now is that any external monitor (either a Dell 30" or Dell 24") will be seen after a reboot or a restart of the X server. But if suspend the laptop, disconnect from the dock, and resume, and then later on, reconnect to the dock, the external monitors are not visible until I kill and restart the X server. Another part of the symptom is when I try to probe for the monitors, using either xrandr or xfce4-display-settings, the system freezes for a second or two, and then when it recovers, if I look in the logs, I see the following warning message, repeated twice:
[246289.614639] WARNING: CPU: 0 PID: 29875 at /usr/projects/linux/linux/drivers/gpu/drm/i915/intel_pm.c:6585 intel_display_power_put+0x4b/0x116 [i915]() [246289.614640] Modules linked in: iptable_filter ip_tables x_tables rfcomm ctr ccm binfmt_misc bnep hid_generic usbhid uvcvideo hid videobuf2_vmalloc videobuf2_memops videobuf2_core btusb bluetooth snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp crc32_pclmul ghash_clmulni_intel pcspkr serio_raw i2c_i801 thinkpad_acpi nvram snd_hda_codec_realtek snd_hda_codec_generic tpm_tis iwlmvm mac80211 i915 drm_kms_helper drm iwlwifi intel_smartconnect intel_gtt snd_hda_intel cfg80211 lpc_ich mfd_core snd_hda_controller snd_hda_codec xhci_pci snd_hwdep xhci_hcd kvm_intel kvm ecryptfs encrypted_keys trusted tpm parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq microcode ehci_pci ehci_hcd e1000e ptp pps_core [246289.614675] CPU: 0 PID: 29875 Comm: Xorg Tainted: G W 3.18.0-rc7-00028-g455e143 #108 [246289.614676] Hardware name: LENOVO 20BECTO1WW/20BECTO1WW, BIOS GMET59WW (2.07 ) 02/12/2014 [246289.614677] 0000000000000009 ffff8802048e3a68 ffffffff815cb640 0000000000000006 [246289.614679] 0000000000000000 ffff8802048e3aa8 ffffffff8106de00 ffff8802048e3aa8 [246289.614681] ffffffffa04a7441 ffff880405610044 ffff880405610000 ffff880405438890 [246289.614683] Call Trace: [246289.614689] [<ffffffff815cb640>] dump_stack+0x4e/0x68 [246289.614692] [<ffffffff8106de00>] warn_slowpath_common+0x81/0x9b [246289.614702] [<ffffffffa04a7441>] ? intel_display_power_put+0x4b/0x116 [i915] [246289.614704] [<ffffffff8106debd>] warn_slowpath_null+0x1a/0x1c [246289.614713] [<ffffffffa04a7441>] intel_display_power_put+0x4b/0x116 [i915] [246289.614731] [<ffffffffa04e6d0c>] modeset_update_crtc_power_domains+0xd8/0x117 [i915] [246289.614746] [<ffffffffa04e7153>] haswell_modeset_global_resources+0xe/0x10 [i915] [246289.614760] [<ffffffffa04e8122>] __intel_set_mode+0x9a5/0x1204 [i915] [246289.614775] [<ffffffffa04ef271>] ? intel_crtc_set_config+0x151/0xa98 [i915] [246289.614789] [<ffffffffa04eec0a>] intel_set_mode+0x16/0x2f [i915] [246289.614802] [<ffffffffa04ef8d2>] intel_crtc_set_config+0x7b2/0xa98 [i915] [246289.614815] [<ffffffffa0426b83>] drm_mode_set_config_internal+0x59/0xe5 [drm] [246289.614823] [<ffffffffa0426c9d>] drm_framebuffer_remove+0x8e/0x104 [drm] [246289.614832] [<ffffffffa042a046>] drm_mode_rmfb+0xdc/0x101 [drm] [246289.614839] [<ffffffffa041de40>] drm_ioctl+0x38a/0x429 [drm] [246289.614847] [<ffffffffa0429f6a>] ? drm_mode_addfb2+0x30/0x30 [drm] [246289.614849] [<ffffffff8127fe04>] ? avc_has_perm+0x35/0x99 [246289.614852] [<ffffffff810c5e4c>] ? read_seqcount_begin.constprop.25+0x5a/0x70 [246289.614855] [<ffffffff81194eb1>] do_vfs_ioctl+0x3ab/0x45e [246289.614857] [<ffffffff8128075f>] ? file_has_perm+0x5d/0x81 [246289.614859] [<ffffffff810ededf>] ? __audit_syscall_entry+0xcd/0xef [246289.614861] [<ffffffff81194fbe>] SyS_ioctl+0x5a/0x7f [246289.614864] [<ffffffff815d39d6>] system_call_fastpath+0x16/0x1b [246289.614865] ---[ end trace 238ba2a27a19ffce ]---
(The above stack trace came from a 3.17-rc7 based kernel.)
Looking at the code, we seem to be triggering on the following WARN_ON in intel_display_power_put:
WARN_ON(!power_domains->domain_use_count[domain]); power_domains->domain_use_count[domain]--;
This warning does *not* appear after a fresh reboot, logging in, and then running xfce4-display-settings, so I assume that part of the problem is that the internal kernel state is getting corrupted when the laptop is undocked and the display disappears while the laptop is suspend, and the internal state inconsistency / corruption persists even though killing and restarting the X server seems to make things the external display monitor become visible again.
This is consistent with the observation that sometimes the laptop will lock up after either (a) resuming with the dock attached or (b) if the external monitor is accidentally powered off (the power button on the dell monitor is way too easy to accidentally hit), and the only way to recover is with a magic sysrq reboot or a forced power cycle.
This is a not a regression, and it's been this way for several months (including 3.17.0), but I've been too busy to really try to debug this until now.
Hopefully the above is helpful; if there's anything more debugging information I can get, let me know!!
- Ted
On Tue, Sep 02, 2014 at 12:05:27AM -0400, Theodore Ts'o wrote:
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel.
If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station).
Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of
https://bugs.freedesktop.org/show_bug.cgi?id=71267
Except the system isn't hanging; it's just not seeing the monitor at all.
On 8 December 2014 at 10:34, Theodore Ts'o tytso@mit.edu wrote:
This is an update to a problem which I reported several months ago (see below). The symptoms have changed a bit since then, but they've stablized since 3.17 and 3.18-rcX, and while annoying, it's tolerable, so I've been living with it.
What I'm basically seeing now is that any external monitor (either a Dell 30" or Dell 24") will be seen after a reboot or a restart of the X server. But if suspend the laptop, disconnect from the dock, and resume, and then later on, reconnect to the dock, the external monitors are not visible until I kill and restart the X server. Another part of the symptom is when I try to probe for the monitors, using either xrandr or xfce4-display-settings, the system freezes for a second or two, and then when it recovers, if I look in the logs, I see the following warning message, repeated twice:
I suspect a lot of the problems are just that xfce isn't sufficiently handling randr events, and it is getting out of sync, it is like hotplug networking before NetworkManager etc.
I just tried using XFCE from F21 and if I leave the display settings app open it crashes hard when I tried the cycle above, which didn't lend me much confidence, it also never reenabled the monitor when it came back,
I've tried a few cycles of this with GNOME desktop and it seems to work pretty well.
I'll try reproducing the exact problem you are seeing however,
I haven't managed that with drm-next tree which has v3.18 merged now.
The i915 driver also has a tendency to WARN_ON on pointless things, the i915 developers insist these are actual bugs, but don't insist on producing patches to fix them in a reasonable time frame or if they do, they add 5 more WARN_ONs to compensate.
Dave.
On Mon, Dec 08, 2014 at 12:32:01PM +1000, Dave Airlie wrote:
I suspect a lot of the problems are just that xfce isn't sufficiently handling randr events, and it is getting out of sync, it is like hotplug networking before NetworkManager etc.
Yes, I've seen this on XFCE 4.11 (in Ubuntu), although I haen't seen it in XFCE 4.10 (in Debian). In 4.11, when xfce gets out of sync, xrandr --auto will allow me to enable the display, even when xfce4-display-settings does not.
However, on my T540p with the monitors connected via the dock, which is the problem I was describing here, xrandr --auto does *not* fix things up. So I think it's a different problem, since I can see this problem even if I don't use xfce4-display-settings, and just use xrandr directly.
- Ted
This morning, I was docked and using a Dell 30" monitor. I reconfigured the X server to stop sending video to the external monitor, suspended the laptop, and after it was suspended undocked it and took it to work. Then I docked it at work, where it was connected to a powered off Dell 24" monitor.
Since this time there was a note:
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [drm] GPU crash dump saved to /sys/class/drm/card0/error
I've filed:
https://bugs.freedesktop.org/show_bug.cgi?id=87327
I do want to note that this is only one of many different symptoms and failures that I am seeing.
Basically, after suspending and resuming, if I use an external monitor, I have to be prepared to restart the X server --- and sometimes the kernel will sponaneously reboot, sometimes when I do something as simple as accidentally brushing against the power switch on the Dell montor. :-( :-( :-(
- Ted
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Theodore Ts'o