Bug 101586 - [KBL] Constant display flicker after i915 is initialised (horizontal lines in graphics mode, flickering in tty)
Summary: [KBL] Constant display flicker after i915 is initialised (horizontal lines in...
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-25 16:29 UTC by René Seindal
Modified: 2018-04-20 16:33 UTC (History)
2 users (show)

See Also:
i915 platform: KBL
i915 features: display/Other


Attachments
dmesg output immediately after boot (56.79 KB, text/plain)
2017-06-25 16:29 UTC, René Seindal
no flags Details
Output of hwinfo immediately after boot (397.13 KB, text/plain)
2017-06-25 16:30 UTC, René Seindal
no flags Details
dmesg output with drm.debug=0x1e and log_buf_len=1M immediately after boot (191.43 KB, text/plain)
2017-06-26 18:34 UTC, René Seindal
no flags Details
dmesg output with drm.debug=0x1e and log_buf_len=1M immediately after boot, all i915 removed (139.39 KB, text/plain)
2017-07-04 20:00 UTC, René Seindal
no flags Details
dmesg output with drm.debug=0x1e and log_buf_len=1M (1012.85 KB, text/x-log)
2017-08-16 19:46 UTC, kxra
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description René Seindal 2017-06-25 16:29:53 UTC
Created attachment 132231 [details]
dmesg output immediately after boot

The computer is a g HP 250 G5 with (I think) a skylake or kabylake integrated graphics card.

The problem happens every time I boot the computer.  The grub (uefi) display is fine, and so is the first part of the boot messages, until at some point the display is reset and the flickering starts.

The flickering is both in graphics mode (gdm3 and after login) and in the console tty.

In graphics mode it takes the form of spurious horizontal lines starting about 1/4 to 1/2 from the left side of the display (never immediately from the left side).  Occasionally the entire image might make a small jump.

In the console it is more like flicker on an old style TV with the occasional image jump.

It is possible to use the computer but the effect is very disturbing.

I have tried to change many of the i915 module variables others have said fixed something, such as enable_fbc, enable_psr and enable_rc6, but to no effect.

The data attached was with these options:

options i915 modeset=1 enable_rc6=1 enable_fbc=1 enable_psr=1 disable_power_well=0 semaphores=1 enable_guc_loading=1 enable_guc_submission=1 
options i915 preliminary_hw_support=1 alpha_support=1
Comment 1 René Seindal 2017-06-25 16:30:38 UTC
Created attachment 132232 [details]
Output of hwinfo immediately after boot
Comment 2 René Seindal 2017-06-25 16:35:18 UTC
Forgot the obvious:

Linux 4.0.11 amd64 / x86_64
Debian testing
Kernel "linux-image-4.11.0-1-amd64" from Debian unstable


I use the computer for now with the i915 module removed, and it works but completely unaccellerated.
Comment 3 Jari Tahvanainen 2017-06-26 14:24:27 UTC
Please add drm.debug=0x1e on kernel command line options and provide dmesg and data from /sys/class/drm/card0/error if applicable. See https://01.org/linuxgraphics/documentation/how-report-bugs.
Comment 4 René Seindal 2017-06-26 18:34:00 UTC
Created attachment 132260 [details]
dmesg output with drm.debug=0x1e and log_buf_len=1M immediately after boot

The requested dmesg output is attached.

The /sys/class/drm/card0/error only gives: "no error state collected".
Comment 5 Jani Nikula 2017-07-04 12:28:13 UTC
(In reply to René Seindal from comment #0)
> The data attached was with these options:
> 
> options i915 modeset=1 enable_rc6=1 enable_fbc=1 enable_psr=1
> disable_power_well=0 semaphores=1 enable_guc_loading=1
> enable_guc_submission=1 
> options i915 preliminary_hw_support=1 alpha_support=1

Please remove *all* of them and try again.
Comment 6 René Seindal 2017-07-04 20:00:21 UTC
Created attachment 132443 [details]
dmesg output with drm.debug=0x1e and log_buf_len=1M immediately after boot, all i915 removed

Here's the requested output.

Just to make sure I've done the right thing, here are the steps I took.

- commented all lines in /etc/modprobe.d/i915
- update-initramfs -u -k 4.11.0-1-amd64
- reboot into kernel 4.11.0-1 with "drm.debug=0x1e max_buf_len=1M" added in grub
- switch to console, save output of dmesg to a file.
- reboot into older kernel where the i915 module is removed so I could write this.

Please let me know if I've done something wrong.

If it can help I can try to make a video of the display so you can see how it behaves.
Comment 7 Jani Nikula 2017-07-05 09:52:11 UTC
(In reply to René Seindal from comment #6)
> If it can help I can try to make a video of the display so you can see how
> it behaves.

So removing the extra i915 params didn't help? I was hoping it would have. But at least we now know more.

The video might prove helpful.
Comment 8 René Seindal 2017-07-06 16:29:06 UTC
(In reply to Jani Nikula from comment #7)

> The video might prove helpful.

I have tried to make a video here:

https://cloud.venicekayak.com/public.php?service=files&t=0ddd8634dc74304c9ce893a82380e602

I only discovered afterwards that I had the camera on a B&W profile, but it shouldn't make much of a difference here.
Comment 9 René Seindal 2017-07-06 19:08:48 UTC
(In reply to Jani Nikula from comment #7)
> (In reply to René Seindal from comment #6)
> > If it can help I can try to make a video of the display so you can see how
> > it behaves.
> 
> So removing the extra i915 params didn't help? I was hoping it would have.
> But at least we now know more.
> 
> The video might prove helpful.

I noticed something weird while making the video.

Apparently the flicker is more pronounced the more the laptop display is opened.

If I close the display to just before the point where it turns off, there doesn't seem to be much flicker, if any.  There's more with the display in a vertical position and much more with the display turned as far back as it will go without forcing anything.

It seems very odd to me, because it would indicate a hardware issue, cabling or whatever, but at the same time the display works perfectly before the i915 driver is loaded, as I hope can be seen from the video, and also if I use the computer as I am now, without the i915 driver loaded at all.
Comment 10 Ricardo 2017-07-11 13:40:07 UTC
added information, moving back to REOPENED
Comment 11 kxra 2017-08-16 19:46:54 UTC
Created attachment 133558 [details]
dmesg output with drm.debug=0x1e and log_buf_len=1M

adding dmesg and here is my lspci (having this issue on a lenovo yoga 910-13IKB running fedor 26 kernel 4.12.5

 ~]$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 02)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 02)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:15.3 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #3 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
Comment 12 Jari Tahvanainen 2018-02-05 11:45:26 UTC
I'm reaaaallly sorry about this delay on communication. There has been some flickering related fixes incorporated to codeline, so...
Rene - your symptoms are pointing to HW issue like you said, since lid move is involved. Is the problem still valid with the latest kernels (generated from drm-tip preferable) 
kxra- Is the problem still valid with the latest kernels (generated from drm-tip preferable)

Just wondering that dmesgs provided by both of you do not have any signal of "fail play" on the kernel, I would expect to see something....
Comment 13 Jani Saarinen 2018-03-29 07:11:49 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 14 Jani Saarinen 2018-04-20 14:15:40 UTC
Closing, please re-open if still occurs.
Comment 15 René Seindal 2018-04-20 16:33:39 UTC
(In reply to Jari Tahvanainen from comment #12)
> I'm reaaaallly sorry about this delay on communication. There has been some
> flickering related fixes incorporated to codeline, so...
> Rene - your symptoms are pointing to HW issue like you said, since lid move
> is involved. Is the problem still valid with the latest kernels (generated
> from drm-tip preferable) 
> kxra- Is the problem still valid with the latest kernels (generated from
> drm-tip preferable)
> 
> Just wondering that dmesgs provided by both of you do not have any signal of
> "fail play" on the kernel, I would expect to see something....


I will test it as soon as I can.

While it does seem to flicker more with the angle of the lid, there is no flicker whatsoever with Windows or with the framebuffer driver (I remove the i915.ko file and reboot), so it is not exclusively a hardware issue.  The hardware works without flicker with other drivers.

I have no chance of getting any kind of support for this issue on this computer, as there is no problem with windows.  For the vendor the computer works.  With the linux driver it doesn't (at least until now).


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.