[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station

Discussion:

(too old to reply)

Theodore Ts'o

2014-09-02 04:10:02 UTC

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Dave Airlie

2014-09-02 11:30:02 UTC

Permalink

Post by Theodore Ts'o
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.

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.

Theodore Ts'o

2014-09-02 13:20:01 UTC

Permalink

Post by Dave Airlie
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

Theodore Ts'o

2014-09-26 02:30:02 UTC

Permalink

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

Theodore Ts'o

2014-12-08 00:40:02 UTC

Permalink

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Dave Airlie

2014-12-08 02:40:02 UTC

Permalink

Post by Theodore Ts'o
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

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Theodore Ts'o

2014-12-15 13:30:02 UTC

Permalink

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/