Bug 71267 - sna: (Haswell) X-server freezes when enabling DP at docking station
Summary: sna: (Haswell) X-server freezes when enabling DP at docking station
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Todd Previte
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 72314
  Show dependency treegraph
 
Reported: 2013-11-05 14:00 UTC by Daniel Martin
Modified: 2017-07-24 22:56 UTC (History)
50 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg 3.11.6 (drm.debug=0x7) (165.73 KB, text/plain)
2013-11-05 14:01 UTC, Daniel Martin
no flags Details
Xorg.0.log (intel git:dc61705, --enable-debug=full) (352.38 KB, text/plain)
2013-11-05 14:03 UTC, Daniel Martin
no flags Details
dmesg 3.11.6 (drm.debug=0xe) (93.70 KB, text/plain)
2013-11-05 14:41 UTC, Daniel Martin
no flags Details
dmesg 3.12.0 (drm.debug=0xe) (93.34 KB, text/plain)
2013-11-06 12:41 UTC, Daniel Martin
no flags Details
dmesg, v3.12.0 + Patch from comment #11 - BUG: bad unlock balance detected! (49.94 KB, text/plain)
2013-11-14 12:04 UTC, Daniel Martin
no flags Details
dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop) (87.64 KB, text/plain)
2013-11-27 16:32 UTC, Daniel Martin
no flags Details
dmesg 3.13.0-rc1 (93.82 KB, text/plain)
2013-11-27 16:34 UTC, Daniel Martin
no flags Details
dmesg 3.11 (working! - with preemption) (81.15 KB, text/plain)
2013-11-28 08:54 UTC, Daniel Martin
no flags Details
dmesg 3.13.0-rc1 with hack from comment #24 (97.29 KB, text/plain)
2013-12-02 12:45 UTC, Daniel Martin
no flags Details
patch used for attachment #90101 (2.97 KB, patch)
2013-12-02 12:53 UTC, Daniel Martin
no flags Details | Splinter Review
printk to the rescue (624 bytes, patch)
2013-12-03 12:39 UTC, Daniel Martin
no flags Details | Splinter Review
patch against 3.13-rc4; DP on Ultra Dock works (800 bytes, patch)
2013-12-23 22:02 UTC, Georg Pichler
no flags Details | Splinter Review
dmesg_3.13_docking_hdmi_with_udelay (498.05 KB, text/plain)
2014-01-20 22:02 UTC, Stefan Agner
no flags Details
Enable debug prints in link train path (2.57 KB, text/plain)
2014-01-27 20:33 UTC, Stefan Agner
no flags Details
Docking to a dock with an HDMI connection (200.46 KB, text/plain)
2014-01-27 20:34 UTC, Stefan Agner
no flags Details
Docking to a dock with an DP connection (40.98 KB, text/plain)
2014-01-27 20:34 UTC, Stefan Agner
no flags Details
link-train-delay.patch (656 bytes, patch)
2014-01-27 20:37 UTC, Stefan Agner
no flags Details | Splinter Review
[PATCH]HDMI connection via dock works with some (random) delay (993 bytes, patch)
2014-02-08 12:25 UTC, Sree Harsha Totakura
no flags Details | Splinter Review
Photograph showing green pattern overlays (184.22 KB, image/jpeg)
2014-02-08 12:41 UTC, Sree Harsha Totakura
no flags Details
drm/i915/dp: add max retries in native aux (1.99 KB, patch)
2014-02-10 15:27 UTC, Jani Nikula
no flags Details | Splinter Review
dmesg 3.13 with attachment/patch 93781 - boot with DP connected (78.53 KB, text/plain)
2014-02-11 07:41 UTC, Daniel Martin
no flags Details
dmesg 3.13 with attachment/patch 93781 - hotplug DP (80.22 KB, text/plain)
2014-02-11 07:43 UTC, Daniel Martin
no flags Details
dmesg-debug-3.12.7-with-dock-firmware-2.17.txt (343.46 KB, text/plain)
2014-02-12 08:32 UTC, Stefan Agner
no flags Details
dmesg-jani-patches-docked.txt (123.79 KB, text/plain)
2014-02-12 23:27 UTC, Sree Harsha Totakura
no flags Details
dmesg-jani-patches-undocked.txt (122.76 KB, text/plain)
2014-02-12 23:33 UTC, Sree Harsha Totakura
no flags Details
dmesg with patch applied, old firmware (83.02 KB, text/plain)
2014-02-13 16:17 UTC, Jean-Marc Valin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Martin 2013-11-05 14:00:13 UTC
HW: Lenovo T440s with a Thinkpad Ultra Dock and a Dell U2410

The T440s was at the docking station when powering on.

If I start the X-server, plugin the Monitor to a DP connector at the docking station and call `xrandr --output DP2 --preferred` the X-server freezes. (Doesn't happen without the docking station at the mDP connector directly at the notebook.)

By freeze I mean:
- no cursor movement
- no VT switching

Though the maschine is reachable via ssh:
- X-server ignores `kill -9`

After 2 minutes the following kernel message shows up:
[  480.195776] INFO: task kworker/0:1:34 blocked for more than 120 seconds.    
[  480.195779] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  480.195781] kworker/0:1     D 0000000000000246     0    34      2 0x00000000
[  480.195803] Workqueue: events ironlake_panel_vdd_work [i915]     
[  480.195805]  ffff880118cebd50 0000000000000046 0000000000014500 ffff880118cebfd8
[  480.195809]  ffff880118cebfd8 0000000000014500 ffff880119218870 ffff88011f214570
[  480.195812]  0000000000000001 ffff880118cebcd8 ffffffff8109a884 ffff88011f2d4500
[  480.195816] Call Trace:     
[  480.195822]  [<ffffffff8109a884>] ? dequeue_entity+0x144/0x4d0     
[  480.195825]  [<ffffffff81099815>] ? set_next_entity+0x95/0xb0     
[  480.195829]  [<ffffffff810135a8>] ? __switch_to+0x118/0x4e0     
[  480.195833]  [<ffffffff814e1029>] schedule+0x29/0x70     
[  480.195835]  [<ffffffff814e1463>] schedule_preempt_disabled+0x23/0x30       
[  480.195839]  [<ffffffff814df9d8>] __mutex_lock_slowpath+0x168/0x3b0         
[  480.195843]  [<ffffffff814dfc32>] mutex_lock+0x12/0x30     
[  480.195852]  [<ffffffffa060a8b5>] ironlake_panel_vdd_work+0x25/0x40 [i915]  
[  480.195855]  [<ffffffff8107c6e7>] process_one_work+0x167/0x450     
[  480.195858]  [<ffffffff8107d0f1>] worker_thread+0x121/0x3a0     
[  480.195861]  [<ffffffff8107cfd0>] ? manage_workers.isra.23+0x2b0/0x2b0      
[  480.195865]  [<ffffffff81083960>] kthread+0xc0/0xd0     
[  480.195868]  [<ffffffff810838a0>] ? kthread_create_on_node+0x120/0x120      
[  480.195871]  [<ffffffff814ea52c>] ret_from_fork+0x7c/0xb0     
[  480.195875]  [<ffffffff810838a0>] ? kthread_create_on_node+0x120/0x120

The bug occured with
  o kernel 3.10.12
  o xorg 1.14.3
  o xf86-video-intel 2.11.15

For this test and the following logs it has been reproduced with
  o kernel 3.11.6
  o xorg 1.14.4
  o xf86-video-intel (at git head - dc61705 sna: Use an inplace exchange for large untiled BO).

