[Lenovo ThinkPad T450s] Issues after docking and locking

One thing that I tried was disabling RC6 in grub, but that didn't seem to help:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_rc6=0"

This change was made by a bot.

Another thing I found in /var/log/kern.log inbetween the FIFI underrun messages is this:

Oct 26 09:32:02 ako-notebook kernel: [58379.446230] ------------[ cut here ]------------
Oct 26 09:32:02 ako-notebook kernel: [58379.446267] WARNING: CPU: 2 PID: 2653 at /build/linux-XO_uEE/linux-4.13.0/drivers/gpu/drm/i915/intel_display.c:12273 intel_atomic_commit_tail+0xda3/0xf80 [i915]
Oct 26 09:32:02 ako-notebook kernel: [58379.446267] Modules linked in: ccm ipt_MASQUERADE nf_nat_masquerade_ipv4 xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 br_netfilter bridge stp llc aufs bnep binfmt_misc cmdlinepart intel_spi_platform intel_spi spi_nor mtd btusb btrtl btbcm btintel bluetooth arc4 ecdh_generic uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media intel_rapl x86_pkg_temp_thermal intel_powerclamp iwlmvm coretemp kvm_intel mac80211 kvm irqbypass intel_cstate intel_rapl_perf iwlwifi snd_seq_midi joydev snd_seq_midi_event input_leds snd_rawmidi serio_raw wmi_bmof snd_hda_codec_hdmi thinkpad_acpi snd_hda_codec_realtek cfg80211 snd_seq intel_pch_thermal snd_hda_codec_generic nvram rtsx_pci_ms snd_hda_intel memstick snd_hda_codec snd_seq_device snd_hda_core snd_hwdep snd_pcm mei_me snd_timer
Oct 26 09:32:02 ako-notebook kernel: [58379.446292] mei lpc_ich shpchp snd soundcore mac_hid xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack libcrc32c iptable_filter parport_pc ppdev lp parport ip_tables x_tables autofs4 algif_skcipher af_alg dm_crypt hid_generic usbhid hid rtsx_pci_sdmmc i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd i2c_algo_bit drm_kms_helper psmouse syscopyarea sysfillrect sysimgblt fb_sys_fops ahci e1000e libahci drm rtsx_pci ptp pps_core wmi video
Oct 26 09:32:02 ako-notebook kernel: [58379.446324] CPU: 2 PID: 2653 Comm: gnome-shell Tainted: G U W 4.13.0-16-lowlatency #19-Ubuntu
Oct 26 09:32:02 ako-notebook kernel: [58379.446325] Hardware name: LENOVO 20BWS2YL00/20BWS2YL00, BIOS JBET51WW (1.16 ) 07/08/2015
Oct 26 09:32:02 ako-notebook kernel: [58379.446325] task: ffffa06e241d8000 task.stack: ffffae6b88e08000
Oct 26 09:32:02 ako-notebook kernel: [58379.446345] RIP: 0010:intel_atomic_commit_tail+0xda3/0xf80 [i915]
Oct 26 09:32:02 ako-notebook kernel: [58379.446346] RSP: 0018:ffffae6b88e0bb08 EFLAGS: 00010286
Oct 26 09:32:02 ako-notebook kernel: [58379.446347] RAX: 0000000000000019 RBX: ffffa06e1b1d8310 RCX: 0000000000000006
Oct 26 09:32:02 ako-notebook kernel: [58379.446347] RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffffa06e3dc8dc70
Oct 26 09:32:02 ako-notebook kernel: [58379.446348] RBP: ffffae6b88e0bbc0 R08: 00000000000004df R09: 0000000000000004
Oct 26 09:32:02 ako-notebook kernel: [58379.446348] R10: 0000000000000001 R11: 0000000000000001 R12: ffffa06e22a1d000
Oct 26 09:32:02 ako-notebook kernel: [58379.446349] R13: ffffa06e251bd000 R14: ffffa06d809ee000 R15: ffffa06e1b1d8308
...

