Bug 98516

Summary:

[i915][SNB] black screen in X when resuming from suspend or hibernate

Product:

DRI

Reporter:

Erik Quaeghebeur <freedesktop>

Component:

DRM/Intel

Assignee:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Status:

CLOSED FIXED

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

major

Priority:

medium

CC:

intel-gfx-bugs

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

SNB

i915 features:

display/DP

Attachments:

Description	Flags
dmesg output after issue occurred	none

Description Erik Quaeghebeur 2016-10-31 11:23:34 UTC

Created attachment 127639 [details]
dmesg output after issue occurred

# System Information

Linux <hostname> 4.8.5-gentoo #1 SMP <datetime> 2016 x86_64 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel GNU/Linux

Manufacturer: LENOVO
Product Name: 4290W4H
Version: ThinkPad X220

Internal connector: LVDS
Connection to external displays: often DP (via docking station), sometimes VGA (directly)

# Problem description

Often, but not always (about half of the time, say), when resuming from suspend (to RAM) or hibernate (to disk), I get a black screen instead of the lock screen (X 1.18.4, SDDM 0.13.0, KWin 5.7.5). The mouse cursor is visible and can be moved and often I get a brief flash of the lock screen (or desktop?) before the screen turns black. Such brief flashes also sometimes occur when switching to a VT. VTs do work.

My impression is that it happens more often after I've disconnected from the DP display, if not upon the first sleep thereafter, then a subsequent one (without intermediate reboot).

I used to be able to reliably resume in the past, but since I upgraded from KDE4 to KDE5, many i915-related issues appeared. I'd read that this was known. After a number of updates both to KDE and the kernel version, many issues went away. This issue is the only remaining major one.

# Some information gathered

When switching to the console, a kernel message sometimes appears:

kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization

I started following the guide at https://01.org/linuxgraphics/documentation/how-report-bugs, so enabled the drm.debug=0x1e log_buf_len=1M options. I attach a resulting dmesg output; my impression is that due to the options, my dmesg is ‘filled’ with stuff that may not be relevant.

Also important to note is that since I activated the kernel options, I've had a different type of issue, which I think essentially locked my computer. The X screen had also turned black and drm-related messages appeared on a VT console I could change to (only one change was possible, I think, before thinks locked up even further).

# Request

I realize that I haven't followed all instructions at https://01.org/linuxgraphics/documentation/how-report-bugs, but I hope the information I provided is enough to get feedback on how to diagnose further.

Comment 1 Erik Quaeghebeur 2016-11-09 09:14:30 UTC

This bug is still present in kernel 4.8.6.

Comment 2 Erik Quaeghebeur 2016-11-29 07:38:40 UTC

This bug is still present in kernel 4.8.11.

Comment 3 Erik Quaeghebeur 2016-12-14 13:23:18 UTC

This bug is still present in kernel 4.8.13.

Comment 4 Erik Quaeghebeur 2016-12-16 07:12:57 UTC