A test with kernel 3.12 is in the queue.
Comment 1 Daniel Martin 2013-11-05 14:01:02 UTC
Created attachment 88694 [details]
dmesg 3.11.6 (drm.debug=0x7)
Comment 2 Daniel Martin 2013-11-05 14:03:12 UTC
Created attachment 88695 [details]
Xorg.0.log (intel git:dc61705, --enable-debug=full)
Comment 3 Daniel Vetter 2013-11-05 14:16:58 UTC
Can you please boot with drm.debug=0xe added to your kernel cmdline, reproduce the issue (up to the stuck task backtrace) and then grab the complete dmesg? Also retesting on 3.12 might be worth a shot.
Comment 4 Daniel Martin 2013-11-05 14:41:16 UTC
Created attachment 88700 [details]
dmesg 3.11.6 (drm.debug=0xe)
Comment 5 Daniel Martin 2013-11-05 14:45:39 UTC
(In reply to comment #3)
> Can you please boot with drm.debug=0xe added to your kernel cmdline,
> reproduce the issue (up to the stuck task backtrace) and then grab the
> complete dmesg?

Done.

> Also retesting on 3.12 might be worth a shot.

Still takes some time. But, will be done.
Comment 6 Daniel Vetter 2013-11-05 15:33:24 UTC
(In reply to comment #4)
> Created attachment 88700 [details]
> dmesg 3.11.6 (drm.debug=0xe)

There seems to be nothing terrible going wrong leading up to the backtrace. So looks like a new kind of bug. Can you please recompile with lockdep (CONFIG_PROVE_LOCKING) enabled and regrab a drm.debug dmesg of the hang? That should list all the other task hogging the mutex and hopefully shed more light onto what's going wrong here.
Comment 7 Daniel Martin 2013-11-06 12:41:05 UTC
Created attachment 88748 [details]
dmesg 3.12.0 (drm.debug=0xe)
Comment 8 Daniel Martin 2013-11-06 12:43:48 UTC
(In reply to comment #7)
> Created attachment 88748 [details]
> dmesg 3.12.0 (drm.debug=0xe)

Anything else I can/should provide?
Comment 9 Daniel Martin 2013-11-06 13:30:54 UTC
Just rushed through some tests:
- I've tested all the other connectors (HDMI, DVI and VGA) at the docking station with the same technique (boot with notebook in docking station, external monitor not plugged in, start X, connect monitor, enable output via xrandr):
  o The xrandr output was always DP2.
  o All had the same problem, the hung timer showed up for ironlake_panel_vdd_work.

- Additionally, I've tried to boot with the monitor already connected. Here the maschine gets stuck in a very early state (No output on the monitor nor LVDS - well eDP) where the network is not up. So I can't grab any logs here.
Comment 10 Chris Wilson 2013-11-08 19:33:43 UTC
Ah, we maybe corrupting the panel_vdd_work item. Try

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf961698f847..6ac2303f33db 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1161,9 +1161,14 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
                return;
 
        WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
-
        intel_dp->want_panel_vdd = false;
 
+       if (cancel_delayed_work(&intel_dp->panel_vdd_work)) {
+               mutex_unlock(&dev->mode_config.mutex);
+               cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+               mutex_lock(&dev->mode_config.mutex);
+       }
+
        if (sync) {
                ironlake_panel_vdd_off_sync(intel_dp);
        } else {
Comment 11 Chris Wilson 2013-11-08 19:36:34 UTC
And now compiles:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf961698f847..8c2b744b03a3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1161,9 +1161,16 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
                return;
 
        WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
-
        intel_dp->want_panel_vdd = false;
 
+       if (cancel_delayed_work(&intel_dp->panel_vdd_work)) {
+               struct drm_device *dev = intel_dp_to_dev(intel_dp);
+
+               mutex_unlock(&dev->mode_config.mutex);
+               cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+               mutex_lock(&dev->mode_config.mutex);
+       }
+
        if (sync) {
                ironlake_panel_vdd_off_sync(intel_dp);
        } else {
Comment 12 Daniel Vetter 2013-11-09 08:55:08 UTC
Dropping just the config.mutex is dangerous, especially when we also call this function from the disable/enable hooks where we always also hold the relevant crtc->mutex.

I wonder a bit though who's hogging the kms lock - we chase an awful lot of pointers to get at it, so if someone's corrupting this I expect we'd blow up. And lockdep shouldn't be too happy about it either. Confusing.
Comment 13 Chris Wilson 2013-11-09 11:17:58 UTC
(In reply to comment #12)
> I wonder a bit though who's hogging the kms lock - we chase an awful lot of
> pointers to get at it, so if someone's corrupting this I expect we'd blow
> up. And lockdep shouldn't be too happy about it either. Confusing.

My theory is that the work item is being called twice. Crazy, huh? But since we seem to be very cavalier in scheduling the work even if it is already queued, I think it is reasonable to assume that we shoot ourselves in the foot.
Comment 14 Daniel Vetter 2013-11-09 13:16:40 UTC
On Sat, Nov 9, 2013 at 12:17 PM,  <bugzilla-daemon@freedesktop.org> wrote:
> --- Comment #13 from Chris Wilson <chris@chris-wilson.co.uk> ---
> (In reply to comment #12)
>> I wonder a bit though who's hogging the kms lock - we chase an awful lot of
>> pointers to get at it, so if someone's corrupting this I expect we'd blow
>> up. And lockdep shouldn't be too happy about it either. Confusing.
>
> My theory is that the work item is being called twice. Crazy, huh? But since we
> seem to be very cavalier in scheduling the work even if it is already queued, I
> think it is reasonable to assume that we shoot ourselves in the foot.

The work item should check whether it's run already (or whether we
killed the vdd synchronously), so double-scheduling shouldn't be
harmful. If that isn't, we have a big bug.
Comment 15 Daniel Martin 2013-11-13 08:22:10 UTC
(Sorry, I've been stuck at meetings this week and so will I during the rest of the week.)

(In reply to comment #11)
Just had time for a quick boot test with the patch. As soon as i915 loads it raises a kernel panic "unbalanced lock". I'll grab the log later.
Comment 16 Daniel Martin 2013-11-14 12:04:36 UTC
Created attachment 89187 [details]
dmesg, v3.12.0 + Patch from comment #11 - BUG: bad unlock balance detected!
Comment 17 Daniel Martin 2013-11-27 16:32:53 UTC
Created attachment 89905 [details]
dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop)

dmesg wo/ docking station as reference
Comment 18 Daniel Martin 2013-11-27 16:33:44 UTC
(In reply to comment #17)
> Created attachment 89905 [details]
> dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop)

Ups, 3.13.0-rc1.
Comment 19 Daniel Martin 2013-11-27 16:34:33 UTC
Created attachment 89906 [details]
dmesg 3.13.0-rc1

dmesg w/ docking station
Comment 20 Daniel Martin 2013-11-27 16:41:03 UTC
I've retested with v3.13-0-rc1 as can be seen in attachment 89905 [details] (without docking station) and attachment 89906 [details] (with docking station). Additionally, I've added some debug messages "XXX: ..." around the locks of dev->mode_config.mutex.

And I've noticed that there're no calls to intel_dp_set_signal_levels() in the docking station case. Whereas they're in the wo/ docking station case right after haswell_write_eld(). Is that correct?
Comment 21 Daniel Martin 2013-11-28 08:54:01 UTC
Created attachment 89947 [details]
dmesg 3.11 (working! - with preemption)

I've found that the option "Preemptible Kernel (Low-Latency Desktop)" can be used as a workaround for the problem. It doesn't work always, but usually. Tested with v3.9..v3.11.

In the dmesg I can see the call to intel_dp_set_signal_levels() and a few others, which I don't without preemption (attachment 89906 [details]). So, I guess the lack of it before a call to ironlake_panel_vdd_work() is the bug?

As of v3.12 this workaround doesn't work anymore. I've started to bisect it, but stopped as it was to inaccurate (as stated above, it didn't worked always for v3.9..v3.11) and time consuming. And imo it's not that predictable/representable due to preemption anyways. But, if you think that it's worth looking at it, then I could try to completly bisect it.
Comment 22 Chris Wilson 2013-11-28 10:29:20 UTC
Try booting with i915.i915_enable_fbc=0
Comment 23 Daniel Martin 2013-11-28 12:15:41 UTC
(In reply to comment #22)
> Try booting with i915.i915_enable_fbc=0

Tried, doesn't change the result.
Comment 24 Daniel Martin 2013-12-02 09:29:40 UTC
I even tried this in ironlake_panel_vdd_work() before it locks mode_config.mutex:

    if (mutex_is_locked(&dev->mode_config.mutex))
        mutex_unlock(&dev->mode_config.mutex);

I know that's not atomic. But, in case of the bug it runs into the if-clause (so, the mutex is locked) and gives a warning about an unbalanced unlock. Then it moves on and ironlake_panel_vdd_work() gets stuck when trying to lock mode_config.mutex.


I've also tested various module parameters (and combinations of), i.e. disabling rc6, powersave, fbc (as Chris mentioned) ... to see if they cause any side effects.

For testing I've noticed that I don't need an X-server to trigger it. With those additional kernel messages I've sprinkled before, inside and when leaving a lock on mode_config.mutex I can see when it runs and get stuck in ironlake_panel_vdd_work(). For this I just need to boot without the monitor and plug it in when the system is up.


Is there anything else I can provide or should test to help you with this bug?
Comment 25 Chris Wilson 2013-12-02 09:48:22 UTC
(In reply to comment #24)
> I even tried this in ironlake_panel_vdd_work() before it locks
> mode_config.mutex:
> 
>     if (mutex_is_locked(&dev->mode_config.mutex))
>         mutex_unlock(&dev->mode_config.mutex);
> 
> I know that's not atomic. But, in case of the bug it runs into the if-clause
> (so, the mutex is locked) and gives a warning about an unbalanced unlock.
> Then it moves on and ironlake_panel_vdd_work() gets stuck when trying to
> lock mode_config.mutex.

Hmm, I was expecting that the warning would be from along the path that was already holding the lock. Is that so? Can you please attach the dmesg with this hack applied?
Comment 26 Daniel Martin 2013-12-02 12:45:20 UTC
Created attachment 90101 [details]
dmesg 3.13.0-rc1 with hack from comment #24

dmesg 3.13.0-rc1 with:
- hack from comment #24
- DRM_DEBUG_KMS messages before, inside and when leaving a lock on mode_config.mutex
- DRM_DEBUG_KMS messages before schedule/cancel_delayed_work(_sync) on panel_vdd_work (That's why "XXX: schedule work (msecs_to_jiffies)..." shows up.)

I've to recall my statement in comment #24:
> I know that's not atomic. But, in case of the bug it runs into the if-clause (so, the mutex is locked) and gives a warning about an unbalanced unlock. Then it moves on and ironlake_panel_vdd_work() gets stuck when trying to lock mode_config.mutex.

With the hack applied it doesn't deadlock in ironlake_panel_vdd_work() when aquiring the lock on mode_config.mutex. Comparing the dmesg output with the preemption workaround, see attachment #89947 [details], I miss intel_dp_set_signal_levels() and friends between haswell_write_eld() and ironlake_panel_vdd_work().

Notes on dmesg:
@57.286024 I've plugged in the monitor and wait.

@263.064377 More than 120s are gone and no "task kworker/xyz blocked for more than 120 seconds" message showed up. Try to start Xorg and wait.

@480.271406 "INFO: task Xorg:152 blocked for more than 120 seconds." Yep, last message in Xorg.0.log is "xfree86: Adding drm device (/dev/dri/card0)". The nice retro pattern never showed up. ;)

@480.307359 "INFO: lockdep is turned off." Heee? I've definitly enabled lockdep, made a `make clean && make` in the kernel tree and in /proc/config.gz I can find CONFIG_LOCKDEP=y.
Comment 27 Daniel Martin 2013-12-02 12:53:04 UTC
Created attachment 90102 [details] [review]
patch used for attachment #90101 [details]

That's the patch I've used when booting and creating attachment #90101 [details].
(There're no mixed tabs&spaces *jedihandwave*.)
Comment 28 Chris Wilson 2013-12-02 13:05:22 UTC
Oh, I wonder if that is just an ownership test failing. But since it is also 3ms later, it could well have been unlocked before we did so. Any way back to the drawing board.
Comment 29 Daniel Martin 2013-12-03 12:39:34 UTC
Created attachment 90151 [details] [review]
printk to the rescue

As mentioned in earlier comments I've missed the link training messages in case of the bug, whereas they show up when it works.

So, I've followed the link training path and sprinkled more and more DRM_DEBUG_KMS along the way and finally found a place where adding such a message seem to masquerade the problem. It may not workaround the problem if I decrease the verbosity level - haven't tested.

It's the for(;;) loop in intel_dp_aux_native_write(), in case of ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER) it adds an udelay(100). Having a DRM_DEBUG_KMS before the udelay() (as done in this attachment) the loop seems to be throttled enough to masquerade the problem.

With this hack applied plugging in the monitor results in its activation - the console gets cloned to it. Even replugging works.
When plugging in the monitor for the first time the "throttle message" showed up 6k to 7k times, when replugging it there've been roughly 2k messages.

I haven't tried to simply raise the udelay().
Comment 30 Chris Wilson 2013-12-03 14:29:43 UTC
Hi Todd, can you check intel_dp_aux_native_write() against the spec, specifically how long we should wait after the auxiliary channel reports AUX_NATIVE_REPLY_DEFER?
Comment 31 Todd Previte 2013-12-03 16:16:24 UTC
Jani and I had a conversation about this not-so-very-long ago. Unfortunately, the spec is rather vague on the details of AUX_DEFERs. There's a little bit more information in there for I2C-over-AUX behavior, but nothing directly about native AUX_DEFERs as far as retry timeouts go. Essentially the spec just says "the source device can try again later" and leaves it at that. There's also an instance in the spec that says "assumes the Source repeats request immediately following a DP Sink AUX Defer response". Nothing like consistency...

That said, I would think that up to 300us would be a safe value for a retry timeout. That should be fine for isolated DEFERs or even a short series of them. However, lots of defers with a timeout value like this can stretch AUX operations out beyond specified specified time limits (10ms for link training for instance), so that's something to keep in mind.
-T
Comment 32 Daniel Martin 2013-12-04 09:58:05 UTC
(In reply to comment #31)
> Jani and I had a conversation about this not-so-very-long ago.
> Unfortunately, the spec is rather vague on the details of AUX_DEFERs.
> There's a little bit more information in there for I2C-over-AUX behavior,
> but nothing directly about native AUX_DEFERs as far as retry timeouts go.
> Essentially the spec just says "the source device can try again later" and
> leaves it at that. There's also an instance in the spec that says "assumes
> the Source repeats request immediately following a DP Sink AUX Defer
> response". Nothing like consistency...
> 
> That said, I would think that up to 300us would be a safe value for a retry
> timeout.

I've raised and tested the udelay() from 100 to 300. It doesn't work reliable, especially when replugging the dp connector. But, a value of 500 did.

> That should be fine for isolated DEFERs or even a short series of
> them. However, lots of defers with a timeout value like this can stretch AUX
> operations out beyond specified specified time limits (10ms for link
> training for instance), so that's something to keep in mind.

Just for my understanding:
- What are isolated DEFERs?
- Is such a docking station nothing more than an active DP adapter?
Comment 33 Todd Previte 2013-12-04 18:48:32 UTC
So a 500us delay in retries alleviates the problem? Interesting. That would seem to indicate that the sink device rather slow to get back to a ready state after responding to a transaction. As I indicated above, the only issue with a high retry time is ensuring that operations like link training can occur within the specified time period. 

An isolated defer would be a single AUX_DEFER received from a sink device for a request from the source. For example, if you ask to read the status bits for link training out of the DPCD and the sink replies with an AUX_DEFER because it's busy servicing another request. You could then wait (in your case, 500us), resend the same request, and receive a valid response. That would be a single, isolated defer.

As for your docking station question, you'd have to refer to the manufacturer's information or contact their support team. I'm sure there's multiple ways they could have constructed the hardware and I don't want to speculate on it without having exactly knowledge.

-T
Comment 34 Ferry Huberts 2013-12-05 16:33:05 UTC
@Daniel: much respect for how you pin-pointed this!

@Intel guys: how about getting a patch for this into the stable trees?
It seems that more and more people are experiencing this problem, including me.
The Thinkpad T440s is now volume shipment and it seems a very popular machine.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1036974
Comment 35 frederik 2013-12-05 18:19:13 UTC
Good Job guys, I want to underline Ferrys request. This bug also affects the T440p series. I guess it affects all 2013 ThinkPad Docks with Haswell graphics.
Comment 36 iivari h 2013-12-06 11:46:10 UTC
Same thing happens with Dell latitude e5540.
Comment 37 Todd Previte 2013-12-06 17:54:32 UTC
There may be more to this issue. From the logs, it looks like the dock is an actual sink / active adapter, supporting 1.2 compliance, HBR2, etc. The monitor, when plugged into this port, is listed as a downstream branch device. The DPCD for the sink device in the dock is this:
     [   26.257557] [drm:intel_dp_get_dpcd], DPCD: 12 14 c4 01 00 15 01 83 02 00 00 00 00 00 04
And the DPCD from the monitor is this:
     [   26.397960] [drm:intel_dp_get_dpcd], DPCD: 11 0a 84 01 01 00 00 00 00 00 00 00 00 00 00

Clearly two different devices. The sink in the middle and the monitor being the branch device may explain why increasing the timeout value appears to alleviate this issue. I'm going to go look into how we handle branch devices and see what I can find in there. In the meantime, to implement the 500us workaround in a patch,  I'll see if I can key off the DPCD value and only use 500us when a downstream port is present. That should prevent any issues when working with normal (non-branch) devices. 

-T
Comment 38 iivari h 2013-12-06 18:02:59 UTC
it seems this is not only docking issue, because i got this problem also when connecting vga monitor to my laptop (latitude e5540) without the dock.
Comment 39 Todd Previte 2013-12-06 19:04:31 UTC
So you're saying you see this same problem with a VGA connection, with your laptop undocked and no other displays connected to it?
Comment 40 iivari h 2013-12-06 19:09:28 UTC
That's right.
Comment 41 Stefan 2013-12-06 20:45:39 UTC
I just tried the 500us fix by compiling the Linux Mint generic kernel with the udelay value changed to 500. This didn't fix the problem for me. Putting my notebook into the docking station while already running still freezes the display. After undocking everything works again.

Connecting an monitor through VGA directly works for me.

Is there any way I can help to fix this problem?
Comment 42 Jonas Jakobsen 2013-12-08 13:56:14 UTC
I also got this problem, I've tried two Thinkpad Pro Docks, and they both have the same problem. Tried to reinstall Windows on my T440s, where the docking stations worked fine.

I'm now running Ubuntu 13.10 with 3.11.0-14-generic, and I'm in dire need of a fix to this problem - so please do! :)
Comment 43 Thomas Fogh Damgaard 2013-12-11 08:39:32 UTC
I've a Lenovo T440s with Fedora 19 (3.11.10) and my laptop screen goes black if I put it in the dock and nothing else happens. If I pull it out again the screen restores. If I boot up in the dock the screen just stays dark after GRUB.
I tried compiling a new kernel with the 500us fix. Now when I put the laptop in the dock nothing happens.
Comment 44 Philip Könighofer 2013-12-12 13:03:02 UTC
Just tested with udelay -> 500 on Ubuntu 13.10. Linux 3.13-rc3. Seems to work with one external display. If I connect the 2nd DP port on the dock, the display gets mirrored from the other DP. Strangely only DP2 is marked as connected in xrandr.

I can provide you with remote-access to my docked t440s test-setup, if that's helpful.
Comment 45 Philip Könighofer 2013-12-12 13:18:18 UTC
xrandr shows me the following
eDP1 connected primary 1920x1080+0+0
DP2 connected 1680x1050+1920+0

is it expected that both of my dock's DisplayPorts are combined to DP2?
Comment 46 Stefan 2013-12-16 05:36:48 UTC
Can anyone provide me with a patch file and exact kernel version for which the udelay with 500 seems to fix the problem (at least partly)? Would be a great help.
Comment 47 Andreas Mohrhard 2013-12-16 20:00:29 UTC
Tested this today with a brand new demo T440p with an ultra dock and two Dell 2412m. Freezes as soon as it is docked. Works with mDP on laptop to DP at the display. If it helps we could provide remote access to one of our systems as well (another 9 are ordered, we have our fingers crossed that this will be fixed ;)).
Comment 48 Philip Könighofer 2013-12-18 08:30:35 UTC
Any news yet? 
Can anyone give a short status update please. 

If you are busy, I am willing to look into this myself. Since I am not familiar with the code, this would definitely take some time.

Thank you.
Comment 49 Oliver Charles 2013-12-19 15:18:11 UTC
I have a ThinkPad T440p with an Ultra dock and I can also confirm this behaviour. However, I have managed to successfully get the screen to work occasionally, but I can't quite determine the steps to get it to successfully configure. Like others, `xrandr` causes the laptop to freeze and undocking it resolves it.
Comment 50 Georg Pichler 2013-12-21 17:23:13 UTC
I also ran into this with a Thinkpad T440 and an Ultra Dock.

I tried the patch in Comment 11 as well as changing the udelay(100) to udelay(500), that Comment 29 mentioned. Didn't change anything: As soon as I plug a monitor via VGA or DVI in the dock, the screen freezes and returns to normal on undocking.

I would be happy to supply further information, if you tell me what you need.
Comment 51 nkalkhof 2013-12-21 21:28:40 UTC
Same problem here with a T440p and a Ultra Dock. Increasing the sleep time to 500us works however the system hogs the CPU about 30 seconds with a black screen before switching to the external screen when docked.
Comment 52 Stefan 2013-12-23 21:34:27 UTC
Is it enough for you to change the sleep-time to 500us or do you additionally add some debug output (like the patch above)?
Comment 53 Georg Pichler 2013-12-23 21:37:14 UTC
(In reply to comment #50)
> I also ran into this with a Thinkpad T440 and an Ultra Dock.
> 
> I tried the patch in Comment 11 as well as changing the udelay(100) to
> udelay(500), that Comment 29 mentioned. Didn't change anything: As soon as I
> plug a monitor via VGA or DVI in the dock, the screen freezes and returns to
> normal on undocking.
> 
> I would be happy to supply further information, if you tell me what you need.

My bad. I tried it today with the DiplayPort connectors: Works like a charm with the patched kernel. But, the DVI and VGA ports on the dock don't work.
Comment 54 Stefan 2013-12-23 21:53:59 UTC
(In reply to comment #53)
> (In reply to comment #50)
> > I also ran into this with a Thinkpad T440 and an Ultra Dock.
> > 
> > I tried the patch in Comment 11 as well as changing the udelay(100) to
> > udelay(500), that Comment 29 mentioned. Didn't change anything: As soon as I
> > plug a monitor via VGA or DVI in the dock, the screen freezes and returns to
> > normal on undocking.
> > 
> > I would be happy to supply further information, if you tell me what you need.
> 
> My bad. I tried it today with the DiplayPort connectors: Works like a charm
> with the patched kernel. But, the DVI and VGA ports on the dock don't work.

Does the HDMI port work for you?
Comment 55 Georg Pichler 2013-12-23 22:02:14 UTC
Created attachment 91164 [details] [review]
patch against 3.13-rc4; DP on Ultra Dock works
Comment 56 Georg Pichler 2013-12-23 22:04:27 UTC
(In reply to comment #54)
> (In reply to comment #53)
> > (In reply to comment #50)
> > > I also ran into this with a Thinkpad T440 and an Ultra Dock.
> > > 
> > > I tried the patch in Comment 11 as well as changing the udelay(100) to
> > > udelay(500), that Comment 29 mentioned. Didn't change anything: As soon as I
> > > plug a monitor via VGA or DVI in the dock, the screen freezes and returns to
> > > normal on undocking.
> > > 
> > > I would be happy to supply further information, if you tell me what you need.
> > 
> > My bad. I tried it today with the DiplayPort connectors: Works like a charm
> > with the patched kernel. But, the DVI and VGA ports on the dock don't work.
> 
> Does the HDMI port work for you?

I don't know. Sadly i didn't have a device to try it out. I will try, when I get back to work after the holidays.
And just for reference, i used Attachment #91164 [details] against the 3.13-rc4 vanilla kernel.
Comment 57 Stefan 2013-12-23 22:22:41 UTC
(In reply to comment #56)
> (In reply to comment #54)
> > (In reply to comment #53)
> > > (In reply to comment #50)
> > > > I also ran into this with a Thinkpad T440 and an Ultra Dock.
> > > > 
> > > > I tried the patch in Comment 11 as well as changing the udelay(100) to
> > > > udelay(500), that Comment 29 mentioned. Didn't change anything: As soon as I
> > > > plug a monitor via VGA or DVI in the dock, the screen freezes and returns to
> > > > normal on undocking.
> > > > 
> > > > I would be happy to supply further information, if you tell me what you need.
> > > 
> > > My bad. I tried it today with the DiplayPort connectors: Works like a charm
> > > with the patched kernel. But, the DVI and VGA ports on the dock don't work.
> > 
> > Does the HDMI port work for you?
> 
> I don't know. Sadly i didn't have a device to try it out. I will try, when I
> get back to work after the holidays.
> And just for reference, i used Attachment #91164 [details] against the
> 3.13-rc4 vanilla kernel.

(In reply to comment #56)
> (In reply to comment #54)
> > (In reply to comment #53)
> > > (In reply to comment #50)
> > > > I also ran into this with a Thinkpad T440 and an Ultra Dock.
> > > > 
> > > > I tried the patch in Comment 11 as well as changing the udelay(100) to
> > > > udelay(500), that Comment 29 mentioned. Didn't change anything: As soon as I
> > > > plug a monitor via VGA or DVI in the dock, the screen freezes and returns to
> > > > normal on undocking.
> > > > 
> > > > I would be happy to supply further information, if you tell me what you need.
> > > 
> > > My bad. I tried it today with the DiplayPort connectors: Works like a charm
> > > with the patched kernel. But, the DVI and VGA ports on the dock don't work.
> > 
> > Does the HDMI port work for you?
> 
> I don't know. Sadly i didn't have a device to try it out. I will try, when I
> get back to work after the holidays.
> And just for reference, i used Attachment #91164 [details] against the
> 3.13-rc4 vanilla kernel.


Ok thx, I didn't have the part below @@ -1164,6 +1164,15 @@ in my kernel, so I'll recompile with it and try again. Just changing to 500us i just know found out that when only connecting HDMI it doesn't hang for some seconds and then hangs as always.

Besides that I only tested with VGA which hangs instantly for me.

Any ideas why DP works but VGA/DVI don't? (I have no DP-device here to verify if it works for me.)
Comment 58 Tako Marks 2014-01-03 12:44:16 UTC
Any updates on the testing of all the ports? I'm quite new to all this so I'm having trouble compiling it myself to test.
Comment 59 nkalkhof 2014-01-03 17:41:56 UTC
The patch doesn't work with a t440 on its docking station. Still 20-50 seconds between eDP<->DP switches in which the cpu seems to burn (fan goes up). Sometimes the external screen comes on shortly but then get black again leaving the system non responsive. One good thing the patch does is to lower the power consumption when the system is idle (no matter if attach to dock od running stand alone) from 18 watts to 10 watts. So I guess there is much more going on here that needs to be fixed.
Comment 60 nkalkhof 2014-01-06 18:06:47 UTC
latest ~danvet/drm-intel/drm-intel-nightly pachtes broke DP switching completely! System freezes all the time when connected to Dock!
Comment 61 Chris Wilson 2014-01-06 20:03:36 UTC
(In reply to comment #60)
> latest ~danvet/drm-intel/drm-intel-nightly pachtes broke DP switching
> completely! System freezes all the time when connected to Dock!

nkalkhof, can you please file a new bug report so that we can prioritise this regression? (I am assuming that is not related to the rest of this bug report...)
Comment 62 Frederic Mohr 2014-01-08 11:08:57 UTC
Is the patch already included in 3.13-rc7 from kernel.org? 

Because I just installed it and it fixed the overall freeze, plus the USB ports are working now. However if I connect DVI, HDMI, VGA or one of the DPorts to a monitor the system freezes again.

This happens only if the monitor is set to the right port as well, plugging in dport and having monitor set to e.g. vga doesn't do anything.

I am using a brand new Thinkpad X240 with Dock and Kubuntu 13.10. Stock kernel (3.11.0-15-generic) had the same problems + USB wasn't working.) 

Everything works if I plug it in directly without the x240 being docked.
Comment 63 frederik 2014-01-08 17:23:37 UTC
Whether 3.13rc7 nor 3.13rc7 with https://bugs.freedesktop.org/attachment.cgi?id=91164 works for me.
Any ideas?
Comment 64 frederik 2014-01-08 18:22:50 UTC
Sorry, anything went wrong as I compiled rc7. 3.13rc7 is working fine, but does not recognize two external attached DP Monitors. Its only shown as one in system control. Monitors are mirrored at this time. 

Works fine when attaching one monitor to non-docking port.

May I provide any debug information?
Comment 65 Marco Berzborn 2014-01-08 18:36:09 UTC
(In reply to comment #64)
> Sorry, anything went wrong as I compiled rc7. 3.13rc7 is working fine, but
> does not recognize two external attached DP Monitors. Its only shown as one
> in system control. Monitors are mirrored at this time. 
> 
> Works fine when attaching one monitor to non-docking port.
> 
> May I provide any debug information?

Are you using a patched kernel or have been using the original kernel from kernel.org?
I compiled 3.13-rc7 with patch https://bugs.freedesktop.org/attachment.cgi?id=91164 a few days ago and I'm still running into desktop freezes everytime I connect a display to any port of the docking station (DP, HDMI, DVI and VGA). 
Would be nice if you share what went wrong in your case and how you fixed it.
Thanks!
Comment 66 frederik 2014-01-08 18:54:40 UTC
I used Archlinux AUR linux-mainline package without any additional patches. The first time I wrote, that it does not work, there has been a compilation error, that I did not see.
Comment 67 nkalkhof 2014-01-08 20:58:12 UTC
(In reply to comment #61)
> (In reply to comment #60)
> > latest ~danvet/drm-intel/drm-intel-nightly pachtes broke DP switching
> > completely! System freezes all the time when connected to Dock!
> 
> nkalkhof, can you please file a new bug report so that we can prioritise
> this regression? (I am assuming that is not related to the rest of this bug
> report...)

chris, disregard my report about total freezes. my kernel .config was messed up during git pull somehow. the above provided patch works with rc7 also but it still takes 20-50 seconds between dp switches when connected to the docking station.
Comment 68 frederik 2014-01-09 13:44:27 UTC
Still sometimes got freezes when DP is attached after power on. Attaching before/after poweron/poweroff works fine (except the mirroring issue).
Comment 69 Marco Berzborn 2014-01-09 21:40:56 UTC
(In reply to comment #66)
> I used Archlinux AUR linux-mainline package without any additional patches.
> The first time I wrote, that it does not work, there has been a compilation
> error, that I did not see.

Thanks! I also had some compilation error.
Ubuntu 13.10 with kernel 3.13-rc7 from kernel.org and patch https://bugs.freedesktop.org/attachment.cgi?id=91164
works. Again, it takes some time for the DP switch as already mentioned.
However, booting when connected to the docking station does not seem to work properly in my case. I have to boot up the laptop and dock it afterwards.
Comment 70 hicolour 2014-01-10 22:51:47 UTC
Any chance for official fix ?
Comment 71 Stefan Agner 2014-01-10 23:09:20 UTC
I tried the patch agains 3.13-rc4 which should fix DP. However, on my device I can't boot Linux at all using this patch (undocked!). I patched a mainline 3.13-rc7 on my Arch Linux. Without the patch, it boots fine, but with the patch the kernel boot freezes just before the switch to the Intel FB. 

Note: Before I even run the patched kernel the first time, I upgraded to latest BIOS (2.17) and also made the Firmware upgrade of the internal DP to VGA converter (see http://support.lenovo.com/en_US/downloads/detail.page?DocID=DS038203). Especially the second one in combination with the patch might trigger my freeze...

Do you did this firmware upgrade?
Comment 72 Daniel Martin 2014-01-15 09:27:44 UTC
Todd, did you had some time investigating the problem?

Meanwhile, Thierry Reding posted a drm/dp series "infrastructure to support AUX channels in a generic way". Will they serve as a base to address this issue in a more generic way?
Comment 73 hicolour 2014-01-16 20:12:23 UTC
last packages upgrade on archlinux  + small workaround  works for me

when os starts freezing I'm turning off /on external screen and then os backs to normal state plus external screen works without any problems


display port ==> mini diplay port

Linux lena 3.12.7-2-ARCH #1 SMP PREEMPT
Comment 74 frederik 2014-01-17 17:55:16 UTC
Which intel graphics driver version has the working arch version?
Comment 75 hicolour 2014-01-17 21:32:37 UTC
~ $ pacman -Qe | grep intel
xf86-video-intel 2.99.907-1
Comment 76 hicolour 2014-01-18 15:02:38 UTC
next intel driver update broke it once again, turn off/on trick doesn't work 


marek at lena lena ~ $ pacman -Qe | grep intel
xf86-video-intel 2.99.907-2
Comment 77 jacek s 2014-01-18 19:56:34 UTC
Hello, 
I have the same problem, maybe I can contribute with some more data to solve this.

If I can provide any more data, let me know how and I will.

OS: Ubuntu 10.13 (GNOME) + apt-get upgrade

Hardware: 
Lenovo docking station Thinkpad Ultradock
Lenovo x240 (only VGA and mini DP output)

Behaviour regarding screens/docking stations:

1) 
Docking station connected to AC adapter.
Docking station connected via HDMI<->HDMI to an LCD screen. 
OS loaded(booted) , user logged in. 
Result:
When I dock the laptop screen freezes, nothing moves, I dont see anything I type.
When I undock the laptop everything unfreezes and I see everything I've typed when it was frozen. I can repeat it all the time. 

2)
Docking station connected to AC adapter.
Docking station connected via DiplayPort<->DVI to an LCD screen.
OS loaded(booted) , user logged in
Result:
Same as above

3)
Docking station connected to AC adapter.
Docking station connected via DiplayPort<->DVI to an LCD screen.
I dock the laptop when its off and then start it. 
Result:
Initial sequence visible, then screen goes blank (backlight on).
When I undock it I see user login screen.Operational. 

4)
Docking station connected to AC adapter.
Docking station connected via HDMI<->DVI to an LCD screen.
I dock the laptop when its off and then start it.
Result: 
Same as above

5)
Docking station NOT connected to AC adapter.
Docking station connected via HDMI<->HDMI to an LCD screen. 
Result:
When I dock the laptop it do not freezes, remains operational but nothing happens with the screen. 

6)Docking station NOT connected to AC adapter.
Docking station connected via DVI<->HDMI to an LCD screen. 
Result:
Same as above.

7) Connecting laptop directly thru miniDP or VGA was not tested yet.


Best Regards
Jacek
Comment 78 hicolour 2014-01-18 20:12:02 UTC
I forgotten to mention

before xf86-video-intel 2.99.907-1 calling xrandr wihout params when the computer is docked freezes OS

now xrandr wihout params doesn't freezes OS
Comment 79 Stefan Agner 2014-01-20 22:01:45 UTC
I tried today vanilla 3.13 on my T440s. Still the same issue. I then inserted the udelay (at the same position stated in the patch) as well as uncommented locks in ironlake_panel_vdd_work (I had boot hangs with the full patch of Georg Pichler applied).

I only have a HDMI device, which is connected to the dock. I booted undocked and docked then. At first, several messages (including the mode information) appeared, however I had no freeze. Then, when I enable the output (using xrandr --output DP2 --auto), the system freezes for several minutes but after a while, I have output on HDMI! My log (dmesg_3.13_docking_hdmi_with_udelay) looks a bit different then others do, especially this every reoccurring intel_dp_set_signal_levels.
Comment 80 Stefan Agner 2014-01-20 22:02:46 UTC
Created attachment 92490 [details]
dmesg_3.13_docking_hdmi_with_udelay
Comment 81 hicolour 2014-01-25 14:11:32 UTC
[2014-01-25 15:01] [PACMAN] upgraded lib32-dbus (1.6.18-1 -> 1.8.0-1)

fix the issue on my side
Comment 82 hicolour 2014-01-25 14:16:09 UTC
too optimistic .. still I need to use on
Comment 83 hicolour 2014-01-25 14:16:43 UTC
too optimistic .. still I need to use on/trick
Comment 84 frederik 2014-01-25 14:56:28 UTC
new dbus/libdbus does not work for me
Comment 85 Jake 2014-01-26 01:33:43 UTC
I care about getting this fixed, so I'm offering USD 100.00 via FreedomSponsors to the first person who fix it.

Offer link: http://www.freedomsponsors.org/core/issue/433/sna-haswell-x-server-freezes-when-enabling-dp-at-docking-station

You can also join me and throw in a few bucks there and we'll get it fixed faster :)
					
If you fix this issue (see my acceptance criteria there) please use that site to request your payment.
Comment 86 Eric Floehr 2014-01-26 02:01:36 UTC
I matched Jake's bounty, so the bounty is now at $200 to get this fixed right.

I have a Haswell laptop with Ultra Dock used for work and I can't use it in the dock with an external monitor. It is affecting my productivity. Thanks for your work on open source!

I am willing to test solutions.
Comment 87 David Runge 2014-01-26 11:34:14 UTC
Same freeze on a W540 with:

Name           : linux
Version        : 3.12.8-1

Name           : xf86-video-intel
Version        : 2.99.907-2

A fix for this would indeed be very nice. A lot of people seem to be affected.

Newest dbus doesn't change anything for me either.
Comment 88 afran 2014-01-26 11:53:06 UTC
The problem not only affects X output (and the described xrandr symptoms), but also happens when booting with framebuffer support: on my Thinkpad T440p, boot halts entirely as soon the framebuffer switches to the higher resolution. Boot only resumes when I lift the laptop momentarily from the docking station (with DisplayPort monitor connected to it). Boot halts next when the console font is switched; same process: it can only be resumed when I lift the laptop from the docking station.

I can easily reproduce this behavior with the latest (2013.09) Grml live linux system (http://grml.org/download/).

Please let me know what further information I can provide to help solve this.
Comment 89 Merlijn 2014-01-27 10:57:14 UTC
I have a Thinkpad T440s and this issue makes my Ultra Dock almost useless. I am experiencing the same problems as described by others here.

http://www.freedomsponsors.org/core/issue/433/sna-haswell-x-server-freezes-when-enabling-dp-at-docking-station

I added another $100 to this bounty a total of $300 now) to get this resolved. If someone can fix this in a day or two of work it should be worth the effort I'm hoping.
Comment 90 Stefan Agner 2014-01-27 20:32:10 UTC
I'm not an expert in this field, but as far as I can interpret the debug output, its only related to the kernel. It seems to be related to link training, whatever that exactly means. My main setup is using an HDMI monitor, so I started with that. I added more and more debug output and ended with what I have in link-train-debug.patch. 

With that patch HDMI takes about 30 seconds and then I see output. But sometimes, it doesn't work at all (see with-link-train-debug-hdmi-3.13.0-ARCH-local-dirty.txt).

However, when I attached a DP monitor at it, switching worked almost instantly (see with-link-train-debug-dp-3.13.0-ARCH-local-dirty.txt).

I then traced down the "offending" debug print, and replaced it with a delay (see link-train-delay.patch). It seems to work on my setup. I tested docked and docking while on, in both cases I get display output almost immediately... 

While I don't understand that stuff really, it seems to be a problem of reading the link status, at least with that delay, reading it seems to heal the problem, at least for DP...
Comment 91 Stefan Agner 2014-01-27 20:33:18 UTC
Created attachment 92880 [details]
Enable debug prints in link train path
Comment 92 Stefan Agner 2014-01-27 20:34:23 UTC
Created attachment 92881 [details]
Docking to a dock with an HDMI connection
Comment 93 Stefan Agner 2014-01-27 20:34:49 UTC
Created attachment 92882 [details]
Docking to a dock with an DP connection
Comment 94 Stefan Agner 2014-01-27 20:37:05 UTC
Created attachment 92883 [details] [review]
link-train-delay.patch

This solves the issue on a custom compiled 3.13 kernel for me (make localyesconfig) using DP port 1.
Comment 95 Jan Hieber 2014-01-28 10:14:14 UTC
Thanks a lot Stefan, I testet your patch on Archlinux 3.13.0-1-mainline (localyesconfig):

When i connect HDMI and one of the two DPs at the dock i can only get one of the three connectors working at same time. The HDMI and 2 DPs at the dock are always mapped to DP2 (arandr).

VGA and DVI did not work.
Now i have a DP screen at the dock and a HDMI screen with Delock mDP->HDMI adapter directly connected and it works.

So the DVI/VGA on dock and the ability to use more than one of the DP/HDMI connectors on the dock are now the remaining big problem.

If i can help out with logs etc, please let me know.
Comment 96 Georg Pichler 2014-01-28 10:40:09 UTC
(In reply to comment #94)

Hi Stefan. Thanks for taking a look at this. I just tried your patch link-train-delay.patch against the 3.13 kernel from kernel.org on Linux Mint 16 (fully patched). My experience with a T440 and an UltraDock:

1) Booting the PC in Dock (no Monitors attached) and then

1a) attaching a DVI monitor to DP1 (DVI-DP adapter):
Comment 97 Jan Hieber 2014-01-28 10:46:12 UTC
OK, after a little testing there are still big problems with this. DPMS turned off my screens and then i could not get the DP-Screen on the dock working again.

Now i use my old configuration, mDP->HDMI Adapter and VGA Screen. I noticed the VGA Screen shows as DP2 (T440s has internal DP-VGA converter).

So it lookls like the two DPs on the dock are mapped to DP2 and the HDMI on dock is mapped to DP2 and the VGA is mapped to DP2...
Comment 98 Georg Pichler 2014-01-28 10:49:03 UTC
(In reply to comment #94)
Sorry, I misclicked. Again:

Hi Stefan. Thanks for taking a look at this. I just tried your patch link-train-delay.patch against the 3.13 kernel from kernel.org on Linux Mint 16 (fully patched). My experience with a T440 and an UltraDock:
(just quick tests, if you want details, please ask)

1) Booting the PC in dock (no monitors attached) and then

1a) attaching a DVI monitor to DP1 (DVI-DP adapter):
    - Freezes for ~1min then the monitor works
1b) same as 1a) but with DVI directly connected:
    - Same result as 1a)
1c) connecting both the DVI as well as the DP (DVI-DP adapter):
    - Freeze ~1min and then the monitors come up, but, as mentioned in Comment 95, they are mirrored and appear both as DP2 in xrandr
1d) connecting VGA:
    - Seems not to work for me. Maybe I didn't wait long enough.

2) Booting with monitors attached to the dock:
   - Depending on which configuration I attach, it boots with the ~1min delay or it drops me to a busybox shell because of a timeout

If you want I can provide some additional logs if necessary.

So, all in all, the patch did not solve my problem. The annoying 1min delay still exists. :(
Comment 99 Daniel Martin 2014-02-04 12:28:49 UTC
At FOSDEM Jesse Barnes gave a talk "Intel BayTrail graphics overview", on one slide he mentioned an "external DP" bug they've fixed. I guess he meant (was to dumb to ask):
    drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup
    http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=2cac613

I've wondered if it's related to this bug. So, I've tested the current drm-intel-fixes branch (including this commit). But, the problem - this bug - still exists.
Comment 100 Arnd Hannemann 2014-02-04 16:30:08 UTC
I'm using T440s with a Thinkpad Ultra Dock and I'm also suffering from this bug.

I tried up to 3.14-rc1 plus "drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup" and still experiencing the problem.

A magic sysrq "Show Blocked State" shows the following blocked states:


[   94.401240] SysRq : Show Blocked State
[   94.401253]   task                        PC stack   pid father
[   94.401264] kworker/1:1     D ffff88031e252f80     0    35      2 0x00000000
[   94.401350] Workqueue: events ironlake_panel_vdd_work [i915]
[   94.401356]  ffff88030ffffd80 0000000000000046 ffff88030fc3c800 ffff88030fffffd8
[   94.401365]  0000000000012f80 0000000000012f80 ffff88030fc3c800 ffff880310272228
[   94.401373]  ffff88031027222c ffff88030fc3c800 00000000ffffffff ffff880310272230
[   94.401381] Call Trace:
[   94.401399]  [<ffffffff8164b9a9>] schedule_preempt_disabled+0x29/0x70
[   94.401408]  [<ffffffff8164d493>] __mutex_lock_slowpath+0x133/0x1b0
[   94.401416]  [<ffffffff8164d52f>] mutex_lock+0x1f/0x2f
[   94.401477]  [<ffffffffa0126f95>] ironlake_panel_vdd_work+0x25/0x40 [i915]
[   94.401487]  [<ffffffff810617e7>] process_one_work+0x177/0x420
[   94.401494]  [<ffffffff81062421>] worker_thread+0x121/0x3a0
[   94.401502]  [<ffffffff81062300>] ? manage_workers.isra.25+0x2b0/0x2b0
[   94.401511]  [<ffffffff810684f2>] kthread+0xd2/0xf0
[   94.401521]  [<ffffffff81068420>] ? kthread_create_on_node+0x180/0x180
[   94.401529]  [<ffffffff81656f6c>] ret_from_fork+0x7c/0xb0
[   94.401538]  [<ffffffff81068420>] ? kthread_create_on_node+0x180/0x180
[   94.401591] Xorg            D ffff88031e212f80     0  1569   1504 0x00400004
[   94.401600]  ffff8803027538c0 0000000000000086 ffff880300831800 ffff880302753fd8
[   94.401608]  0000000000012f80 0000000000012f80 ffff880300831800 ffffffff81e49c00
[   94.401616]  ffff8803027538f0 00000000ffff3747 ffffffff81e49c00 000000000000d0b8
[   94.401624] Call Trace:
[   94.401635]  [<ffffffff8164b539>] schedule+0x29/0x70
[   94.401644]  [<ffffffff8164a782>] schedule_timeout+0x162/0x2a0
[   94.401657]  [<ffffffff81051f00>] ? ftrace_raw_output_tick_stop+0x70/0x70
[   94.401715]  [<ffffffffa01279e8>] intel_dp_aux_ch+0x3b8/0x570 [i915]
[   94.401725]  [<ffffffff81087a30>] ? prepare_to_wait_event+0x100/0x100
[   94.401776]  [<ffffffffa0127c3a>] intel_dp_aux_native_write+0x9a/0xf0 [i915]
[   94.401825]  [<ffffffffa0128406>] ? intel_edp_psr_do_enable+0x186/0x2f0 [i915]
[   94.401875]  [<ffffffffa012a19f>] intel_dp_start_link_train+0x6f/0x2b0 [i915]
[   94.401926]  [<ffffffffa0123589>] intel_ddi_pre_enable+0x89/0xe0 [i915]
[   94.401974]  [<ffffffffa0113ee4>] haswell_crtc_enable+0xb4/0x620 [i915]
[   94.401983]  [<ffffffff81334949>] ? snprintf+0x39/0x40
[   94.402029]  [<ffffffffa011552f>] __intel_set_mode+0x85f/0x15c0 [i915]
[   94.402037]  [<ffffffff81334685>] ? vsnprintf+0x415/0x610
[   94.402085]  [<ffffffffa01186c6>] intel_set_mode+0x16/0x30 [i915]
[   94.402130]  [<ffffffffa0118f8b>] intel_crtc_set_config+0x7bb/0x990 [i915]
[   94.402175]  [<ffffffffa003f6ed>] drm_mode_set_config_internal+0x5d/0xe0 [drm]
[   94.402216]  [<ffffffffa0042547>] drm_mode_setcrtc+0xf7/0x5e0 [drm]
[   94.402247]  [<ffffffffa0033aa2>] drm_ioctl+0x4d2/0x600 [drm]
[   94.402263]  [<ffffffff811be15b>] ? inotify_handle_event+0xfb/0x150
[   94.402280]  [<ffffffff8118e8c8>] do_vfs_ioctl+0x2d8/0x4b0
[   94.402290]  [<ffffffff8117e511>] ? __sb_end_write+0x31/0x60
[   94.402298]  [<ffffffff8117c162>] ? vfs_write+0x172/0x1e0
[   94.402308]  [<ffffffff811989ef>] ? __fget_light+0x2f/0x70
[   94.402317]  [<ffffffff8118eb21>] SyS_ioctl+0x81/0xa0
[   94.402325]  [<ffffffff81657012>] system_call_fastpath+0x16/0x1b
[   94.402373] Sched Debug Version: v0.11, 3.14.0-rc1aha+ #2
Comment 101 Todd Previte 2014-02-04 16:37:19 UTC
The Baytrail patches aren't going to help this issue. I need to spend some time reviewing the information here and see what I can do. 

-T
Comment 102 Sree Harsha Totakura 2014-02-08 12:25:49 UTC
Created attachment 93653 [details] [review]
[PATCH]HDMI connection via dock works with some (random) delay
Comment 103 Sree Harsha Totakura 2014-02-08 12:41:40 UTC
Created attachment 93654 [details]
Photograph showing green pattern overlays

Output on an external display connected with HDMI to dock when patch 92883 is applied.  This also appeared once with patch 91164.  But wasn't noticed until now with patch 93653.
Comment 104 Jake 2014-02-08 12:56:29 UTC
fwiw the bounty for fixing this issue is now at $550. Please consider donating if this issue affects your ability to work.
Comment 105 Sree Harsha Totakura 2014-02-08 13:02:26 UTC
I tried Agner's train delay patch (https://bugs.freedesktop.org/attachment.cgi?id=92883) with the recent linux-3.13.2 and had partial success with a HDMI connection.  My rig includes T440s with a ThinkPad Ultra Dock.  As noted by others, the display is not instantly turned on; it takes about ~30 seconds to light up.  I say partial success because the display now has patterns with green dots all over.  See the attached picture I took with my camera (https://bugs.freedesktop.org/attachment.cgi?id=93654).  I green overlay is also present with Pichler's patch (https://bugs.freedesktop.org/attachment.cgi?id=91164), but I only observed it once.

I observed the following in dmesg:
root@iris:/home/totakura# dmesg | grep drm
[   17.327337] [drm] Initialized drm 1.1.0 20060810
[   17.566302] [drm] Memory usable by graphics device = 2048M
[   17.607126] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   17.607128] [drm] Driver supports precise vblank timestamp query.
[   17.746991] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
[   17.764706] fbcon: inteldrmfb (fb0) is primary device
[   18.782531] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[   19.354891] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[   19.363836] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[  466.978775] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
[ 1216.132474] [drm] stuck on render ring
[ 1216.132490] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[ 1216.132493] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 1216.132495] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[ 1216.132497] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 1216.132500] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.

I could not get the GPU crash dump which is show in the dmesg as I rebooted immediately.  Sorry :(

Next, I combined Agner's (92882) and Pichler's(91164) patches into one (https://bugs.freedesktop.org/attachment.cgi?id=93653).  With this patch, I was able to boot up while docked.  The transition from GRUB to FB took a while but after that the external display is identical to that on the notebook display.  Consequently, I was able to suspend/shutdown while docked.  While waking up from suspend there is also a delay during which the system freezes, but its short.  With this patch I do not see the DRM warning in dmesg anymore.  This is the output now:

totakura@iris:~$ dmesg | grep drm
[   19.758646] [drm] Initialized drm 1.1.0 20060810
[   20.152088] [drm] Memory usable by graphics device = 2048M
[   20.192418] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   20.192419] [drm] Driver supports precise vblank timestamp query.
[   20.320274] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
[   20.426013] fbcon: inteldrmfb (fb0) is primary device
[   21.811554] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[   43.744150] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[   43.768082] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

With the external display working over HDMI, I went on to connect another display to the VGA port on the dock.  This display simply replicated the HDMI display.  This should not be the case here as from the dock's manual, I should be able to drive three displays, of which one should be connected to the VGA port.

I also observed that even though I connected to the HDMI port, the xrandr output still lists the external display under DP2 while showing HDMI2 as disconnected.  I do not know if this is a bug or not.  Here is the output:
totakura@iris:~$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 32767 x 32767
eDP1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 309mm x 175mm
   1920x1080      60.0*+   59.9  
   1680x1050      60.0     59.9  
   1600x1024      60.2  
   1400x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x960       60.0  
   1360x768       59.8     60.0  
   1152x864       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   1920x1080      60.0*+   50.0     59.9  
   1920x1080i     60.1     50.0     60.0  
   1680x1050      60.0  
   1280x1024      75.0     60.0  
   1440x900       59.9  
   1280x960       60.0  
   1280x800       59.8  
   1152x864       75.0  
   1280x720       60.0     50.0     59.9  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   720x576        50.0  
   720x480        60.0     59.9  
   640x480        75.0     72.8     66.7     60.0     59.9  
   720x400        70.1  
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

With the other display connected to VGA, it is not listed by xrandr.

Apart from these, sound via HDMI is working.  Note that the sound output from the dock via 3.5mm pin is disable when HDMI is in use.
Comment 106 Oliver Charles 2014-02-08 13:51:46 UTC
I've sponsored $50 towards getting this fixed. My requirements are a working DVI connection with a ThinkPad T440s and a ThinkPad Ultra Dock.
Comment 107 Jan Henning 2014-02-10 14:06:29 UTC
I have exactly the same issue on Ubuntu 14.04 with an T440s which makes its display connection via the docking stations Display Port.

After I patched the Kernel with Stefan Agners link-train-delay.patch and now it works reasonably well, the time it takes to make the display connection for me is about 10 seconds at max, which is acceptable for me.

However, I don't think this solution is perfect, so I added a few dollars to the bounty and hope some working patch makes it upstream.
Comment 108 Sree Harsha Totakura 2014-02-10 14:20:19 UTC
This post http://forums.lenovo.com/t5/T400-T500-and-newer-T-series/T540p-T440p-UltraDock-external-display-issues/m-p/1428373/highlight/true#M92038 suggests that there is a problem with the Thinkpad dock's firmware.
Comment 109 Jani Nikula 2014-02-10 15:27:19 UTC
Created attachment 93781 [details] [review]
drm/i915/dp: add max retries in native aux

Please try this for debug info.
Comment 110 Theodore Ts'o 2014-02-10 18:03:27 UTC
I tried applying the patch ([PATCH]HDMI connection via dock works with some (random) delay: https://bugs.freedesktop.org/attachment.cgi?id=93653) against a 3.13 kernel, and it makes things **worse** on my T540p.   With the 3.13 kernel w/o the patch, I can boot and start up the X server w/o problems, as long as it is not docked.  With this patch, the system locks up very early in the boot process, as soon as the console switches from the compat VGA mode into the higher resolution console mode).

Also, when comparing an unpatched 3.12 kernel with an unpatched 3.13 kernel, 3.13 is also worse with the T540p.  With the unpatched 3.12 kernel, I can have the laptop in the dock, and so long as there are no external monditors hooked up via the dock video connectors, it worked fine.   With the unpatched 3.13 kernel, it's fine outside of the dock, but if it is in the dock, even if the dock does not have any external video monitors hooked up, any time there is any change to the video setup (i.e., X server starts up, DPMS puts the monitor to sleep, etc.) the system will lock up.  It will recover after I eject the laptop from the dock, and after that point I can redock it, but while the system is locked up, the laptop heats up and the fan starts up --- which I suspect means that we are indeed hanging in some spinlock.
Comment 111 Daniel Martin 2014-02-11 07:39:55 UTC
(In reply to comment #109)
> Created attachment 93781 [details] [review] [review]
> drm/i915/dp: add max retries in native aux
> 
> Please try this for debug info.

Hardware:
- ThinkPad T540p
- ThinkPad Pro Dock [40A1] (with DP, DVI, VGA)
- Dell U2410

Tests:
- boot without any connectors: hotplugging of all connectors works
- boot once with each connector: works

dmesg logs for both tests (with DP) following ...
Comment 112 Daniel Martin 2014-02-11 07:41:56 UTC
Created attachment 93841 [details]
dmesg 3.13 with attachment/patch 93781 - boot with DP connected

Boot a kernel v3.13 with attachment 93781 [details] [review] in docking station with DP connected.
Comment 113 Daniel Martin 2014-02-11 07:43:39 UTC
Created attachment 93842 [details]
dmesg 3.13 with attachment/patch 93781 - hotplug DP

Boot a kernel v3.13 with attachment 93781 [details] [review] in docking station and hotplug DP.
Comment 114 Jani Nikula 2014-02-11 10:00:08 UTC
(In reply to comment #111)
> Tests:
> - boot without any connectors: hotplugging of all connectors works
> - boot once with each connector: works
> 
> dmesg logs for both tests (with DP) following ...

Thanks, the logs confirm we are indeed receiving plenty of aux defer replies from the sink. I sent the patches to the list [1], on top of drm-intel-nightly (3.13 requires trivial backporting). I'm not too optimistic about them fixing the actual output, just the hang.

[1] http://mid.gmane.org/cover.1392111874.git.jani.nikula@intel.com
Comment 115 Theodore Ts'o 2014-02-11 17:56:03 UTC
I tried applying the two patches which you posted on intel-gfx[1], ported to 3.13.

[1] http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737

Using a T540p and an Ultradock, connected to a Dell U2410 via a DisplayPort cable --- and it worked!  Not only were there no hangs, but in fact I could enable and disable the external display.  The "too many retries" did indeed trigger:

[    4.152360] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
...
[    4.245174] fbcon: inteldrmfb (fb0) is primary device
...
[    5.952436] [drm:intel_dp_aux_native_write] *ERROR* too many retries, giving up
[    6.004766] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[    6.129836] Console: switching to colour frame buffer device 240x75
[    6.134854] i915 0000:00:02.0: fb0: inteldrmfb frame buffer 
[    6.134856] i915 0000:00:02.0: registered panic notifier
[    6.275753] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[    6.276089] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
[    6.276620] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[    6.277149] snd_hda_intel 0000:00:03.0: irq 46 for MSI/MSI-Xdevice

When I tried disabling the external monitor, undocking, and redocking, and then tried enabled the external monitor again, the too many retries did trigger again:

[ 1066.879571] drm: not enough stolen space for compressed buffer (need 33554432 more bytes), disabling. Hint: you may be able to increase stolen memory size in the BIOS to avoid this.
[ 1070.884851] [drm:intel_dp_aux_native_write] *ERROR* too many retries, giving up
Comment 116 pascal.beyeler 2014-02-12 07:22:58 UTC
Lenovo has released a firmware update for the docking station.
Please see:
http://forums.lenovo.com/t5/T400-T500-and-newer-T-series/T540p-T440p-UltraDock-external-display-issues/td-p/1368847/highlight/true/page/14

Firmware update: http://download.lenovo.com/ibmdl/pub/pc/pccbbs/options/fwdphb01.exe

Unfortunately, there is no version for Linux. So you have to run Windows to update the firmware. Is someone here running a dual boot environment who could give it a try? Hopefully, this update solves our problem.
Comment 117 Ferry Huberts 2014-02-12 08:05:16 UTC
That is beta firmware.
The Lenovo guy in there said final firmware would likely be released next week.

And I asked for a bootable CD update, and other people did so as well.
The Lenovo guy in there said he'd pass on the request for a bootable CD update.
Comment 118 Philip Könighofer 2014-02-12 08:08:54 UTC
(In reply to comment #117)
> That is beta firmware.
> The Lenovo guy in there said final firmware would likely be released next
> week.
> 
> And I asked for a bootable CD update, and other people did so as well.
> The Lenovo guy in there said he'd pass on the request for a bootable CD
> update.

Just installed the firmware update. Now dock shows firmware version 2.17.
Firmware update utility required Intel display-driver installed on my Windows 8.1 installation, otherwise it was unable to update to detect the DP-hub.

Now reinstalling Linux. I am going to report back in a few minutes.
Comment 119 Philip Könighofer 2014-02-12 08:11:10 UTC
(In reply to comment #118)
> Just installed the firmware update. Now dock shows firmware version 2.17.
> Firmware update utility required Intel display-driver installed on my
> Windows 8.1 installation, otherwise it was unable to update to detect the
> DP-hub.

It also required a least one display connected to the dock during the update process.
Comment 120 pascal.beyeler 2014-02-12 08:16:10 UTC
(In reply to comment #117)
> That is beta firmware.
> The Lenovo guy in there said final firmware would likely be released next
> week.
> 
> And I asked for a bootable CD update, and other people did so as well.
> The Lenovo guy in there said he'd pass on the request for a bootable CD
> update.

Are you sure it is still a beta version? It doesn't say so on the official page:
http://support.lenovo.com/en_US/detail.page?DocID=HT081248
Comment 121 Ferry Huberts 2014-02-12 08:17:53 UTC
(In reply to comment #120)

> Are you sure it is still a beta version? It doesn't say so on the official
> page:
> http://support.lenovo.com/en_US/detail.page?DocID=HT081248

Ah ok, it appears I misunderstood.
Comment 122 Stefan Agner 2014-02-12 08:31:56 UTC
Just installed this new Firmware (which claims to be Version 2.17). It certainly improves situation, I get output on my HDMI monitor with an unpatched kernel:

However, I still get
[drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting

I also get a mirrored output on VGA, however I could not extend to that adapter. (it seems to be a hardware mirror, I only see one external display, DP2, in XrandR...)

See also dmesg-debug-3.12.7-with-dock-firmware-2.17.txt
Comment 123 Stefan Agner 2014-02-12 08:32:40 UTC
Created attachment 93905 [details]
dmesg-debug-3.12.7-with-dock-firmware-2.17.txt
Comment 124 Philip Könighofer 2014-02-12 08:42:27 UTC
(In reply to comment #122)
> I also get a mirrored output on VGA, however I could not extend to that
> adapter. (it seems to be a hardware mirror, I only see one external display,
> DP2, in XrandR...)

Same here. Switching to one external DP display now works like a charm. Gets identified as DP2 in xrandr.

Connecting a second DP display result in a mirrored output. Both external displays are identified as DP2.

There seems to be still a problem enumerating the devices connected to the DP hub
Comment 125 Sree Harsha Totakura 2014-02-12 08:52:28 UTC
(In reply to comment #115)
> I tried applying the two patches which you posted on intel-gfx[1], ported to
> 3.13.
> 
> [1] http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737
> 
> Using a T540p and an Ultradock, connected to a Dell U2410 via a DisplayPort
> cable --- and it worked!  Not only were there no hangs, but in fact I could
> enable and disable the external display.  The "too many retries" did indeed
> trigger:

These patches did not work for me with my T440s.  During bootup it hangs upon switch to FB.  Once booted undocked, it hangs when docked and external monitor is enabled through xrandr.
Comment 126 Philip Könighofer 2014-02-12 10:39:39 UTC
(In reply to comment #125)
> (In reply to comment #115)
> > I tried applying the two patches which you posted on intel-gfx[1], ported to
> > 3.13.
> > 
> > [1] http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737
> > 
> > Using a T540p and an Ultradock, connected to a Dell U2410 via a DisplayPort
> > cable --- and it worked!  Not only were there no hangs, but in fact I could
> > enable and disable the external display.  The "too many retries" did indeed
> > trigger:
> 
> These patches did not work for me with my T440s.  During bootup it hangs
> upon switch to FB.  Once booted undocked, it hangs when docked and external
> monitor is enabled through xrandr.

Try to update your dock to the new firmware. It should resolve this issue, at least if you are using only a single external display!
Comment 127 Jani Nikula 2014-02-12 10:51:15 UTC
(In reply to comment #125)
> These patches did not work for me with my T440s.  During bootup it hangs
> upon switch to FB.  Once booted undocked, it hangs when docked and external
> monitor is enabled through xrandr.

Dmesg with drm.debug=0xe please.
Comment 128 Jani Nikula 2014-02-12 10:53:31 UTC
(In reply to comment #124)
> There seems to be still a problem enumerating the devices connected to the
> DP hub

We currently do not support MST (multistream) DP branch devices. If it works for multiple monitors, great, but it's more or less by accident.
Comment 129 Philip Könighofer 2014-02-12 10:58:58 UTC
(In reply to comment #128)
> (In reply to comment #124)
> > There seems to be still a problem enumerating the devices connected to the
> > DP hub
> 
> We currently do not support MST (multistream) DP branch devices. If it works
> for multiple monitors, great, but it's more or less by accident.

Thank you for the feedback.

It seems the hang is resolved with the dock firmware update (2.17) provided by Lenovo. As far as I am concerned I think this bug can be closed.

If I understand correctly, MST support is entire different thing.
Is there already a bug/feature req. for this?
Comment 130 Jani Nikula 2014-02-12 10:59:55 UTC
(In reply to comment #114)
> Thanks, the logs confirm we are indeed receiving plenty of aux defer replies
> from the sink. I sent the patches to the list [1], on top of
> drm-intel-nightly (3.13 requires trivial backporting). I'm not too
> optimistic about them fixing the actual output, just the hang.
> 
> [1] http://mid.gmane.org/cover.1392111874.git.jani.nikula@intel.com

Oh, and I would appreciate people testing the patches *before* upgrading the dock firmware. We don't want to freeze the system regardless of what the DP sink/branch device does.
Comment 131 Jani Nikula 2014-02-12 11:05:11 UTC
(In reply to comment #129)
> It seems the hang is resolved with the dock firmware update (2.17) provided
> by Lenovo. As far as I am concerned I think this bug can be closed.

From the kernel perspective it's fixed when we don't freeze the machine even when a dock with buggy firmware is connected, which is what my patches fix.

Plus we need to follow-up on comment #125.

> If I understand correctly, MST support is entire different thing.
> Is there already a bug/feature req. for this?

Bug 72795.
Comment 132 Philip Könighofer 2014-02-12 11:14:25 UTC
(In reply to comment #131)
> (In reply to comment #129)
> > It seems the hang is resolved with the dock firmware update (2.17) provided
> > by Lenovo. As far as I am concerned I think this bug can be closed.
> 
> From the kernel perspective it's fixed when we don't freeze the machine even
> when a dock with buggy firmware is connected, which is what my patches fix.
> 
> Plus we need to follow-up on comment #125.

I have got the following devices:
   * T440s (Kernel 3.13.2)
   * Dock (fw2.10)
   * Dock (fw2.17)

If I can provide additional logs, please give me infos on which scenarios (/patches).
Comment 133 Sree Harsha Totakura 2014-02-12 11:54:47 UTC
(In reply to comment #132)
> I have got the following devices:
>    * T440s (Kernel 3.13.2)
>    * Dock (fw2.10)
>    * Dock (fw2.17)
> 
> If I can provide additional logs, please give me infos on which scenarios
> (/patches).

Apply the patches from this thread: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737 to linux-3.13.2 and provide dmesg output with 'drm.debug=0xe' kernel parameter.
Comment 134 Jani Nikula 2014-02-12 14:42:45 UTC
(In reply to comment #133)
> (In reply to comment #132)
> > I have got the following devices:
> >    * T440s (Kernel 3.13.2)
> >    * Dock (fw2.10)
> >    * Dock (fw2.17)
> > 
> > If I can provide additional logs, please give me infos on which scenarios
> > (/patches).
> 
> Apply the patches from this thread:
> http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/33737 to
> linux-3.13.2 and provide dmesg output with 'drm.debug=0xe' kernel parameter.

For convenience, rebased on top of v3.13.2:
http://cgit.freedesktop.org/~jani/drm/log/?h=native-aux-defer-v3.13.2
Comment 135 Theodore Ts'o 2014-02-12 15:26:24 UTC
Jani, for the record, I did my tests with your two patches before I updated the dock firmware, and it definitely did make the hangs go away --- and as I mentioned, I was even able to connect to an external Dell LCD panel using DP without any problems (although the "too many retries" debug message did trigger).

Many thanks for working on this issue, and I agree that the kernel should not be hanging even if the dock is buggy.   I have two Ultradocks (one at work and one at home) --- would it be helpful if I keep one unupgraded for now?   From looking at the intel-gfx list it sounds like you are planning on changing the infrastructure to use some new infrastructure in the next kernel version or two?  If you'd like me to do some testing of the new code with a buggy dock, I'm happy to keep one of my docks at the old firmware version, especially since the two patches seem to be an adequate workaround.
Comment 136 Ferry Huberts 2014-02-12 15:29:42 UTC
(In reply to comment #135)
> Many thanks for working on this issue, and I agree that the kernel should
> not be hanging even if the dock is buggy.   I have two Ultradocks (one at
> work and one at home) --- would it be helpful if I keep one unupgraded for

Me too.
I can help as well.

> now?   From looking at the intel-gfx list it sounds like you are planning on
> changing the infrastructure to use some new infrastructure in the next
> kernel version or two?  If you'd like me to do some testing of the new code
> with a buggy dock, I'm happy to keep one of my docks at the old firmware
> version, especially since the two patches seem to be an adequate workaround.
Comment 137 bfrancom 2014-02-12 16:53:00 UTC
(In reply to comment #124)
> (In reply to comment #122)
> > I also get a mirrored output on VGA, however I could not extend to that
> > adapter. (it seems to be a hardware mirror, I only see one external display,
> > DP2, in XrandR...)
> 
> Same here. Switching to one external DP display now works like a charm. Gets
> identified as DP2 in xrandr.
> 
> Connecting a second DP display result in a mirrored output. Both external
> displays are identified as DP2.
> 
> There seems to be still a problem enumerating the devices connected to the
> DP hub

Same on a Thinkpad W540 with Ultra Dock. Ubuntu 13.10 3.14.0-031400rc1-generic
Comment 138 Jean-Marc Valin 2014-02-12 20:31:56 UTC
I have a W540 that also freezes when trying to use DP, with the difference that I don't see any oops or error message in neither the kernel logs, nor the X logs. When I plug in an external monitor, xranrd shows it as connected to DP2, regardless of whether it's connected to DP1, DP2, DVI or HDMI. On one occasion, I have been able to get a mirror output on both DP1 and DP2 (still after 1-2 min of freezing), even though xrandr still showed only DP2 as being connected. I have been unable to reproduce that partial success since. During the freeze, Xorg keeps using a steady 20% CPU, but any attempt at attaching gdb to the Xorg process only resulted in gdb feezing (had to kill -9 it). Anything I can run to help debugging this?
Comment 139 Bernhard 2014-02-12 21:28:06 UTC
(In reply to comment #138)
> When I plug in an external monitor, xranrd shows it as connected
> to DP2, regardless of whether it's connected to DP1, DP2, DVI or HDMI.

From how I understand it, this is because all the display connectors are provided through a DP MST hub that is working in the dock. This hub then provides three possible outputs (VGA, digital group 1 and digital group 2). We need DP MST support.
Comment 140 Jan Hieber 2014-02-12 21:38:41 UTC
It looks like MST is required to drive 4k monitors

read here: http://askubuntu.com/questions/369946/displayport-1-2-mst-daisy-chain-dual-monitor-setup-intel-graphics

If this is true i think it will be implemented soon. Does anybody know if there is still work for MSt support? i can't find anything about it.
Comment 141 Roland Dreier 2014-02-12 22:24:56 UTC
Is MST actually required for 4K / 60Hz monitors, or is HBR2 / DP 1.2 sufficient?  (My understanding is that Intel Linux drivers already support HBR2)
Comment 142 Jan Hieber 2014-02-12 22:27:52 UTC
I don't know. So without MST support there will be no way to connect more than one monitor to the dock?
Comment 143 Sree Harsha Totakura 2014-02-12 23:27:35 UTC
Created attachment 93971 [details]
dmesg-jani-patches-docked.txt

dmesg output from drm module with changes proposed by Jani while the computer was booted while docked.
Comment 144 Sree Harsha Totakura 2014-02-12 23:33:48 UTC
Created attachment 93972 [details]
dmesg-jani-patches-undocked.txt

dmesg output from drm module with changes proposed by Jani while the computer was booted while undocked.  The computer is then docked and the display spilt using xrandr.
Comment 145 Sree Harsha Totakura 2014-02-12 23:36:10 UTC
(In reply to comment #131)
> From the kernel perspective it's fixed when we don't freeze the machine even
> when a dock with buggy firmware is connected, which is what my patches fix.
> 
> Plus we need to follow-up on comment #125.

Jani, my earlier comment was a false alarm.  My apologies.  I confirm that your patches work very well for my T440s with an Ultra Dock (firmware not updated).  I tested with following two scenarios:
1. Booting while docked and then using xrandr to split the display.
2. Booting undocked and then dock and use xrandr to split the display.
The changes worked well for both scenarios, albeit some minor delay which is very much acceptable.

As mentioned by Tso earlier, there were some "*ERROR* too many retries, giving up" messages.  Here are the dmesg outputs for the above two scenarios.
https://bugs.freedesktop.org/attachment.cgi?id=93971
https://bugs.freedesktop.org/attachment.cgi?id=93972

This bug may now be closed.

Thanks!
Comment 146 Daniel Vetter 2014-02-13 15:14:58 UTC
Thanks everyone for reporting this and testing patches, fix is now on track for 3.14 and stable kernels:

commit 2f589112609b0a964b3d78c99c0f3a83ac16add6
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Feb 11 11:52:05 2014 +0200

    drm/i915/dp: add native aux defer retry limit
Comment 147 Jean-Marc Valin 2014-02-13 16:17:15 UTC
Created attachment 94007 [details]
dmesg with patch applied, old firmware

I applied the patch on the FC20 3.12 kernel and although there was no freeze, I got some scary error messages in my kernel logs. See attached output. This is a Lenovo W540 laptop running Fedora 20 with the latest laptop BIOS, but the old dock firmware.
Comment 148 Jani Nikula 2014-02-14 08:38:42 UTC
(In reply to comment #147)
> Created attachment 94007 [details]
> dmesg with patch applied, old firmware
> 
> I applied the patch on the FC20 3.12 kernel and although there was no
> freeze, I got some scary error messages in my kernel logs. See attached
> output. This is a Lenovo W540 laptop running Fedora 20 with the latest
> laptop BIOS, but the old dock firmware.

That is to be expected if the display port sink replies with repeated aux defer messages. Error for the retry limit first, then error for the modeset failing due to this. Don't worry about it.

(The modeset failure message comes from the post-modeset state checker. We could handle this more gracefully, but there are scenarios where the failures we detect during modeset do not result in a non-working display... while bailing out early would definitely result in a non-working display.)
Comment 149 Jani Nikula 2014-02-14 12:41:48 UTC
(In reply to comment #85)
> I care about getting this fixed, so I'm offering USD 100.00 via
> FreedomSponsors to the first person who fix it.
> 
> Offer link:
> http://www.freedomsponsors.org/core/issue/433/sna-haswell-x-server-freezes-
> when-enabling-dp-at-docking-station
> 
> You can also join me and throw in a few bucks there and we'll get it fixed
> faster :)
> 					
> If you fix this issue (see my acceptance criteria there) please use that
> site to request your payment.

We had a bug in the driver, and thanks to this bug report it's now fixed. Everyone, thanks for the report and testing! I hear a firmware upgrade in the dock also fixes the issue, but it doesn't mean we didn't have a bug.

As the fix ended up being my commit, I feel I should express my view on the offered bounty. This is speaking solely for myself, not for my employer or colleagues. Regardless of the firmware fix, I think it would be unethical of me to accept any part of the bounty.

I am employed to work on the driver, and fixing issues like this is part of the job. Personal prize money should not directly affect, or give an impression that it would affect, the priorities I set and am given as an employed developer. This is also a team effort. I contributed the fix, but many developers were involved in the triage, and people who tested the patches likely spent more time on this than I did! (Thanks again!)

All that said, I appreciate the offer and FreedomSponsors in general, and I would have no qualms about accepting bounties for things I work on in a hobbyist capacity.

If you still feel indebted for having made the offer, please consider sponsoring some other task or donating to a charity of your choosing.

Thanks.
Comment 150 Ferry Huberts 2014-02-14 13:47:48 UTC
Jani,

Well spoken, respect.

That is why I love Open Source!
It tends to attract people with the 'right kind' of attitude AFAIC.

So thanks to everyone involved!

Keep up the good work :-)
Comment 151 Jonas Jakobsen 2014-02-14 14:02:01 UTC
Hi Jani

Awesome attitude, thanks for fixing this.

Do you know when there is an official new driver including this fix available on https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13815 or similar site (I for some reason cannot connect to the site right now, but I think it's where I got my last Intel linux driver).

Thanks in advance!
Comment 152 Jani Nikula 2014-02-14 14:53:57 UTC
(In reply to comment #151)
> Do you know when there is an official new driver including this fix
> available on https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13815
> or similar site (I for some reason cannot connect to the site right now, but
> I think it's where I got my last Intel linux driver).

CC Rodrigo, I think this question is for you. ;) The fix itself is queued to 3.14 and -stable.
Comment 153 Anastas Stoyanovsky 2014-02-14 15:00:34 UTC
Dual display is confirmed working after firmware upgrade.

I'm dual booting Arch Linux (uname -r: kernel 3.12.9-2-ARCH) and Windows 7 on a Thinkpad T440 and using the Thinkpad Pro Dock; after installing dock firmware version 2.17.00 linked above on Windows and rebooting into Arch, dual display (monitor model Acer V236HL) is confirmed working over DVI, including extended desktop.

Thank you to everyone that contributed to this fix.
Comment 154 Anastas Stoyanovsky 2014-02-14 15:01:50 UTC
(In reply to comment #153)
> Dual display is confirmed working after firmware upgrade.
> 
> I'm dual booting Arch Linux (uname -r: kernel 3.12.9-2-ARCH) and Windows 7
> on a Thinkpad T440 and using the Thinkpad Pro Dock; after installing dock
> firmware version 2.17.00 linked above on Windows and rebooting into Arch,
> dual display (monitor model Acer V236HL) is confirmed working over DVI,
> including extended desktop.
> 
> Thank you to everyone that contributed to this fix.

Elaboration: I have not applied any patches to the kernel at all. The firmware upgrade was enough in my case.
Comment 155 Georg Pichler 2014-02-15 01:16:50 UTC
(In reply to comment #149)
> As the fix ended up being my commit, I feel I should express my view on the
> offered bounty. This is speaking solely for myself, not for my employer or
> colleagues. Regardless of the firmware fix, I think it would be unethical of
> me to accept any part of the bounty.

Thank you all very much. And very well spoken, Jani. It's a great community at work here.
Comment 156 Mark A. Hershberger 2014-02-25 15:42:12 UTC
Additional datapoint since I just ran into this bug but haven't yet managed to upgrade the firmware.

I am running Debian Testing right now on a new x240 with the ultradock.  I was testing this and, just as gdm was about to start up, I docked the system.

Kernel is now saying "task kworker/1:3:1450 blocked for more than 120 seconds" and "task Xorg:1647 blocked for more than 120 seconds" followed by "Not tainted 3.12-1-amd64 #1"

I'll apply the firmware updates, but it I thought this might help someone who was searching for an answer.
Comment 157 Jani Nikula 2014-02-25 16:26:27 UTC
(In reply to comment #156)
> Additional datapoint since I just ran into this bug but haven't yet managed
> to upgrade the firmware.
> 
> I am running Debian Testing right now on a new x240 with the ultradock.  I
> was testing this and, just as gdm was about to start up, I docked the system.
> 
> Kernel is now saying "task kworker/1:3:1450 blocked for more than 120
> seconds" and "task Xorg:1647 blocked for more than 120 seconds" followed by
> "Not tainted 3.12-1-amd64 #1"
> 
> I'll apply the firmware updates, but it I thought this might help someone
> who was searching for an answer.

Was this with or without the kernel patches? If without, please try with them. Thanks.
Comment 158 Mark A. Hershberger 2014-02-28 21:51:18 UTC
without.  I haven't had time to compile a new one.
Comment 159 Thomas Fogh Damgaard 2014-03-13 09:35:03 UTC
Using Fedora 20 with kernel 3.13.6-200.fc20.x86_64 I can now use my Lenovo T440s and the ThinkPad Pro Dock and 1 external monitor. However if I connect a second monitor it just gets a mirror of the first external monitor. I can connect the first monitor to VGA or DVI and that works fine.

xrandr output with two monitor connected (same output with only one external monitor):
$ xrandr
Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 173mm
   1920x1080      60.0*+
   1400x1050      60.0  
   1280x1024      60.0  
   1280x960       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 459mm x 296mm
   1680x1050      60.0*+
   3360x1050      60.0  
   2560x1024      60.0  
   1280x1024      75.0     60.0  
   1440x900       75.0     59.9  
   1280x960       60.0  
   1280x800       74.9     59.8  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     60.0  
   720x400        70.1  
HDMI2 disconnected (normal left inverted right x axis y axis)
Comment 160 Daniel Martin 2014-03-13 10:10:16 UTC
(In reply to comment #159)
> Using Fedora 20 with kernel 3.13.6-200.fc20.x86_64 I can now use my Lenovo
> T440s and the ThinkPad Pro Dock and 1 external monitor. However if I connect
> a second monitor it just gets a mirror of the first external monitor. I can
> connect the first monitor to VGA or DVI and that works fine.

Duplicate of comment #122, an answer can be found in comment #128 or search for MST in this report.
Comment 161 Aidy 2014-03-13 13:35:32 UTC
(In reply to comment #159)
> DP2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis)
> 459mm x 296mm
>    1680x1050      60.0*+
>    3360x1050      60.0  

This is perhaps the wrong place, but I'm curious; if you select the 3360x1050 mode, does it stretch across both monitors?
Comment 162 Thomas Fogh Damgaard 2014-03-13 14:32:51 UTC
Thanks! Yes. It stretches across both monitors.
Comment 163 Martin 2014-04-24 07:40:36 UTC
So, to my understanding MST is not supported meaning that multiple (DP) connected monitors will become mirrored. However, it seems like also the DVI output is mirrored - is this expected? 

I am running Ubuntu 14.04 (i.e. 3.13.0-24-generic) on a T440p attached to an ultra dock (firmware 2.17), and attaching one DP monitor works flawlessly together with the builtin display. However attaching an additional monitor (occurs for both DP and DVI) simply mirrors the first DP connected display. xrandr outputs the same in either case:

martin@martin-ThinkPad-T440p:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
   1600x900       60.0 +
   1440x900       59.9  
   1360x768       59.8     60.0  
   1152x864       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200      60.0*+
   3840x1200      60.0  
   2560x1024      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x800       59.8  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        60.0  
   720x400        70.1  
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

I would expect the DVI port to be working independently of the DP port - is this  not the case?

thanks,
Martin
Comment 164 Jan Hieber 2014-04-24 08:40:11 UTC
Im not sure but i think all outputs (DP, DVI, VGA) are converted from DP. So one big DP Hub with direct DP, VGA-converter and DVI-converter.
Comment 165 Martin 2014-04-24 13:16:50 UTC
So no matter what we do, we can only reach a maximum of two unique displays (the builtin and one external) without MST?
Comment 166 Jan Hieber 2014-04-24 13:22:47 UTC
i currently have 1x mDP > HDMI; 1x DVI on Dock; and builtin. so 3 displays are possible with dock and builtin. and vga on the laptop directly may be also usable. i read that MST is currently in progress by some intel devs, i think it was on phoronix.
Comment 167 Martin 2014-04-24 13:42:55 UTC
Thanks Jan, I will try the mDP solution whenever I can get hold of an adapter/cable. 

I guess the post you are referring to is this http://www.phoronix.com/scan.php?page=news_item&px=MTY1MjI
Comment 168 Ferry Huberts 2014-04-24 14:47:05 UTC
(In reply to comment #166)
> i currently have 1x mDP > HDMI; 1x DVI on Dock; and builtin. so 3 displays
> are possible with dock and builtin. and vga on the laptop directly may be
> also usable. i read that MST is currently in progress by some intel devs, i
> think it was on phoronix.

That information is wrong.

David Airlie of Red Hat is hacking on it, see http://cgit.freedesktop.org/~airlied/linux/log/?h=i915-mst-hacks
Comment 169 Tomas Heinrich 2014-04-24 17:04:15 UTC
(In reply to comment #166)
> i currently have 1x mDP > HDMI; 1x DVI on Dock; and builtin. so 3 displays
> are possible with dock and builtin.

I can confirm that this setup works.

> and vga on the laptop directly may be also usable.

I've tried using it and it appears disabled when the laptop is docked.
Comment 170 Yaroslav Pronin 2015-02-06 10:13:33 UTC

The same problem on MacBook Air 2014 in the transition to the standby mode. After that set the brightness below 90% is not possible, the screen goes off completely. I think the problem in the module wl.
WARNING: CPU: 3 PID: 86 at drivers/gpu/drm/i915/intel_pm.c:6585 intel_display_power_put+0x15c/0x170 [i915]() [i915]


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.