Alexander Kops, thank you for reporting this and helping make Ubuntu better.

In order to allow additional upstream developers to examine the issue, at your earliest convenience, could you please test the latest upstream kernel available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Also, you don't need to apport-collect further unless specifically requested to do so.

It is most helpful that after testing of the latest upstream kernel is complete, you mark this report Status Confirmed.

Lastly, to keep this issue relevant to upstream, please continue to test the latest mainline kernel as it becomes available.

Thank you for your help.

So I tried to reproduce it with the kernel v4.14-rc6 (bb176f67090ca54869fc1262c913aa69d2ede070)
I tried to get that error for an hour with some lock/unlock, suspend and hibernate cycles but it didn't appear.
Unfortunately I can't test it for a whole working day, since the internet is not working with that kernel (network manager shows everything is connected, but typing "route" on the command line yields an empty result).

Alexander Kops, to clarify:
1) When using the Ubuntu kernel, is the issue consistently reproducible?

2) You mention in your Bug Description:
>"...one of the three things happen when I come back after some time and try to unlock (so it went to power save in-between)"
Are you stating that only the screen turned off but the computer is still on, or the computer is set to either suspend or hibernate after a certain amount of time?

3) Kernel 4.14-rc7 just came out, which might let you test with internet working.

Hi
1) When using the current kernels 4.13.0-16-generic or 4.13.0-16-lowlatency it is insofar reproducible, that it happens most of the time (I'd say more than 50%).
But not every time, that's why I'm not confident to say the bug is fixed after one or two unlocks.

2) Yes, I think it only happens after suspend though. When I lock the screen and the computer goes into power save mode, then this would happen. If I only lock it and immediately unlock, this is not a problem.

3) I installed the rc7 and indeed the internet works with it. I'll be able to use it on a full work day on Wednesday. I'll report back on the end of the day Wednesday.

Tried it now with kernel 4.14.0-041400rc7-generic and it still appears. (Notebook sits in dock, locked the screen, let it sit for 45 minutes, came back to computer being shut down).

In /var/log/syslog I find

Nov 1 10:01:05 xxx kernel: [ 404.329288] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Nov 1 10:02:30 xxx kernel: [ 489.669089] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Nov 1 10:04:38 xxx kernel: [ 617.781995] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Alexander Kops, to advise, posting small snips of syslog, or any log for that matter, isn't helpful, as what you posted could be a result of some other issue earlier in the log. Instead, you would want to post the log in its entirety, and advise when in the log you performed an action correlated to the problem. In this case, the event most correlated to your computer improperly shutting down is the act of locking it.

With this in mind, I'd like to follow up on your comment:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1727662/comments/8
>"Yes, I think it only happens after suspend though."

It needs to be confirmed without doubt via you checking the GUI settings that your computer is set after you lock the screen that it will only turn off the monitor, only suspend, or turn off the monitor first, then some time after this event, it goes into suspend, etc. Could you please advise to which situation precisely is the case?

Also, with issues like these, folks typically update their buggy, outdated, and insecure BIOS prior to reporting, as BIOS bugs can manifest issues like this. As per your dmesg:
https://launchpadlibrarian.net/343008378/CurrentDmesg.txt
[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later)
...
[ 0.120112] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff]

In addition, there are numerous BIOS bugs fixed as identified by Lenovo:
https://pcsupport.lenovo.com/us/en/products/LAPTOPS-AND-NETBOOKS/THINKPAD-T-SERIES-LAPTOPS/THINKPAD-T450S/downloads/DS102110

Once updated, could you please post the result of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Oh, right now I'm running on the BIOS version
JBET51WW (1.16 )
07/08/2015
That's indeed a lot behind the current one. I'll try to update and report back.

I updated my BIOS to the current version
~ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
JBET66WW (1.30 )
09/13/2017

It didn't fix the [Firmware Bug] lines in the syslog though
Also the actual bug still appears. There seem to be some lines in the log that I haven't seen before though

