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.
Created attachment 88694 [details] dmesg 3.11.6 (drm.debug=0x7)
Created attachment 88695 [details] Xorg.0.log (intel git:dc61705, --enable-debug=full)
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.
Created attachment 88700 [details] dmesg 3.11.6 (drm.debug=0xe)
(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.
(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.
Created attachment 88748 [details] dmesg 3.12.0 (drm.debug=0xe)
(In reply to comment #7) > Created attachment 88748 [details] > dmesg 3.12.0 (drm.debug=0xe) Anything else I can/should provide?
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.
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 {
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 {
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.
(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.
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.
(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.
Created attachment 89187 [details] dmesg, v3.12.0 + Patch from comment #11 - BUG: bad unlock balance detected!
Created attachment 89905 [details] dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop) dmesg wo/ docking station as reference
(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.
Created attachment 89906 [details] dmesg 3.13.0-rc1 dmesg w/ docking station
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?
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.
Try booting with i915.i915_enable_fbc=0
(In reply to comment #22) > Try booting with i915.i915_enable_fbc=0 Tried, doesn't change the result.
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?
(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?
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.
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*.)
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.
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().
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?
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
(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?
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
@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
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.
Same thing happens with Dell latitude e5540.
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
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.
So you're saying you see this same problem with a VGA connection, with your laptop undocked and no other displays connected to it?
That's right.
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?
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! :)
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.
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.
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?
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.
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 ;)).
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.
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.
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.
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.
Is it enough for you to change the sleep-time to 500us or do you additionally add some debug output (like the patch above)?
(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.
(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?
Created attachment 91164 [details] [review] patch against 3.13-rc4; DP on Ultra Dock works
(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. (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.)
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.
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.
latest ~danvet/drm-intel/drm-intel-nightly pachtes broke DP switching completely! System freezes all the time when connected to Dock!
(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...)
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.
Whether 3.13rc7 nor 3.13rc7 with https://bugs.freedesktop.org/attachment.cgi?id=91164 works for me. Any ideas?
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?
(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!
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.
(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.
Still sometimes got freezes when DP is attached after power on. Attaching before/after poweron/poweroff works fine (except the mirroring issue).
(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.
Any chance for official fix ?
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?
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?
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
Which intel graphics driver version has the working arch version?
~ $ pacman -Qe | grep intel xf86-video-intel 2.99.907-1
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
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
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
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.
Created attachment 92490 [details] dmesg_3.13_docking_hdmi_with_udelay
[2014-01-25 15:01] [PACMAN] upgraded lib32-dbus (1.6.18-1 -> 1.8.0-1) fix the issue on my side
too optimistic .. still I need to use on
too optimistic .. still I need to use on/trick
new dbus/libdbus does not work for me
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.
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.
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.
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.
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.
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...
Created attachment 92880 [details] Enable debug prints in link train path
Created attachment 92881 [details] Docking to a dock with an HDMI connection
Created attachment 92882 [details] Docking to a dock with an DP connection
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.
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.
(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):
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...
(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. :(
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.
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
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
Created attachment 93653 [details] [review] [PATCH]HDMI connection via dock works with some (random) delay
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.
fwiw the bounty for fixing this issue is now at $550. Please consider donating if this issue affects your ability to work.
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.
I've sponsored $50 towards getting this fixed. My requirements are a working DVI connection with a ThinkPad T440s and a ThinkPad Ultra Dock.
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.
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.
Created attachment 93781 [details] [review] drm/i915/dp: add max retries in native aux Please try this for debug info.
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.
(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 ...
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.
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.
(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
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
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.
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.
(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.
(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.
(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
(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.
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
Created attachment 93905 [details] dmesg-debug-3.12.7-with-dock-firmware-2.17.txt
(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
(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.
(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!
(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.
(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.
(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?
(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.
(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.
(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).
(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.
(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
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.
(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.
(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
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?
(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.
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.
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)
I don't know. So without MST support there will be no way to connect more than one monitor to the dock?
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.
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.
(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!
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
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.
(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.)
(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.
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 :-)
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!
(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.
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.
(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.
(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.
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.
(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.
without. I haven't had time to compile a new one.
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)
(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.
(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?
Thanks! Yes. It stretches across both monitors.
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
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.
So no matter what we do, we can only reach a maximum of two unique displays (the builtin and one external) without MST?
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.
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
(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
(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.
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.