Bug 106017 - Flickering screen with Intel graphics from specific kernel version onwards (4.2)
Summary: Flickering screen with Intel graphics from specific kernel version onwards (4.2)
Status: RESOLVED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-12 18:43 UTC by Uwe Dippel
Modified: 2019-06-04 10:46 UTC (History)
4 users (show)

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


Attachments
dmesg with parameters as required (3.93 MB, text/plain)
2018-09-13 18:23 UTC, Uwe Dippel
no flags Details
dmesg debug as requested (952.76 KB, text/plain)
2018-10-21 20:20 UTC, Uwe Dippel
no flags Details
As per request (1.01 MB, text/plain)
2018-10-23 17:13 UTC, Uwe Dippel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Dippel 2018-04-12 18:43:04 UTC
(Cited from https://askubuntu.com/questions/927407/flickering-screen-with-intel-graphics-on-ubuntu-17-04:)

The screen is flickering, going black for extended periods of time (~10 seconds) as well as "hot pixels" on the home screen and in some applications. The system is an Intel Skylake integrated graphics (HD 510) with no other graphics card that could be interfering.

The problem goes away if I either reduce the resolution (to 1080i or lower) or the refresh rate (from 60Hz to 30Hz).

Summary of things I have (unsuccessfully) tried so far:

creating config script for the X server as suggested, among others, on the Arch wiki. This seems to be the go to advice for this sort of problem, but unfortunately it hasn't helped me.

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    Option "AccelMethod" "sna"
    Option "TearFree" "true"
    Option "DRI" "3"
EndSection
I also tried this with AccelMethod uxa and it didn't help.

Enabling the intel microcode proprietary driver

nomodeset and i915.modeset=0 kernel parameters. This just limits my resolution to 1024x768 (or maybe it was 1280x1024, but either one isn't satisfactory)
i915.preliminary_hw_support=1, i915.enable_rc6=0, i915.enable_psr=0 kernel parameters
acpi=off kernel parameter
Upgrading drivers through the Intel graphics update tool as well as from this website (latest versions at the time of this writing: GuC - Ver 6.1, DMC - Ver 1.26, HuC - Ver 1.07)
Upgrading kernel to 4.11 and 4.12rc5, which has only seemed to make matters worse
apt-get purge xserver-xorg-video-intel, which hasn't helped, as well as a reinstall
Installing intel-vaapi-driver (from launchpad)
Different distros (Lubuntu 16.04.2, Lubuntu 17.04, Ubuntu 17.04, Fedora 25), they all have the same problem. Update: So does the recently released Lubuntu 17.10 (kernel 4.13.0-16)
Increasing the initially allocated memory to 1024MB in the BIOS
Enabling CSM in the BIOS
Setting the intel_iommu kernel parameter to off or igfx_off
Running stock Ubuntu 17.10. I thought maybe it was an X11 issue, and using Wayland might work. It didn't, although the exact symptoms changed slightly
Replacing the i915.ko file in the kernel's drivers directory with the working one from the 15.10 install. Somewhat surprisingly, this does not work. I had been halfway sure it would.

(Cited from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1712508:)

I have two Lenovo T410s that I upgraded from 14.04 to 16.04.
Since then, one is working fine while the other shows mainly an ever disappearing screen and flickering.

I think that I can help with this problem, since my two T410s are identical in hard- and software, including BIOS, except that one is a type 2924 (with NVIDIA-card, though disabled in the BIOS), and the other one is a 2904 (without NVIDIA card).

I have checked for differences at boot time and found DMAR as major difference:
T410s, 2924: [ 0.335616] DMAR: Disabling batched IOTLB flush on Ironlake
T410s, 2904: [ 0.355681] DMAR: BIOS has allocated no shadow GTT; disabling IOMMU for graphics

The outputs of lspci -k | grep -EA3 'VGA|3D|Display' are identical to the point.


As requested, the upstream kernel was tried, and exposed the same problem.

Also, with the reinstallation of an older kernel 3.x in that same machine, this problem does not exist. Therefore it should be considered a regression.
Comment 1 Jani Saarinen 2018-04-25 14:23:25 UTC
Have you tried with latest drm-tip: https://cgit.freedesktop.org/drm-tip?
Comment 2 Uwe Dippel 2018-04-25 14:54:16 UTC
Could you point out how the uninitiated can do that test, please? 
When will it appear in a kernel - and in which - to be tried?
Comment 3 Jani Saarinen 2018-05-04 12:44:38 UTC
Hi, sure.
See: https://01.org/linuxgraphics/documentation/build-guide-0
Comment 4 Uwe Dippel 2018-05-05 16:39:17 UTC
I have to pass this task on to someone with the necessary disk space and the suitable background. 
Sorry!
Comment 5 Jani Saarinen 2018-05-17 09:59:14 UTC
I resolve this now until tested and re-opened with drm-tip.
Comment 6 Uwe Dippel 2018-08-16 10:00:00 UTC
I allow myself to reopen the bug, since I installed (k)ubuntu 18.04 yesterday and the behaviour is identically unchanged, with a normally unusable full HD screen.

https://bugs.freedesktop.org/show_bug.cgi?id=106017#c5 wrote "I resolve this now until tested and re-opened with drm-tip." 
Sorry, I don't understand that 'drm-tip'. I would still like to helpout, and get this problem solved. What do I have to do?
Comment 7 Jani Saarinen 2018-08-16 10:02:53 UTC
drm-tip is our pre-upstream kernel tree. 

As i have asked earlier: Have you tried with latest drm-tip: https://cgit.freedesktop.org/drm-tip?

Now it is already on 4.18 so please try that and report back.
Comment 8 Lakshmi 2018-09-11 08:02:02 UTC
Uwe, Ping?
Comment 9 Uwe Dippel 2018-09-11 09:06:54 UTC
Lakshmi,

thanks, and sorry, I don't get what you mean. 
Yes, I'm here ('ping'); yes, the problem prevails, and no, I have no abilities and neither the disk space to try a 'latest drm-tip'.

However, I could refer to another bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790354
which did not happen in ubuntu 16.04 and compounds the underlying bug here: At boot, about 1 out of 8 cases doesn't give me a usable screen, since the start frequency of horizontal refresh seems to be arbitrarily chosen. Since it is always the same unaltered setting of a basically built-in machine, this behaviour is inexplicable to me (always starting from cold boot). 
And with the horizontal refresh not being stored, not even within the same session let alone across boots, the situation has gone from bad to worse on my side.
I dared to point to this bug, since the person on that end also wanted me to recompile the kernel for this storage-of-settings-bug. Which to me, the amateur, sounds fake. 

I'm most happy you look into this matter, and will help with whatever I can (which is quite limited, though).
Comment 10 Lakshmi 2018-09-12 20:02:37 UTC
Uwe, Can you attach dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Comment 11 Uwe Dippel 2018-09-13 18:23:46 UTC
Created attachment 141554 [details]
dmesg with parameters as required
Comment 12 Lakshmi 2018-09-17 14:25:58 UTC
Uwe, I would request you to verify the issue with the latest drmtip (recommended)/or kernel. If issue exists, logs from that will speed up the investigation.
Comment 13 Uwe Dippel 2018-09-17 14:35:48 UTC
That's fine, but not possible on my side. 
I have neither the expertise to recompile nor the disk space.

Anything else, I'll be more than pleased to help out.
Comment 14 Lakshmi 2018-10-21 18:01:24 UTC
Uwe, Need the logs from latest kernel with kernel parameters drm.debug=0x1e log_buf_len=4M from boot.

Dmesg from latest kernel is needed for investigation.

Reducing the priority to medium.
Comment 15 Uwe Dippel 2018-10-21 20:20:53 UTC
Created attachment 142122 [details]
dmesg debug as requested

This is the dmesg in debug mode of the most recent *buntu-Kernel. That's the best I can do.
Comment 16 Lakshmi 2018-10-22 13:12:28 UTC
Uwe, can you upgrade to latest stable kernel (4.19) (if not drm-tip) and verify the issue.
Comment 17 Uwe Dippel 2018-10-22 16:46:03 UTC
Okay, taken from Ubuntu:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2018-10-21/

$ uname -sr
Linux 4.19.0-994-generic

Behaviour is identical to before, that is flickering prevails.
However, the test is also flawed, due to 
'possible missing firmware /lib/firmware/i915/xyz-dmc-ver_1_07.bin
(xyz: I don't know, only noted and couldn't read my handwriting properly afterwards, sorry)

Still hope, this helps,

Uwe
Comment 18 Lakshmi 2018-10-23 08:22:41 UTC
Can you attach dmesg log from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Comment 19 Uwe Dippel 2018-10-23 17:13:59 UTC
Created attachment 142157 [details]
As per request
Comment 20 Lakshmi 2019-02-26 09:40:35 UTC
Attached logs from kernel 4.19 shows
[drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110

Is this issue related to Bug 108529? Swati, what's your opinion?
Comment 21 Uwe Dippel 2019-02-27 21:14:15 UTC
@Lakshmi,

I run into another problem with Intel drivers, this time 5300 on lenovo Helix 2.
Please refer to 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817944

Here, if you check the logs, it's another clear case of 'giving up'. In this case however, it seems to wait for EDID, and after showing the screen for some time, it starts by looking not synchronized, and in the end I'm stuck with a black display. 
Remarkable the output of xrandr, which tried hard, successfully in the beginning, shows some ridiculous results later, and finally considers the display 'not connected'; while I don't do anything, don't touch anything. Some time later it starts trying again.

I wonder if I should file this as a bug here under Freedesktop as well? 

(Yes, I do know I should try with the most recent kernel version, too. I will do so in one of the next days, after having read up (again) how I did it last time. I do take bets, however, that it doesn't make any difference. I rather think some bug will be found one day that explains all those unexplained 'giving up's, while the W10 driver on just the other half of the hard disk performs properly after a reboot.)
Comment 22 Uwe Dippel 2019-03-08 20:29:56 UTC
While I think that #21 might be resolved, w.r.t. the original problem, after almost half a year of no visible activity to get it working, I have given up, and sold that machine (lenovo T410s) for good. 

While I still hope that Intel can continue working on this issue, I won't be available any longer for testing due to the lack of hardware showing this problem.
Comment 23 Lakshmi 2019-06-04 10:46:40 UTC
Uwe, thanks for the geedback.
To investigate further with this bug we need dmesg from latest drmtip. Closing this bug as you can not reproduce this issue anymore. 

If the same issue is seen on similar platform please verify the issue with latest drmtip. If issue persists with drmtip, attach dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M and reopen the issue.


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.