Nov 3 12:37:05 xxx kernel: [ 8137.161988] [drm:pipe_config_err [i915]] *ERROR* mismatch in pixel_rate (expected 148500, found 296999)
Nov 3 12:37:05 xxx kernel: [ 8137.162024] [drm:pipe_config_err [i915]] *ERROR* mismatch in shared_dpll (expected ffff9818ca8b46e0, found ffff9818ca8b47
78)
Nov 3 12:37:05 xxx kernel: [ 8137.162051] [drm:pipe_config_err [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 148500, found 296999
)
Nov 3 12:37:05 xxx kernel: [ 8137.162076] [drm:pipe_config_err [i915]] *ERROR* mismatch in port_clock (expected 270000, found 540000)
Nov 3 12:37:05 xxx kernel: [ 8137.162078] pipe state doesn't match!

Can you advise on how to narrow down the error to the actual state where it happens?
Can it be achieved through changing settings in /etc/systemd/logind.conf?
Because currently the only way to reproduce it is locking the screen while the computer is sitting in the docking station and come back after a longer period of time (e.g. 30 minutes)

Somebody else seems to have a similar problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1506339

Alexander Kops, I'd like to circle back on some issues I raised that were unaddressed/unanswered in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1727662/comments/10:

1) Please make a comment to if you have the GUI setup to suspend and/or hibernate after a set amount of time, and how long the timeout is.
2) Please provide a screenshot of the GUI and how you have it configured for inactivity regarding the above.
3) Please stop posting snips of logs. As I mentioned before, it is not helpful here. Instead, attach the log uncompressed/untarred in its entirety with no modifications.
4) That's great you found fedora report who is reporting a similar error message. Unfortunately, there is so little information in that report, its largely useless.

Automatic locking is set to on after 3 minutes.

Here a screenshot of the energy settings (switched language to english). I'm not sure if there is any other setting where I could influence the behaviour.

Here the screen lock settings in English again.

Note that I usually lock the screen manually via the top right menu when I leave the computer.

Alexander Kops:
1) Could you please remove the kernel parameter "i915.enable_rc6=0", and any other non-default kernel parameters and keep it that way going forward? It is best to keep this as close to the default configurations as possible.
2) Could you please reproduce the problem with the latest mainline kernel, and attach to this report as separate files syslog and kernel.log?
3) Please advise which of the three events happened as per the Bug Description.
4) To satisfy a curiousity, does your computer's fan run loudly, and/or does the computer run hot temperature wise? Temperature monitoring information may be found at: https://help.ubuntu.com/community/SensorInstallHowto I would recommend polling only once every few seconds.

1) I forgot to mention that I removed "i915.enable_rc6=0" after I tried the first mainline kernel. So everything after that was already with RC6 enabled.
2) I'll try to reproduce it with the latest mainline kernel on Monday and attach the requested files.

4) I can't hear the fan and the temperatures seem to be ok right now (after a day of running), but I will keep monitoring it

sensors
iwlwifi-virtual-0
Adapter: Virtual device
temp1: +37.0°C

thinkpad-isa-0000
Adapter: ISA adapter
fan1: 0 RPM

