(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.
Have you tried with latest drm-tip: https://cgit.freedesktop.org/drm-tip?
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?
Hi, sure. See: https://01.org/linuxgraphics/documentation/build-guide-0
I have to pass this task on to someone with the necessary disk space and the suitable background. Sorry!
I resolve this now until tested and re-opened with drm-tip.
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?
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.
Uwe, Ping?
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).
Uwe, Can you attach dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Created attachment 141554 [details] dmesg with parameters as required
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.
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.
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.
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.
Uwe, can you upgrade to latest stable kernel (4.19) (if not drm-tip) and verify the issue.
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
Can you attach dmesg log from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Created attachment 142157 [details] As per request
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?
@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.)
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.
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.