kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #43458
[Bug 1275794] Re: Lenovo T440s freezes when connected to docking station
Launchpad has imported 99 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=71267.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2013-11-05T14:00:13+00:00 Consume-noise-7 wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/0
------------------------------------------------------------------------
On 2013-11-05T14:01:02+00:00 Consume-noise-7 wrote:
Created attachment 88694
dmesg 3.11.6 (drm.debug=0x7)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/1
------------------------------------------------------------------------
On 2013-11-05T14:03:12+00:00 Consume-noise-7 wrote:
Created attachment 88695
Xorg.0.log (intel git:dc61705, --enable-debug=full)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/2
------------------------------------------------------------------------
On 2013-11-05T14:16:58+00:00 Daniel-ffwll wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/3
------------------------------------------------------------------------
On 2013-11-05T14:41:16+00:00 Consume-noise-7 wrote:
Created attachment 88700
dmesg 3.11.6 (drm.debug=0xe)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/4
------------------------------------------------------------------------
On 2013-11-05T14:45:39+00:00 Consume-noise-7 wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/5
------------------------------------------------------------------------
On 2013-11-05T15:33:24+00:00 Daniel-ffwll wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/6
------------------------------------------------------------------------
On 2013-11-06T12:41:05+00:00 Consume-noise-7 wrote:
Created attachment 88748
dmesg 3.12.0 (drm.debug=0xe)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/7
------------------------------------------------------------------------
On 2013-11-06T12:43:48+00:00 Consume-noise-7 wrote:
(In reply to comment #7)
> Created attachment 88748 [details]
> dmesg 3.12.0 (drm.debug=0xe)
Anything else I can/should provide?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/8
------------------------------------------------------------------------
On 2013-11-06T13:30:54+00:00 Consume-noise-7 wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/9
------------------------------------------------------------------------
On 2013-11-08T19:33:43+00:00 Chris Wilson wrote:
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 {
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/10
------------------------------------------------------------------------
On 2013-11-08T19:36:34+00:00 Chris Wilson wrote:
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 {
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/11
------------------------------------------------------------------------
On 2013-11-09T08:55:08+00:00 Daniel-ffwll wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/12
------------------------------------------------------------------------
On 2013-11-09T11:17:58+00:00 Chris Wilson wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/13
------------------------------------------------------------------------
On 2013-11-09T13:16:40+00:00 Daniel-ffwll wrote:
On Sat, Nov 9, 2013 at 12:17 PM, <bugzilla-daemon@xxxxxxxxxxxxxxx> wrote:
> --- Comment #13 from Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> ---
> (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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/14
------------------------------------------------------------------------
On 2013-11-13T08:22:10+00:00 Consume-noise-7 wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/15
------------------------------------------------------------------------
On 2013-11-14T12:04:36+00:00 Consume-noise-7 wrote:
Created attachment 89187
dmesg, v3.12.0 + Patch from comment #11 - BUG: bad unlock balance detected!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/16
------------------------------------------------------------------------
On 2013-11-27T16:32:53+00:00 Consume-noise-7 wrote:
Created attachment 89905
dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop)
dmesg wo/ docking station as reference
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/17
------------------------------------------------------------------------
On 2013-11-27T16:33:44+00:00 Consume-noise-7 wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/18
------------------------------------------------------------------------
On 2013-11-27T16:34:33+00:00 Consume-noise-7 wrote:
Created attachment 89906
dmesg 3.13.0-rc1
dmesg w/ docking station
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/19
------------------------------------------------------------------------
On 2013-11-27T16:41:03+00:00 Consume-noise-7 wrote:
I've retested with v3.13-0-rc1 as can be seen in attachment 89905
(without docking station) and attachment 89906 (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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/20
------------------------------------------------------------------------
On 2013-11-28T08:54:01+00:00 Consume-noise-7 wrote:
Created attachment 89947
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). 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/21
------------------------------------------------------------------------
On 2013-11-28T10:29:20+00:00 Chris Wilson wrote:
Try booting with i915.i915_enable_fbc=0
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/22
------------------------------------------------------------------------
On 2013-11-28T12:15:41+00:00 Consume-noise-7 wrote:
(In reply to comment #22)
> Try booting with i915.i915_enable_fbc=0
Tried, doesn't change the result.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/23
------------------------------------------------------------------------
On 2013-12-02T09:29:40+00:00 Consume-noise-7 wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/24
------------------------------------------------------------------------
On 2013-12-02T09:48:22+00:00 Chris Wilson wrote:
(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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/25
------------------------------------------------------------------------
On 2013-12-02T12:45:20+00:00 Consume-noise-7 wrote:
Created attachment 90101
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, 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/26
------------------------------------------------------------------------
On 2013-12-02T12:53:04+00:00 Consume-noise-7 wrote:
Created attachment 90102
patch used for attachment #90101
That's the patch I've used when booting and creating attachment #90101.
(There're no mixed tabs&spaces *jedihandwave*.)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/27
------------------------------------------------------------------------
On 2013-12-02T13:05:22+00:00 Chris Wilson wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/28
------------------------------------------------------------------------
On 2013-12-03T12:39:34+00:00 Consume-noise-7 wrote:
Created attachment 90151
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().
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/29
------------------------------------------------------------------------
On 2013-12-03T14:29:43+00:00 Chris Wilson wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/30
------------------------------------------------------------------------
On 2013-12-03T16:16:24+00:00 Tprevite wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/31
------------------------------------------------------------------------
On 2013-12-04T09:58:05+00:00 Consume-noise-7 wrote:
(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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/32
------------------------------------------------------------------------
On 2013-12-04T18:48:32+00:00 Tprevite wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/33
------------------------------------------------------------------------
On 2013-12-05T16:33:05+00:00 Mailings-f wrote:
@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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/34
------------------------------------------------------------------------
On 2013-12-05T18:19:13+00:00 Burtan wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/35
------------------------------------------------------------------------
On 2013-12-06T11:46:10+00:00 Iivari-halla wrote:
Same thing happens with Dell latitude e5540.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/36
------------------------------------------------------------------------
On 2013-12-06T17:54:32+00:00 Tprevite wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/37
------------------------------------------------------------------------
On 2013-12-06T18:02:59+00:00 Iivari-halla wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/38
------------------------------------------------------------------------
On 2013-12-06T19:04:31+00:00 Tprevite wrote:
So you're saying you see this same problem with a VGA connection, with
your laptop undocked and no other displays connected to it?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/39
------------------------------------------------------------------------
On 2013-12-06T19:09:28+00:00 Iivari-halla wrote:
That's right.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/40
------------------------------------------------------------------------
On 2013-12-06T20:45:39+00:00 St-lendl wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/41
------------------------------------------------------------------------
On 2013-12-08T13:56:14+00:00 Nemauen wrote:
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! :)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/42
------------------------------------------------------------------------
On 2013-12-11T08:39:32+00:00 Thomas-fogh-damgaard wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/43
------------------------------------------------------------------------
On 2013-12-12T13:03:02+00:00 G-philip wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/44
------------------------------------------------------------------------
On 2013-12-12T13:18:18+00:00 G-philip wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/45
------------------------------------------------------------------------
On 2013-12-16T05:36:48+00:00 St-lendl wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/46
------------------------------------------------------------------------
On 2013-12-16T20:00:29+00:00 Andreas Mohrhard wrote:
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 ;)).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/47
------------------------------------------------------------------------
On 2013-12-18T08:30:35+00:00 G-philip wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/48
------------------------------------------------------------------------
On 2013-12-19T15:18:11+00:00 Oliver Charles wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/49
------------------------------------------------------------------------
On 2013-12-21T17:23:13+00:00 Georg Pichler wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/50
------------------------------------------------------------------------
On 2013-12-21T21:28:40+00:00 Nkalkhof wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/51
------------------------------------------------------------------------
On 2013-12-23T21:34:27+00:00 St-lendl wrote:
Is it enough for you to change the sleep-time to 500us or do you
additionally add some debug output (like the patch above)?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/52
------------------------------------------------------------------------
On 2013-12-23T21:37:14+00:00 Georg Pichler wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/53
------------------------------------------------------------------------
On 2013-12-23T21:53:59+00:00 St-lendl wrote:
(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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/54
------------------------------------------------------------------------
On 2013-12-23T22:02:14+00:00 Georg Pichler wrote:
Created attachment 91164
patch against 3.13-rc4; DP on Ultra Dock works
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/55
------------------------------------------------------------------------
On 2013-12-23T22:04:27+00:00 Georg Pichler wrote:
(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 against the 3.13-rc4 vanilla kernel.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/56
------------------------------------------------------------------------
On 2013-12-23T22:22:41+00:00 St-lendl wrote:
(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.)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/57
------------------------------------------------------------------------
On 2014-01-03T12:44:16+00:00 TASQA wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/58
------------------------------------------------------------------------
On 2014-01-03T17:41:56+00:00 Nkalkhof wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/59
------------------------------------------------------------------------
On 2014-01-06T18:06:47+00:00 Nkalkhof wrote:
latest ~danvet/drm-intel/drm-intel-nightly pachtes broke DP switching
completely! System freezes all the time when connected to Dock!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/60
------------------------------------------------------------------------
On 2014-01-06T20:03:36+00:00 Chris Wilson wrote:
(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...)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/61
------------------------------------------------------------------------
On 2014-01-08T11:08:57+00:00 frederic.mohr wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/62
------------------------------------------------------------------------
On 2014-01-08T17:23:37+00:00 Frederik-schwan wrote:
Whether 3.13rc7 nor 3.13rc7 with https://bugs.freedesktop.org/attachment.cgi?id=91164 works for me.
Any ideas?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/63
------------------------------------------------------------------------
On 2014-01-08T18:22:50+00:00 Frederik-schwan wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/64
------------------------------------------------------------------------
On 2014-01-08T18:36:09+00:00 Berzborn-marco wrote:
(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!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/65
------------------------------------------------------------------------
On 2014-01-08T18:54:40+00:00 Frederik-schwan wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/66
------------------------------------------------------------------------
On 2014-01-08T20:58:12+00:00 Nkalkhof wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/67
------------------------------------------------------------------------
On 2014-01-09T13:44:27+00:00 Frederik-schwan wrote:
Still sometimes got freezes when DP is attached after power on.
Attaching before/after poweron/poweroff works fine (except the mirroring
issue).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/68
------------------------------------------------------------------------
On 2014-01-09T21:40:56+00:00 Berzborn-marco wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/69
------------------------------------------------------------------------
On 2014-01-10T22:51:47+00:00 Marek-1 wrote:
Any chance for official fix ?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/70
------------------------------------------------------------------------
On 2014-01-10T23:09:20+00:00 K-stefan wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/71
------------------------------------------------------------------------
On 2014-01-15T09:27:44+00:00 Consume-noise-7 wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/72
------------------------------------------------------------------------
On 2014-01-16T20:12:23+00:00 Marek-1 wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/73
------------------------------------------------------------------------
On 2014-01-17T17:55:16+00:00 Burtan wrote:
Which intel graphics driver version has the working arch version?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/74
------------------------------------------------------------------------
On 2014-01-17T21:32:37+00:00 Marek-1 wrote:
~ $ pacman -Qe | grep intel
xf86-video-intel 2.99.907-1
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/75
------------------------------------------------------------------------
On 2014-01-18T15:02:38+00:00 Marek-1 wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/76
------------------------------------------------------------------------
On 2014-01-18T19:56:34+00:00 Jacek-6 wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/77
------------------------------------------------------------------------
On 2014-01-18T20:12:02+00:00 Marek-1 wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/78
------------------------------------------------------------------------
On 2014-01-20T22:01:45+00:00 K-stefan wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/79
------------------------------------------------------------------------
On 2014-01-20T22:02:46+00:00 K-stefan wrote:
Created attachment 92490
dmesg_3.13_docking_hdmi_with_udelay
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/80
------------------------------------------------------------------------
On 2014-01-25T14:11:32+00:00 Marek-1 wrote:
[2014-01-25 15:01] [PACMAN] upgraded lib32-dbus (1.6.18-1 -> 1.8.0-1)
fix the issue on my side
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/81
------------------------------------------------------------------------
On 2014-01-25T14:16:09+00:00 Marek-1 wrote:
too optimistic .. still I need to use on
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/82
------------------------------------------------------------------------
On 2014-01-25T14:16:43+00:00 Marek-1 wrote:
too optimistic .. still I need to use on/trick
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/83
------------------------------------------------------------------------
On 2014-01-25T14:56:28+00:00 Frederik-schwan wrote:
new dbus/libdbus does not work for me
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/84
------------------------------------------------------------------------
On 2014-01-26T01:33:43+00:00 Pskk4kauyw wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/85
------------------------------------------------------------------------
On 2014-01-26T02:01:36+00:00 Eric Floehr wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/86
------------------------------------------------------------------------
On 2014-01-26T11:34:14+00:00 David Runge wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/87
------------------------------------------------------------------------
On 2014-01-26T11:53:06+00:00 Afran wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/88
------------------------------------------------------------------------
On 2014-01-27T10:57:14+00:00 Vanittersum wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/89
------------------------------------------------------------------------
On 2014-01-27T20:32:10+00:00 K-stefan wrote:
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...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/90
------------------------------------------------------------------------
On 2014-01-27T20:33:18+00:00 K-stefan wrote:
Created attachment 92880
Enable debug prints in link train path
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/91
------------------------------------------------------------------------
On 2014-01-27T20:34:23+00:00 K-stefan wrote:
Created attachment 92881
Docking to a dock with an HDMI connection
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/92
------------------------------------------------------------------------
On 2014-01-27T20:34:49+00:00 K-stefan wrote:
Created attachment 92882
Docking to a dock with an DP connection
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/93
------------------------------------------------------------------------
On 2014-01-27T20:37:05+00:00 K-stefan wrote:
Created attachment 92883
link-train-delay.patch
This solves the issue on a custom compiled 3.13 kernel for me (make
localyesconfig) using DP port 1.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/94
------------------------------------------------------------------------
On 2014-01-28T10:14:14+00:00 Jan Hieber wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/95
------------------------------------------------------------------------
On 2014-01-28T10:40:09+00:00 Georg Pichler wrote:
(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):
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/96
------------------------------------------------------------------------
On 2014-01-28T10:46:12+00:00 Jan Hieber wrote:
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...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/97
------------------------------------------------------------------------
On 2014-01-28T10:49:03+00:00 Georg Pichler wrote:
(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. :(
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275794/comments/98
** Changed in: linux
Status: Unknown => Incomplete
** Changed in: linux
Importance: Unknown => Medium
** Bug watch added: Red Hat Bugzilla #1036974
https://bugzilla.redhat.com/show_bug.cgi?id=1036974
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1275794
Title:
Lenovo T440s freezes when connected to docking station
Status in The Linux Kernel:
Incomplete
Status in “linux” package in Ubuntu:
Incomplete
Bug description:
This bug report looks to be for the same issue:
https://bugs.freedesktop.org/show_bug.cgi?id=71267
I came across the above bug report here:
https://bbs.archlinux.org/viewtopic.php?pid=1374408
I'm running with a Thinkpad T440s and ultra dock with hdmi<->hdmi. In
my case if I dock when hdmi is connected to the dock, the mouse and
keyboard freeze once connected. When I undock they unfreeze. If I
dock when hdmi is not connected to the dock, the mouse and keyboard
don't freeze.
Ubuntu release: 14.04 Trusty Tahr (development branch)
---
ApportVersion: 2.13.2-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: corey 2385 F.... pulseaudio
/dev/snd/controlC0: corey 2385 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=12d1435c-d652-4aab-8da6-3b043f3da722
InstallationDate: Installed on 2014-01-31 (3 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140130)
MachineType: LENOVO 20AQCTO1WW
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-5-generic.efi.signed root=UUID=d17999de-2672-48e5-b628-403d311d3251 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
RelatedPackageVersions:
linux-restricted-modules-3.13.0-5-generic N/A
linux-backports-modules-3.13.0-5-generic N/A
linux-firmware 1.123
Tags: trusty
Uname: Linux 3.13.0-5-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip kvm libvirtd lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/10/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: GJET67WW (2.17 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20AQCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: 0B98405 STD
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrGJET67WW(2.17):bd12/10/2013:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 20AQCTO1WW
dmi.product.version: ThinkPad T440s
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1275794/+subscriptions