acpitz-virtual-0
Adapter: Virtual device
temp1: +46.0°C (crit = +128.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +45.0°C (high = +105.0°C, crit = +105.0°C)
Core 0: +45.0°C (high = +105.0°C, crit = +105.0°C)
Core 1: +45.0°C (high = +105.0°C, crit = +105.0°C)

pch_wildcat_point-virtual-0
Adapter: Virtual device
temp1: +47.0°C

Please try kernel here http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/.

If the same issue still happens, file an upstream bug at: http://bugzilla.freedesktop.org
Product: DRI
Component: DRM/Intel

So I used the kernel at drm-intel-nightly/current/
It ran fine the whole day, but now I saw again that the notebook was shut down after locking the screen and coming back after half an hour.
But I'm not sure if it's the same bug, since I don't see any of the error messages previously reported in this bug report in the logs.

I'll attach syslog and kern.log. The problem happened between 17:00 and 17:30

The kern.log

Alexander Kops, to advise, if the root cause problem is drm-intel (I'll let Kai-Heng Feng speak to this as the root cause since he asked you to test this), and this is confirmed an issue in the latest mainline kernel (which is now 4.14-rc8) then testing drm-intel makes sense.

This is due to how Ubuntu sources paches from mainline (not drm-intel), and some patches, but not necessarily all, are sent from drm-intel to mainline. Also, drm-intel is an experimental, fast changing tree, where some patches that don't and will never exist in mainline can be removed/added at any time.

Despite this, while you did note the kernel crash as per #4, and the errors as per the Bug Description, you didn't include the log in its entirety, which would allow one to best confirm this is the root cause.

I took a peak at the recent attachments, and while I'm not an expert, I didn't find better confirmation either way.

Kai-Heng Feng, could you please advise on your thoughts regarding the root cause here?

Would an SSH/netconsole dump be helpful here as per https://help.ubuntu.com/community/DebuggingSystemCrash, or you think enough information is available?

So if I got you right, additionally you want me to install the latest mainline 4.14-rc8, reproduce the bug there and then attach kern.log and syslog here?

Alexander Kops, yes please. Also, it would be helpful to attach the information via SSH or netconsole via https://help.ubuntu.com/community/DebuggingSystemCrash .

In addition, to follow up:
1) Have the issues happened without having to lock the computer (i.e. during active daily use, with the PC in or not in the docking station)? No need for a test to this specifically, just as per your recollection?
2) When the computer is plugged into the docking station, does the OS recognize this by showing the battery icon in a charging/charged state?
3) Does this issue happen if you don't dock the computer in the docking station, and only have the power cord plugged into the computer directly (i.e. no external monitors plugged)?
4) Does the issue happen bypassing the docking station, and plugging the monitors and power directly into the laptop?
5) Does this issue happen if the PC has nothing connected (i.e. keep it on battery, and no external monitors)?
6) Regarding your question in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1727662/comments/12 :
>"Can you advise on how to narrow down the error to the actual state where it happens?"

What seems strange is how after locking the computer with it plugged into the docking station, presuming the power cord is plugged into the docking station, there are a few events in order of most to least interest:
* The PC is set to suspend on battery. I originally presumed that this is the issue trigger, but was thrown off as the GUI screenshots are set to do this only on battery.
* The screen dims when inactive. You could try rapidly toggling the brightness max up/down.
* The WiFi turning off. You could try toggling the WiFi hard swich/key combo repeatedly.
* The lock event itself. You could try locking and immediately unlocking multiple times in quick succession.

Today I installed 4.14.0-041400rc8-generic
I had a crash again, this time the computer did not power down but I came back to a completely frozen lock screen (only visible on the main monitor, not the secondary screens), so I had to hard reboot.
I'll attach kern.log and syslog

Syslog from todays crash with 4.14.0-041400rc8-generic

Regarding your other questions:
1) The issues have not happened without locking so far. Everything works smoothly when I don't lock (so that's why my workaround is to not lock the screen when I'm only away for short, although it's against company policies...)
2) When docked in the docking station I can see the loading battery icon and "Fully charged"
3,4,5) I have to test this separately again, maybe on the weekend. So far I did not see the issues when the computer was undocked (and no external displays present).

For the points raised in #6, I will test this and answer back later.

Alexander Kops:
1) What is the manufacturer, model, and firmware version of your docking station?
2) Your recent logs much better confirm the root cause. Hence, could you please cross post this issue to Intel following their instructions for 1.1-DRM KERNEL via https://01.org/linuxgraphics/documentation/how-report-bugs ? Please provide a direct URL to this new report once made so that it may be tracked.

