Lenovo T440s freezes when connected to docking station
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
linux (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
This bug report looks to be for the same issue:
https:/
I came across the above bug report here:
https:/
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/
/dev/snd/
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
EcryptfsInUse: Yes
HibernationDevice: RESUME=
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=
ProcVersionSign
RelatedPackageV
linux-
linux-
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.
dmi.board.name: 20AQCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: 0B98405 STD
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 20AQCTO1WW
dmi.product.
dmi.sys.vendor: LENOVO
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #21 |
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #22 |
Created attachment 88694
dmesg 3.11.6 (drm.debug=0x7)
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #23 |
Created attachment 88695
Xorg.0.log (intel git:dc61705, --enable-
In freedesktop.org Bugzilla #71267, Daniel-ffwll (daniel-ffwll) wrote : | #24 |
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.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #25 |
Created attachment 88700
dmesg 3.11.6 (drm.debug=0xe)
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #26 |
(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 freedesktop.org Bugzilla #71267, Daniel-ffwll (daniel-ffwll) wrote : | #27 |
(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_
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #28 |
Created attachment 88748
dmesg 3.12.0 (drm.debug=0xe)
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #29 |
(In reply to comment #7)
> Created attachment 88748 [details]
> dmesg 3.12.0 (drm.debug=0xe)
Anything else I can/should provide?
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #30 |
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_
- 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.
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #31 |
Ah, we maybe corrupting the panel_vdd_work item. Try
diff --git a/drivers/
index bf961698f847.
--- a/drivers/
+++ b/drivers/
@@ -1161,9 +1161,14 @@ void ironlake_
-
+ if (cancel_
+ mutex_unlock(
+ cancel_
+ mutex_lock(
+ }
+
if (sync) {
} else {
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #32 |
And now compiles:
diff --git a/drivers/
index bf961698f847.
--- a/drivers/
+++ b/drivers/
@@ -1161,9 +1161,16 @@ void ironlake_
-
+ if (cancel_
+ struct drm_device *dev = intel_dp_
+
+ mutex_unlock(
+ cancel_
+ mutex_lock(
+ }
+
if (sync) {
} else {
In freedesktop.org Bugzilla #71267, Daniel-ffwll (daniel-ffwll) wrote : | #33 |
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 freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #34 |
(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.
In freedesktop.org Bugzilla #71267, Daniel-ffwll (daniel-ffwll) wrote : | #35 |
On Sat, Nov 9, 2013 at 12:17 PM, <email address hidden> wrote:
> --- Comment #13 from Chris Wilson <email address hidden> ---
> (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.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #36 |
(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.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #37 |
Created attachment 89187
dmesg, v3.12.0 + Patch from comment #11 - BUG: bad unlock balance detected!
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #38 |
Created attachment 89905
dmesg 3.12.0-rc1 (WITHOUT DOCK! - monitor directly at laptop)
dmesg wo/ docking station as reference
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #39 |
(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.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #40 |
Created attachment 89906
dmesg 3.13.0-rc1
dmesg w/ docking station
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #41 |
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_
And I've noticed that there're no calls to intel_dp_
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #42 |
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_
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/
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #43 |
Try booting with i915.i915_
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #44 |
(In reply to comment #22)
> Try booting with i915.i915_
Tried, doesn't change the result.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #45 |
I even tried this in ironlake_
if (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_
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_
Is there anything else I can provide or should test to help you with this bug?
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #46 |
(In reply to comment #24)
> I even tried this in ironlake_
> mode_config.mutex:
>
> if (mutex_
> mutex_unlock(
>
> 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_
> 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?
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #47 |
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/
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_
With the hack applied it doesn't deadlock in ironlake_
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.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #48 |
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*.)
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #49 |
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.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #50 |
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_
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().
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #51 |
Hi Todd, can you check intel_dp_
In freedesktop.org Bugzilla #71267, Tprevite (tprevite) wrote : | #52 |
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 freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #53 |
(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?
In freedesktop.org Bugzilla #71267, Tprevite (tprevite) wrote : | #54 |
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
In freedesktop.org Bugzilla #71267, Mailings-f (mailings-f) wrote : | #55 |
@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:/
In freedesktop.org Bugzilla #71267, Burtan (akaburtan) wrote : | #56 |
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.
In freedesktop.org Bugzilla #71267, Iivari-halla (iivari-halla) wrote : | #57 |
Same thing happens with Dell latitude e5540.
In freedesktop.org Bugzilla #71267, Tprevite (tprevite) wrote : | #58 |
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_
And the DPCD from the monitor is this:
[ 26.397960] [drm:intel_
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
In freedesktop.org Bugzilla #71267, Iivari-halla (iivari-halla) wrote : | #59 |
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.
In freedesktop.org Bugzilla #71267, Tprevite (tprevite) wrote : | #60 |
So you're saying you see this same problem with a VGA connection, with your laptop undocked and no other displays connected to it?
In freedesktop.org Bugzilla #71267, Iivari-halla (iivari-halla) wrote : | #61 |
That's right.
In freedesktop.org Bugzilla #71267, St-lendl (st-lendl) wrote : | #62 |
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?
In freedesktop.org Bugzilla #71267, Nemauen (nemauen) wrote : | #63 |
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! :)
In freedesktop.org Bugzilla #71267, Thomas-fogh-damgaard (thomas-fogh-damgaard) wrote : | #64 |
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.
In freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #65 |
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.
In freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #66 |
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?
In freedesktop.org Bugzilla #71267, St-lendl (st-lendl) wrote : | #67 |
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.
In freedesktop.org Bugzilla #71267, Andreas Mohrhard (l-andreas) wrote : | #68 |
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 ;)).
In freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #69 |
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.
In freedesktop.org Bugzilla #71267, Oliver Charles (oliver-charles) wrote : | #70 |
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.
In freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #71 |
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.
In freedesktop.org Bugzilla #71267, Nkalkhof (nkalkhof) wrote : | #72 |
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.
In freedesktop.org Bugzilla #71267, St-lendl (st-lendl) wrote : | #73 |
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 freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #74 |
(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 freedesktop.org Bugzilla #71267, St-lendl (st-lendl) wrote : | #75 |
(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?
In freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #76 |
Created attachment 91164
patch against 3.13-rc4; DP on Ultra Dock works
In freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #77 |
(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.
In freedesktop.org Bugzilla #71267, St-lendl (st-lendl) wrote : | #78 |
(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.)
In freedesktop.org Bugzilla #71267, Tasqa (tasqa) wrote : | #79 |
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.
In freedesktop.org Bugzilla #71267, Nkalkhof (nkalkhof) wrote : | #80 |
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.
In freedesktop.org Bugzilla #71267, Nkalkhof (nkalkhof) wrote : | #81 |
latest ~danvet/
In freedesktop.org Bugzilla #71267, Chris Wilson (ickle) wrote : | #82 |
(In reply to comment #60)
> latest ~danvet/
> 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...)
In freedesktop.org Bugzilla #71267, frederic.mohr (frederic-mohr) wrote : | #83 |
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.
In freedesktop.org Bugzilla #71267, Frederik-schwan (frederik-schwan) wrote : | #84 |
Whether 3.13rc7 nor 3.13rc7 with https:/
Any ideas?
In freedesktop.org Bugzilla #71267, Frederik-schwan (frederik-schwan) wrote : | #85 |
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 freedesktop.org Bugzilla #71267, Berzborn-marco (berzborn-marco) wrote : | #86 |
(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:/
Would be nice if you share what went wrong in your case and how you fixed it.
Thanks!
In freedesktop.org Bugzilla #71267, Frederik-schwan (frederik-schwan) wrote : | #87 |
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 freedesktop.org Bugzilla #71267, Nkalkhof (nkalkhof) wrote : | #88 |
(In reply to comment #61)
> (In reply to comment #60)
> > latest ~danvet/
> > 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.
In freedesktop.org Bugzilla #71267, Frederik-schwan (frederik-schwan) wrote : | #89 |
Still sometimes got freezes when DP is attached after power on. Attaching before/after poweron/poweroff works fine (except the mirroring issue).
In freedesktop.org Bugzilla #71267, Berzborn-marco (berzborn-marco) wrote : | #90 |
(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:/
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.
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #91 |
Any chance for official fix ?
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #92 |
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://
Do you did this firmware upgrade?
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #93 |
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?
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #94 |
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
In freedesktop.org Bugzilla #71267, Burtan (akaburtan) wrote : | #95 |
Which intel graphics driver version has the working arch version?
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #96 |
~ $ pacman -Qe | grep intel
xf86-video-intel 2.99.907-1
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #97 |
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
In freedesktop.org Bugzilla #71267, Jacek-6 (jacek-6) wrote : | #98 |
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
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #99 |
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
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #100 |
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_
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_
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #101 |
Created attachment 92490
dmesg_3.
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #102 |
[2014-01-25 15:01] [PACMAN] upgraded lib32-dbus (1.6.18-1 -> 1.8.0-1)
fix the issue on my side
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #103 |
too optimistic .. still I need to use on
In freedesktop.org Bugzilla #71267, Marek-1 (marek-1) wrote : | #104 |
too optimistic .. still I need to use on/trick
In freedesktop.org Bugzilla #71267, Frederik-schwan (frederik-schwan) wrote : | #105 |
new dbus/libdbus does not work for me
In freedesktop.org Bugzilla #71267, Pskk4kauyw (pskk4kauyw) wrote : | #106 |
I care about getting this fixed, so I'm offering USD 100.00 via FreedomSponsors to the first person who fix it.
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.
In freedesktop.org Bugzilla #71267, Eric Floehr (eric-intellovations) wrote : | #107 |
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.
In freedesktop.org Bugzilla #71267, David Runge (dvzrv) wrote : | #108 |
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.
In freedesktop.org Bugzilla #71267, Afran (afran) wrote : | #109 |
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://
Please let me know what further information I can provide to help solve this.
In freedesktop.org Bugzilla #71267, Vanittersum (vanittersum) wrote : | #110 |
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.
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.
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #111 |
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-
With that patch HDMI takes about 30 seconds and then I see output. But sometimes, it doesn't work at all (see with-link-
However, when I attached a DP monitor at it, switching worked almost instantly (see with-link-
I then traced down the "offending" debug print, and replaced it with a delay (see link-train-
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...
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #112 |
Created attachment 92880
Enable debug prints in link train path
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #113 |
Created attachment 92881
Docking to a dock with an HDMI connection
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #114 |
Created attachment 92882
Docking to a dock with an DP connection
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #115 |
Created attachment 92883
link-train-
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 freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #117 |
(In reply to comment #94)
Hi Stefan. Thanks for taking a look at this. I just tried your patch link-train-
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 freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #119 |
(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-
(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. :(
Ubuntu Foundations Team Bug Bot (crichton) wrote : | #1 |
Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https:/
To change the source package that this bug is filed about visit https:/
[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]
tags: | added: bot-comment |
affects: | ubuntu → linux (Ubuntu) |
Brad Figg (brad-figg) wrote : Missing required logs. | #2 |
This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:
apport-collect 1275794
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.
Changed in linux (Ubuntu): | |
status: | New → Incomplete |
Joseph Salisbury (jsalisbury) wrote : | #3 |
Would it be possible for you to test the latest upstream kernel? Refer to https:/
If this bug is fixed in the mainline kernel, please add the following tag 'kernel-
If the mainline kernel does not fix this bug, please add the tag: 'kernel-
If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".
Thanks in advance.
[0] http://
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
tags: | added: trusty |
Corey Bryant (corey.bryant) wrote : AlsaInfo.txt | #4 |
tags: | added: apport-collected |
description: | updated |
Corey Bryant (corey.bryant) wrote : BootDmesg.txt | #5 |
Corey Bryant (corey.bryant) wrote : CRDA.txt | #6 |
Corey Bryant (corey.bryant) wrote : CurrentDmesg.txt | #7 |
Corey Bryant (corey.bryant) wrote : IwConfig.txt | #8 |
Corey Bryant (corey.bryant) wrote : Lspci.txt | #9 |
Corey Bryant (corey.bryant) wrote : Lsusb.txt | #10 |
Corey Bryant (corey.bryant) wrote : ProcCpuinfo.txt | #11 |
Corey Bryant (corey.bryant) wrote : ProcEnviron.txt | #12 |
Corey Bryant (corey.bryant) wrote : ProcInterrupts.txt | #13 |
Corey Bryant (corey.bryant) wrote : ProcModules.txt | #14 |
Corey Bryant (corey.bryant) wrote : PulseList.txt | #15 |
Corey Bryant (corey.bryant) wrote : RfKill.txt | #16 |
Corey Bryant (corey.bryant) wrote : UdevDb.txt | #17 |
Corey Bryant (corey.bryant) wrote : UdevLog.txt | #18 |
Corey Bryant (corey.bryant) wrote : WifiSyslog.txt | #19 |
Corey Bryant (corey.bryant) wrote : | #20 |
I just booted with the latest kernel and it's not fixed there.
linux-image-
Changed in linux: | |
importance: | Unknown → Medium |
status: | Unknown → Incomplete |
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #120 |
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://
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.
tags: | added: kernel-bug-exists-upstream |
Changed in linux (Ubuntu): | |
status: | Incomplete → Confirmed |
In freedesktop.org Bugzilla #71267, Arnd (arnd-arndnet) wrote : | #121 |
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_
[ 94.401356] ffff88030ffffd80 0000000000000046 ffff88030fc3c800 ffff88030fffffd8
[ 94.401365] 0000000000012f80 0000000000012f80 ffff88030fc3c800 ffff880310272228
[ 94.401373] ffff88031027222c ffff88030fc3c800 00000000ffffffff ffff880310272230
[ 94.401381] Call Trace:
[ 94.401399] [<ffffffff8164b
[ 94.401408] [<ffffffff8164d
[ 94.401416] [<ffffffff8164d
[ 94.401477] [<ffffffffa0126
[ 94.401487] [<ffffffff81061
[ 94.401494] [<ffffffff81062
[ 94.401502] [<ffffffff81062
[ 94.401511] [<ffffffff81068
[ 94.401521] [<ffffffff81068
[ 94.401529] [<ffffffff81656
[ 94.401538] [<ffffffff81068
[ 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] [<ffffffff8164b
[ 94.401644] [<ffffffff8164a
[ 94.401657] [<ffffffff81051
[ 94.401715] [<ffffffffa0127
[ 94.401725] [<ffffffff81087
[ 94.401776] [<ffffffffa0127
[ 94.401825] [<ffffffffa0128
[ 94.401875] [<ffffffffa012a
[ 94.401926] [<ffffffffa0123
[ 94.401974] [<ffffffffa0113
[ 94.401983] [<ffffffff81334
[ 94.402029] [<ffffffffa0115
[ 94.402037] [<ffffffff81334
[ 94.402085] [<ffffffffa0118
[ 94.402130] [<ffffffffa0118
[ 94.402175] [<ffffffffa003f
[ 94.402216] [<ffffffffa0042
[ 94.402247] [<ffffffffa0033
In freedesktop.org Bugzilla #71267, Tprevite (tprevite) wrote : | #122 |
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
Changed in linux (Ubuntu): | |
status: | Confirmed → Triaged |
In freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #123 |
Created attachment 93653
[PATCH]HDMI connection via dock works with some (random) delay
In freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #124 |
Created attachment 93654
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.
In freedesktop.org Bugzilla #71267, Pskk4kauyw (pskk4kauyw) wrote : | #125 |
fwiw the bounty for fixing this issue is now at $550. Please consider donating if this issue affects your ability to work.
In freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #126 |
I tried Agner's train delay patch (https:/
I observed the following in dmesg:
root@iris:
[ 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_
[ 1216.132474] [drm] stuck on render ring
[ 1216.132490] [drm] GPU crash dump saved to /sys/class/
[ 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.freedeskto
[ 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:/
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 b...
In freedesktop.org Bugzilla #71267, Oliver Charles (oliver-charles) wrote : | #127 |
I've sponsored $50 towards getting this fixed. My requirements are a working DVI connection with a ThinkPad T440s and a ThinkPad Ultra Dock.
In freedesktop.org Bugzilla #71267, Herr-jth (herr-jth) wrote : | #128 |
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-
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.
In freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #129 |
This post http://
In freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #130 |
Created attachment 93781
drm/i915/dp: add max retries in native aux
Please try this for debug info.
In freedesktop.org Bugzilla #71267, Theodore Ts'o (tytso) wrote : | #131 |
I tried applying the patch ([PATCH]HDMI connection via dock works with some (random) delay: https:/
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 freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #132 |
(In reply to comment #109)
> Created attachment 93781 [details] [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 ...
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #133 |
Created attachment 93841
dmesg 3.13 with attachment/patch 93781 - boot with DP connected
Boot a kernel v3.13 with attachment 93781 in docking station with DP connected.
In freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #134 |
Created attachment 93842
dmesg 3.13 with attachment/patch 93781 - hotplug DP
Boot a kernel v3.13 with attachment 93781 in docking station and hotplug DP.
In freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #135 |
(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://<email address hidden>
In freedesktop.org Bugzilla #71267, Theodore Ts'o (tytso) wrote : | #136 |
I tried applying the two patches which you posted on intel-gfx[1], ported to 3.13.
[1] http://
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_
[ 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/
[ 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_
In freedesktop.org Bugzilla #71267, Pascal-beyeler (pascal-beyeler) wrote : | #137 |
Lenovo has released a firmware update for the docking station.
Please see:
http://
Firmware update: http://
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.
In freedesktop.org Bugzilla #71267, Mailings-f (mailings-f) wrote : | #138 |
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 freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #139 |
(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 freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #140 |
(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 freedesktop.org Bugzilla #71267, Pascal-beyeler (pascal-beyeler) wrote : | #141 |
(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://
In freedesktop.org Bugzilla #71267, Mailings-f (mailings-f) wrote : | #142 |
(In reply to comment #120)
> Are you sure it is still a beta version? It doesn't say so on the official
> page:
> http://
Ah ok, it appears I misunderstood.
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #143 |
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_
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-
In freedesktop.org Bugzilla #71267, K-stefan (k-stefan) wrote : | #144 |
Created attachment 93905
dmesg-debug-
In freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #145 |
(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 freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #146 |
(In reply to comment #115)
> I tried applying the two patches which you posted on intel-gfx[1], ported to
> 3.13.
>
> [1] http://
>
> 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 freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #147 |
(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://
> >
> > 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 freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #148 |
(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 freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #149 |
(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 freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #150 |
(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 freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #151 |
(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://<email address hidden>
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 freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #152 |
(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?
In freedesktop.org Bugzilla #71267, G-philip (g-philip) wrote : | #153 |
(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 freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #154 |
(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://
In freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #155 |
(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://
> linux-3.13.2 and provide dmesg output with 'drm.debug=0xe' kernel parameter.
For convenience, rebased on top of v3.13.2:
http://
In freedesktop.org Bugzilla #71267, Theodore Ts'o (tytso) wrote : | #156 |
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 freedesktop.org Bugzilla #71267, Mailings-f (mailings-f) wrote : | #157 |
(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 freedesktop.org Bugzilla #71267, bfrancom@gmail.com (bfrancom) wrote : | #158 |
(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-
In freedesktop.org Bugzilla #71267, Jmvalin (jmvalin) wrote : | #159 |
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 freedesktop.org Bugzilla #71267, Bernhard (schlimmchen) wrote : | #160 |
(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
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.
In freedesktop.org Bugzilla #71267, Roland Dreier (roland.dreier) wrote : | #162 |
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?
In freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #164 |
Created attachment 93971
dmesg-jani-
dmesg output from drm module with changes proposed by Jani while the computer was booted while docked.
In freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #165 |
Created attachment 93972
dmesg-jani-
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 freedesktop.org Bugzilla #71267, Freedesktop-s (freedesktop-s) wrote : | #166 |
(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:/
https:/
This bug may now be closed.
Thanks!
In freedesktop.org Bugzilla #71267, Daniel-ffwll (daniel-ffwll) wrote : | #167 |
Thanks everyone for reporting this and testing patches, fix is now on track for 3.14 and stable kernels:
commit 2f589112609b0a9
Author: Jani Nikula <email address hidden>
Date: Tue Feb 11 11:52:05 2014 +0200
drm/i915/dp: add native aux defer retry limit
In freedesktop.org Bugzilla #71267, Jmvalin (jmvalin) wrote : | #168 |
Created attachment 94007
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.
Changed in linux: | |
status: | Incomplete → Fix Released |
In freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #169 |
(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 freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #170 |
(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://
> when-enabling-
>
> 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.
In freedesktop.org Bugzilla #71267, Mailings-f (mailings-f) wrote : | #171 |
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 :-)
In freedesktop.org Bugzilla #71267, Nemauen (nemauen) wrote : | #172 |
Hi Jani
Awesome attitude, thanks for fixing this.
Do you know when there is an official new driver including this fix available on https:/
Thanks in advance!
In freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #173 |
(In reply to comment #151)
> Do you know when there is an official new driver including this fix
> available on https:/
> 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.
In freedesktop.org Bugzilla #71267, Anastas-stoyanovsky (anastas-stoyanovsky) wrote : | #174 |
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 freedesktop.org Bugzilla #71267, Anastas-stoyanovsky (anastas-stoyanovsky) wrote : | #175 |
(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 freedesktop.org Bugzilla #71267, Georg Pichler (georgpichler) wrote : | #176 |
(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.
In freedesktop.org Bugzilla #71267, Mark A. Hershberger (hexmode) wrote : | #177 |
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 freedesktop.org Bugzilla #71267, Jani-nikula (jani-nikula) wrote : | #178 |
(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.
In freedesktop.org Bugzilla #71267, Mark A. Hershberger (hexmode) wrote : | #180 |
without. I haven't had time to compile a new one.
In freedesktop.org Bugzilla #71267, Giles Carré (giles-carre) wrote : | #179 |
I confirm this behaviour: with the dock firmware update (T440s in a ProDock for me), I can use external displays. I can have two external displays (two 1680x1050), one on HDMI port, an another on VGA port.
In normal mode, the two external displays are mirrored.
But I can put them in extended desktop mode and have something like one 3360x1050 display. I'd preffer have two distinct displays, because today it's difficult to manage the windows size of the graphic applications (in particular, the automatic resize facility when you push the window to the bottom/
Nevertheless, the good news is that I can use 3 displays in the same time: the internal one and the two externals.
Corey Bryant (corey.bryant) wrote : | #181 |
Tested successfully on 3.14.0-
In freedesktop.org Bugzilla #71267, Thomas-fogh-damgaard (thomas-fogh-damgaard) wrote : | #182 |
Using Fedora 20 with kernel 3.13.6-
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 freedesktop.org Bugzilla #71267, Consume-noise-7 (consume-noise-7) wrote : | #183 |
(In reply to comment #159)
> Using Fedora 20 with kernel 3.13.6-
> 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 freedesktop.org Bugzilla #71267, Notadrian (notadrian) wrote : | #184 |
(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?
In freedesktop.org Bugzilla #71267, Thomas-fogh-damgaard (thomas-fogh-damgaard) wrote : | #185 |
Thanks! Yes. It stretches across both monitors.
In freedesktop.org Bugzilla #71267, Ms-l (ms-l) wrote : | #186 |
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@
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.
Corey Bryant (corey.bryant) wrote : | #188 |
This is no longer an issue in the released version of 14.04 LTS.
In freedesktop.org Bugzilla #71267, Ms-l (ms-l) wrote : | #189 |
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.
In freedesktop.org Bugzilla #71267, Ms-l (ms-l) wrote : | #191 |
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://
In freedesktop.org Bugzilla #71267, Mailings-f (mailings-f) wrote : | #192 |
(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://
In freedesktop.org Bugzilla #71267, Theinric (theinric) wrote : | #193 |
(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.
In freedesktop.org Bugzilla #71267, Proninyaroslav (proninyaroslav) wrote : | #194 |
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/
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: kernel/ hung_task_ timeout_ secs" disables this message. panel_vdd_ work [i915] 884>] ? dequeue_ entity+ 0x144/0x4d0 815>] ? set_next_ entity+ 0x95/0xb0 5a8>] ? __switch_ to+0x118/ 0x4e0 029>] schedule+0x29/0x70 463>] schedule_ preempt_ disabled+ 0x23/0x30 9d8>] __mutex_ lock_slowpath+ 0x168/0x3b0 c32>] mutex_lock+ 0x12/0x30 8b5>] ironlake_ panel_vdd_ work+0x25/ 0x40 [i915] 6e7>] process_ one_work+ 0x167/0x450 0f1>] worker_ thread+ 0x121/0x3a0 fd0>] ? manage_ workers. isra.23+ 0x2b0/0x2b0 960>] kthread+0xc0/0xd0 8a0>] ? kthread_ create_ on_node+ 0x120/0x120 52c>] ret_from_ fork+0x7c/ 0xb0 8a0>] ? kthread_ create_ on_node+ 0x120/0x120
[ 480.195776] INFO: task kworker/0:1:34 blocked for more than 120 seconds.
[ 480.195779] "echo 0 > /proc/sys/
[ 480.195781] kworker/0:1 D 0000000000000246 0 34 2 0x00000000
[ 480.195803] Workqueue: events ironlake_
[ 480.195805] ffff880118cebd50 0000000000000046 0000000000014500 ffff880118cebfd8
[ 480.195809] ffff880118cebfd8 0000000000014500 ffff880119218870 ffff88011f214570
[ 480.195812] 0000000000000001 ffff880118cebcd8 ffffffff8109a884 ffff88011f2d4500
[ 480.195816] Call Trace:
[ 480.195822] [<ffffffff8109a
[ 480.195825] [<ffffffff81099
[ 480.195829] [<ffffffff81013
[ 480.195833] [<ffffffff814e1
[ 480.195835] [<ffffffff814e1
[ 480.195839] [<ffffffff814df
[ 480.195843] [<ffffffff814df
[ 480.195852] [<ffffffffa060a
[ 480.195855] [<ffffffff8107c
[ 480.195858] [<ffffffff8107d
[ 480.195861] [<ffffffff8107c
[ 480.195865] [<ffffffff81083
[ 480.195868] [<ffffffff81083
[ 480.195871] [<ffffffff814ea
[ 480.195875] [<ffffffff81083
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.