8086:1616 [Lenovo ThinkPad T450s] External monitor is disabled after resume

[crs]

I have an external screen connected to my machine (T450s, via docking station) and after resuming from suspend, my external monitor is disabled.

After some trial and error I made an interesting observation: The external monitor only stops working if suspend via systemctl suspend, sudo pm-suspend, or via the hotkey on my keyboard (K750).

However, this problem does not occur if I suspend via the menu entry in the upper right corner.

How is this even possible?

Mapping the suspend command from the upper right corner to a hotkey would be a sufficient workaround. But which command is used by that button?

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: xorg 1:7.7+7ubuntu4
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Tue May 12 11:10:31 2015
DistUpgraded: Fresh install
DistroCodename: vivid
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:5036]
InstallationDate: Installed on 2015-05-03 (9 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: LENOVO 20BWS03F00
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-15-generic root=/dev/mapper/vgubuntu-root ro quiet splash
SourcePackage: xorg
Symptom: display
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/10/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: JBET47WW (1.12 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20BWS03F00
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrJBET47WW(1.12):bd03/10/2015:svnLENOVO:pn20BWS03F00:pvrThinkPadT450s:rvnLENOVO:rn20BWS03F00:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
dmi.product.name: 20BWS03F00
dmi.product.version: ThinkPad T450s
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.12.1+15.04.20150410.1-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.60-2
version.libgl1-mesa-dri: libgl1-mesa-dri 10.5.2-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.5.2-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.17.1-0ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.9.0-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.5.0-1ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917-1~exp1ubuntu2.1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.11-1ubuntu2build1
xserver.bootTime: Tue May 12 11:08:05 2015
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:

xserver.version: 2:1.17.1-0ubuntu3

[crs (crs-s)]

Thanks for your response, Christopher.
I updated my BIOS to the latest version available:

JBET48WW (1.13 )
04/20/2015

Unfortunately, nothing has changed. The system still behaves like in the initial post of this report.

[crs (crs-s)]

By the way: Could this bug be related to systemd? I could imagine that, because (a) this does not occur on Utopic and (b) I just found someone having problems using an external screen, and those problems are related to systemd (http://askubuntu.com/questions/613693/15-04-closing-lid-does-not-suspend-laptop-if-connected-to-external-monitor).

[penalvch (penalvch)]

crs, just to clarify, if you boot into a kernel from Trusty, is this still reproducible?

[crs (crs-s)]

After some trial and error it seems like I have to rephrase the initial bug report:

If I resume from suspend caused by systemctl suspend, sudo pm-suspend, or via the hotkey on my keyboard (K750), the login screen is only shown on the build-in screen and not on the external monitor. In this case the external monitor remains off and has to be enabled again by pressing super+p multiple times.

However, if I resume from suspend caused be the suspend entry in the menu accessible from the upper right corner (hereafter referred to as 'menu suspend'), the login screen is shown on both screens (build-in and external). In this case the external monitor works as intended, even after logging in.

If automatic login is enabled, the login screen is never shown after resuming (obviously) and both monitors do work as intended. However, enabling automatic login is not a sufficient work around.

I wasn't able to reproduce this observation on an live CD system (tried 14.04, 14.10, 15.04) since those systems always behaved weird after another user with password was added.

So, how does 'menu suspend' differ from the other ways mentioned to suspend the system?

[penalvch (penalvch)]

crs, while still in Vivid, if you boot into a kernel from Trusty, is this still reproducible?

[crs (crs-s)]

I would really like to test this, but I'm unable to boot into a kernel from Trusty.

I installed
linux-headers-3.13.11-03131111_3.13.11-03131111.201411111336_all.deb
linux-headers-3.13.11-03131111-generic_3.13.11-03131111.201411111336_amd64.deb
linux-image-3.13.11-03131111-generic_3.13.11-03131111.201411111336_amd64.deb
and ran update-grub:
...
Found linux image: /boot/vmlinuz-3.19.0-16-generic
Found initrd image: /boot/initrd.img-3.19.0-16-generic
Found linux image: /boot/vmlinuz-3.13.11-03131111-generic
Found initrd image: /boot/initrd.img-3.13.11-03131111-generic
...

but 3.13 isn't shown during the boot process. What step did I miss?

[crs (crs-s)]

Unfortunately, it seems like that the T450s is not fully supported by Trusty. Suspend and resume doesn't even work when only the build-in screen is used.

Thus, there is no way for me to test if this behavior does exist on Trusty.

[penalvch (penalvch)]

crs, would Utopic provide a testable environment?

[crs (crs-s)]

I tested it on Utopic and this behavior didn't occur: both monitors work after resume.

[penalvch (penalvch)]

crs, are you able to test the latest mainline kernel in Utopic (or a Utopic kernel in Vivid)?

[crs (crs-s)]

Yes.

vivid + 3.17.1-031701-generic #201410150735 SMP Wed Oct 15 11:36:31 UTC 2014 x86_64 x86_64 x86_64:
The problem does *not* occur.

However, with a recent kernel (3.19.0-16-generic #16-Ubuntu SMP Thu Apr 30 16:09:58 UTC 2015 x86_64 x86_64 x86_64), the problem occurs.

[penalvch (penalvch)]

crs, could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test 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 bug 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 XY and Z are numbers corresponding to the kernel version.

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

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[crs (crs-s)]

This bug still exists on 4.1.0-040100rc4-generic #201505181436 SMP Mon May 18 18:38:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[penalvch (penalvch)]

crs, the next step is to fully commit bisect from kernel 3.17 to 3.19 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[crs (crs-s)]

last good kernel: 3.18.3-031803-generic
first bad kernel: 3.18.4-031804-generic

I tried to do a git bisect but I didn't make it far because there are no tags 3.18.3/3.18.4 in kernel repo (kernel.org) I cloned.
These are the only tags containing 3.18:
v3.18
v3.18-rc1
...
v3.18-rc7

Is there another ubuntu specific repository that contains the tags I mentioned (3.18.{3,4}) ?

[timobaumann (timobaumann)]

Hi crs,
I found the tags in git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git . Which will help you to bisect.
I had a look at the commits between 3.18.3 and 4. The two very last commits before 3.18.4 are my primary suspects:

commit 6b49734139bad7703ccdf0bded005c605f28ca61
Author: Greg Kroah-Hartman <email address hidden>
Date: Mon Mar 18 13:16:44 2013 -0700

    Revert "drm/i915: reorder setup sequence to have irqs for output setup"

    Revert commit 2a9810441fcc26cf3f006f015f8a62094fe57a90 which is
    commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.

    This caused problems in 3.8-stable, but all is fine in 3.9-rc.

    Signed-off-by: Greg Kroah-Hartman <email address hidden>
    Cc: Imre Deak <email address hidden>
    Cc: Daniel Vetter <email address hidden>

commit 2909d2604809e056e5fe3ee102c42cc7899b1739
Author: Greg Kroah-Hartman <email address hidden>
Date: Mon Mar 18 13:13:39 2013 -0700

    Revert "drm/i915: enable irqs earlier when resuming"

    This reverts commit 31f14f4219d2a74b7a6d86c7798f49141b5eccbe which was
    commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 upstream.

    It caused problems in the 3.8-stable series, but 3.9-rc is just fine.

    Signed-off-by: Greg Kroah-Hartman <email address hidden>
    Cc: Chris Wilson <email address hidden>
    Cc: Mika Kuoppala <email address hidden>
    Cc: Ilya Tumaykin <email address hidden>
    Cc: Daniel Vetter <email address hidden>

Not only are these the only commits mentioning i915, in addition, the diffs seem to remove some workarounds that set a enable_hotplug_processing; to false...

So, bisecting could probably be limited to trying the commit before 2909d2604809e056e5fe3ee102c42cc7899b1739, that commit, and the following commit.

I think it should be rather obvious what is going wrong for someone who is at the slightest familiar with this code.

[crs (crs-s)]

And there we have the bisect result:

>git bisect good a5872ca0a6f5e889d628b2946e550c7d0e892430
ddf6f9a4c9fb1c72ea2e8d196c9a580a8e914dbd is the first bad commit
commit ddf6f9a4c9fb1c72ea2e8d196c9a580a8e914dbd
Author: Dave Airlie <email address hidden>
Date: Mon Dec 8 13:23:37 2014 +1000

    drm/i915: resume MST after reading back hw state

    commit e7d6f7d708290da1b7c92f533444b042c79412e0 upstream.

    Otherwise the MST resume paths can hit DPMS paths
    which hit state checker paths, which hit WARN_ON,
    because the state checker is inconsistent with the
    hw.

    This fixes a bunch of WARN_ON's on resume after
    undocking.

    Signed-off-by: Dave Airlie <email address hidden>
    Reviewed-by: Daniel Vetter <email address hidden>
    Signed-off-by: Jani Nikula <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

:040000 040000 692369dcf6b67c2b69d16bffeba828431067b128 99ccabef6d1cb9b5092025a4670a2e00e92b87a7 M drivers

[penalvch (penalvch)]

crs, could you please provide the missing information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[crs (crs-s)]

Sure, you may take look at the file attached.

[crs (crs-s)]

Output of 'cat /proc/acpi/wakeup > wakeup' attached.

[penalvch (penalvch)]

crs, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (intel-gfx) by following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.

[crs (crs-s)]

http://lists.freedesktop.org/archives/intel-gfx/2015-July/072146.html