1) It's a lenovo ThinkPad Ultra Dock Type 40A2 20V
I didn't know docking stations had firmwares up until now. Is there a way to find out via Ubuntu? Otherwise I have to talk to my company helpdesk about it.
2) Ok, will report it there. Do I have to try with another kernel again? Since the /drm-intel-nightly/current/ I tried it with did not yield the same log outputs...

Alexander Kops:
>"1) It's a lenovo ThinkPad Ultra Dock Type 40A2 20V I didn't know docking stations had firmwares up until now. Is there a way to find out via Ubuntu? Otherwise I have to talk to my company helpdesk about it."

While I'm not sure how to check via Ubuntu, the path of least resistence may be to pop a Windows laptop on the dock if available, and confirm via https://support.lenovo.com/us/en/solutions/migr-4tpjf4

>"2) Ok, will report it there. Do I have to try with another kernel again? Since the /drm-intel-nightly/current/ I tried it with did not yield the same log outputs..."

As per Intel's instructions, they want to you to test drm-tip, and provide debugging information. However, you don't have to build it. Instead, pre-built builds are provided as a courtesy by Ubuntu maintainers via https://wiki.ubuntu.com/Kernel/MainlineBuilds

Also, don't worry about SSH/netconsole, as that is usually for when the logs aren't giving reasonable hints to root cause. The latest logs were much better.

Ok, I'll install the drm-tip kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/ , try to reproduce it there, and report it to Intel.

Alexander Kops, to advise, if you can't reproduce in drm-tip, still report it as per their instructions as it's reproducible in mainline (i.e. upstream issue).

Some updates:
* I cross posted the issue to the freedesktop bugtracker here: https://bugs.freedesktop.org/show_bug.cgi?id=103643
* I got my docking station firmware updated, it is now at 2.33.00. Unfortunately I was not able to determine what the previous version was
* I'm running with the current drm-tip kernel for 1.5 days now and the issue was *not* reproducable so far

Alexander Kops, couple of issues:
1) To clarify, after the firmware update, is the issue still reproducible with latest mainline?
2) Your upstream post is missing all the information requested by Intel as documented in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1727662/comments/30 . It makes it most difficult for upstream to help if the information they request isn't provided. Also, upstream may ignore your post due to it not having required, publicly documented debugging information.

1) Currently trying to reproduce
2) I know, I'm trying to reproduce the issue with "drm.debug=0x1e log_buf_len=1M" added right now, and will add the information later

Alexander Kops:
"2) I know, I'm trying to reproduce the issue with "drm.debug=0x1e log_buf_len=1M" added right now, and will add the information later"

If it's not reproducible in drm-tip, if reproducible in mainline then one could take this debug log from there. This will given them a hint on what difference between mainline and drm-tip addressed the issue.

So I was just able to reproduce the shut-down issue with the kernel 4.14.0-041400rc8-generic and the debugging flags enabled.
I submitted a kern.log to the upstream bug report.

Hi Alexander. Thanks for your bug report and all your effort to troubleshoot and fix this weird issue.
I'm not using any docking station but I'm experiencing the same behaviour (screen flickering and unable to lock my screen) here on a Lenovo T450s with a Intel HD Graphics 5500 (Broadwell GT2) GPU.
It happens both with Ubuntu 17.10 and Fedora (26 and 27) so i'm so I suppose that's a weird bug in the intel driver.
Did you find any workaround or fix?