Because I've read somewhere that this improves stability, I've disabled VT-d in the BIOS (I'm not using it) and set

    i915.enable_fbc=1
    i915.semaphores=1

Sadly enough, the issue still arises, so this didn't fix it.

Comment 5 Jani Nikula 2016-12-19 09:29:37 UTC

Please remove i915.enable_fbc=1 and i915.semaphores=1 module parameters, and try drm-tip branch of https://cgit.freedesktop.org/drm-tip

Comment 6 Erik Quaeghebeur 2016-12-19 22:10:48 UTC

(In reply to Jani Nikula from comment #5)
> Please remove i915.enable_fbc=1 and i915.semaphores=1 module parameters, and
> try drm-tip branch of https://cgit.freedesktop.org/drm-tip

I'll try to do that. Any page with info on how to combine with distribution-specific patches?

Also, FYI, the server is quite slow: after more than an hour I'm at 7% of the git clone. I'm on a ~2 MiB/s connection and I haven't gone over 100 KiB/s with this download.

Comment 7 Jani Nikula 2016-12-20 09:26:43 UTC

(In reply to Erik Quaeghebeur from comment #6)
> (In reply to Jani Nikula from comment #5)
> > Please remove i915.enable_fbc=1 and i915.semaphores=1 module parameters, and
> > try drm-tip branch of https://cgit.freedesktop.org/drm-tip
> 
> I'll try to do that. Any page with info on how to combine with
> distribution-specific patches?

In short, don't combine. Just try drm-tip with nothing on top, unless specifically asked.

> Also, FYI, the server is quite slow: after more than an hour I'm at 7% of
> the git clone. I'm on a ~2 MiB/s connection and I haven't gone over 100
> KiB/s with this download.

There are transient hickups like that I guess. Regardless of speed, what I usually do is clone Linus' tree, and add other trees as remotes. Git is smart enough to only download the delta from the remote.

Comment 8 Erik Quaeghebeur 2016-12-22 08:47:58 UTC

(In reply to Jani Nikula from comment #5)
> Please remove i915.enable_fbc=1 and i915.semaphores=1 module parameters, and
> try drm-tip branch of https://cgit.freedesktop.org/drm-tip

First experience:
* suspend-to-disk on the train
* dock (for external display/keyboard) and resume
=> hard locked desktop (pointer visible, rest is black, no response from keyboard or mouse); had to shutdown machine using physical on-off button; no mention of intel-driver related stuff in system logs around that time

I'll report back with more experiences as they come in.

Comment 9 Erik Quaeghebeur 2016-12-22 15:41:03 UTC

Second experience: after undocking, suspend-to-ram and resume worked as it should.

Third experience: suspend-to-disk results, after resuming, in a typical pointer-on-black screen, but after a while the desktop lock screen is shown. However, it is locked relatively hard (cannot change to console), but it can be killed with Ctrl-Alt-Backspace, after which the system recovers.

In the logs, I found a GPU HANG message, for which I'll file a new bug, as requested therein: Bug #99184.

Comment 10 Erik Quaeghebeur 2017-01-25 15:56:28 UTC

4.10.0-rc3+ namely drm-tip aa012aa081f6a6d2dd5a1df0f3c3736017df0d56

I still get:

jan 25 16:40:44 <hostname> kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
jan 25 16:40:44 <hostname> kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training

(failed to resume from hibernate, i.e., suspend-to-disk)

Comment 11 Ricardo 2017-02-24 17:36:50 UTC

information provided removing NEEDINFO status

Comment 12 Elizabeth 2017-07-25 17:27:19 UTC

(In reply to Erik Quaeghebeur from comment #10)
> 4.10.0-rc3+ namely drm-tip aa012aa081f6a6d2dd5a1df0f3c3736017df0d56
> 
> I still get:
> 
> jan 25 16:40:44 <hostname> kernel: [drm:intel_dp_start_link_train [i915]]
> *ERROR* failed to start channel equalization
> jan 25 16:40:44 <hostname> kernel: [drm:intel_dp_start_link_train [i915]]
> *ERROR* failed to enable link training
> 
> (failed to resume from hibernate, i.e., suspend-to-disk)

Hello Erik,
Still present on 4.12 and higher or/and latest drm-tip?
Thanks.

Comment 13 Erik Quaeghebeur 2017-07-25 19:12:45 UTC

(In reply to Elizabeth from comment #12)
> Still present on 4.12 and higher or/and latest drm-tip?

Haven't tried, I'm on 4.9.34 and the issue has either been fixed or become seldom enough to not be bothersome. Because of this, I am for now not going to investigate further. I think this bug may therefore be closed as long as I have the possibility of reopening with new info about a newer kernel.

Comment 14 Elizabeth 2017-07-25 20:20:42 UTC

(In reply to Erik Quaeghebeur from comment #13)
> (In reply to Elizabeth from comment #12)
> > Still present on 4.12 and higher or/and latest drm-tip?
> 
> Haven't tried, I'm on 4.9.34 and the issue has either been fixed or become
> seldom enough to not be bothersome. Because of this, I am for now not going
> to investigate further. I think this bug may therefore be closed as long as
> I have the possibility of reopening with new info about a newer kernel.
Thanks for the answer Erik,
In that case, I'll close the bug. If the problem appears again, you can mark as REOPEN and share the information.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.