Bug 101586

Created attachment 132232 [details]
Output of hwinfo immediately after boot

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.

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.

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".

(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.

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.

(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.

(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.

(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.

added information, moving back to REOPENED

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

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....

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.

Closing, please re-open if still occurs.

(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).