As reported upstream, when I used the drm-tip kernel I didn't see the FIFO error message in the logs again (but still had random power downs).
I'm running the mainline kernel 4.15.0-041500rc8-generic and also don't see any of the described issues anymore (although I still have 1-2 random shutdowns per week while the notebook sits in the dock unattended, but there is currently no hint that it's related to the Intel driver).

I think I am having the same issue on my DELL XPS 13 with intel graphics (no dock).

Is this what you are all seeing? https://www.youtube.com/watch?v=2g2GRca3nik

lanrat, in order to address your issue, it will help immensely if you use the computer the problem is reproducible with, and file a new report with Ubuntu via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

Christopher, the purpose of my question was because, after some research, I do not think that this is a device specific issue, and is actually the result of the kernel and graphics card. Hence why I posted the video to see if you are all seeing the same issue or if it is unrelated.

lanrat, nobody can root cause your issue simply by reviewing a video. However, posting a report allows developers to review debugging logs for root causing.

Christopher, I apologize if I am miscommunicating.

All I am asking is if what you are observing is similar to the video I posted, nothing more.

lanrat, Launchpad is a development platform, for Ubuntu users to provide debugging information of problems for developers to review, and fix. Asking folks to review a video without providing debugging information is unhelpful here.

Christopher, I am trying to provide debugging information for myself and the Ubuntu developers. I have NOT asked anybody to perform a root cause analysis, debug my problem, or perform any video review. I have only asked if the observed behavior in the bug in this thread is similar to the one I am observing because all of the other debug information listed in this report is identical to my situation.

At this point I'm giving up on asking here. Maybe you are right and this is the wrong form, my thinking was that it would be helpful for you to know that this issue is not specific to the particular hardware listed here. I apologize if I have not been helpful.

I am also observing this issue on a Thinkpad T470s using a Thinkpad Ultra Type 40A2 dock.

Here is my syslog

I primarily observe this issue when manually turning on my monitor after unlock, after it fails to autowake. The problem appears to occur at Apr 11 09:08:41 in the attached kern.log.

Running on Ubuntu 16.04

/proc/version:
Linux version 4.13.0-36-generic (buildd@lgw01-amd64-033) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)) #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018

/proc/cpuinfo attached

Hi, I would like to confirm this as this also affects not only my client but also my Colleagues (thinkpad T460s and T470s). The Problem seem to occur after a few minutes of inactiviy randomly. Some experience this 3-4 times/day while some 2-5 times a week.

Running on Ubuntu Bionic 18.04
Kernel Version: 4.15.0-36-generic

Kernel Log is attached.

Same Problem seems to occur on my T480s with Thinkpad Ultra Docking station and two external displays.

After booting and login, all displays work, but after executing:
  # xrandr --output DP2-3 --rotate left

Display DP2-3 does not display anything any more, even though xrandr claims it should:
  #xrandr
  Screen 0: minimum 320 x 200, current 5680 x 1920, maximum 8192 x 8192
  […]
  DP2-3 connected 1200x1920+4480+0 left (normal left inverted right x axis y axis) 518mm x 324mm
     1920x1200 59.95*+
  […]

I'm running fully updated Ubuntu 18.10:
4.18.0-12-generic #13-Ubuntu SMP Wed Nov 14 15:17:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Same problem on Dell Lattitude 5591 with K17A USB C Dock. Laptop crashed after screen lock.

Alexander Kops, to keep this relevant to upstream, one would want to periodically check for, and test the latest mainline kernel (now 5.4-rc3) as it is released, to confirm if the drm-tip improvements have been made available for inclusion into Ubuntu.

Could you please advise?

Hello! I think i got the same issue.
Using a Thinkpad T440 with a Dockingstation (Ultra Dock) using two external Monitors.
The attached kernel.log contains all infos from the time i unlocked my laptop until i turned it off because it is completly frozen.
I cannot reproduce it, but it occures maybe two times a week.

System infos:
sudo lshw -C video
 PCI (sysfs)
   *-display
        Beschreibung: VGA compatible controller
        Produkt: 4th Gen Core Processor Integrated Graphics Controller
        Hersteller: Intel Corporation
        Physische ID: 2
        Bus-Informationen: pci@0000:00:02.0
        Version: 06
        Breite: 64 bits
        Takt: 33MHz
        Fähigkeiten: msi pm vga_controller bus_master cap_list rom
        Konfiguration: driver=i915 latency=0
        Ressourcen: irq:28 memory:f0000000-f03fffff memory:e0000000-efffffff ioport:3000(Größe=64) memory:c0000-dffff

uname -a
 Linux tp-T440p 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux