Bug 1119621 - kernel 4.19 + i915 gives black screen/intermittent display
kernel 4.19 + i915 gives black screen/intermittent display
Status: RESOLVED UPSTREAM
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 openSUSE Factory
: P5 - None : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-12-15 02:26 UTC by Tejas Guruswamy
Modified: 2020-01-14 10:09 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Packages installed on 12-18-2018 (16.40 KB, text/plain)
2018-12-20 16:25 UTC, Bill Wayson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tejas Guruswamy 2018-12-15 02:26:20 UTC
All 4.19 kernels I have tested (up-to-date Tumbleweed) have given only a flashing/intermittent display after bootloader on my laptop.
After GRUB instead of the splash screen, I see the manufacturer image from the UEFI again and then the display spends most of its time off. Sometimes hitting keys (or just randomly, perhaps something to do with screen refresh) brings the display back for a moment and reveals system has actually booted and is operational, just with no display.
Problem exists both on tty/console and in X (KDE), starting from the splash screen and continuing till reboot/shutdown.

Booting and running kernels from 4.18 series work fine, completely stable, with no changes in configuration. "Recovery mode" also gives a steady tty display.
No errors in Xorg.log or dmesg that I can spot.

> lsmod | grep i915
i915                 2064384  15
i2c_algo_bit           16384  1 i915
drm_kms_helper        196608  1 i915
drm                   471040  16 drm_kms_helper,i915
video                  45056  1 i915

Not sure which packages are relevant.
libvulkan_intel-18.1.7-208.1.x86_64
libdrm_intel1-2.4.96-1.1.x86_64
ucode-intel-20180807a-1.1.x86_64
intel-gpu-tools-1.23-2.1.x86_64
libdrm_intel1-32bit-2.4.96-1.1.x86_64
xf86-video-intel-2.99.917+git8674.25c9a2fcc-1.1.x86_64
intel-vaapi-driver-2.2.0-1.1.x86_64
xf86-video-intel-32bit-2.99.917+git8674.25c9a2fcc-1.1.x86_64
xorg-x11-driver-video-7.6_1-17.2.x86_64
libdrm2-2.4.96-1.1.x86_64
kernel-default-4.19.7-1.5.x86_64 (not working)
kernel-default-4.18.15-1.2.x86_64 (working)
kernel-default-4.19.5-1.5.x86_64 (not working)
kernel-firmware-20181026-1.1.noarch

> sudo /usr/sbin/lshw -c video -c cpu
  *-cpu                     
       description: CPU
       product: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
       vendor: Intel Corp.
       physical id: 1b
       bus info: cpu@0
       version: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
       serial: To Be Filled By O.E.M.
       slot: U3E1
       size: 1378MHz
       capacity: 4005MHz
       width: 64 bits
       clock: 100MHz
       capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d cpufreq
       configuration: cores=4 enabledcores=4 threads=8
  *-display
       description: VGA compatible controller
       product: UHD Graphics 620
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 07
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:127 memory:de000000-deffffff memory:c0000000-cfffffff ioport:f000(size=64) memory:c0000-dffff
Comment 1 Felix Miata 2018-12-15 09:24:02 UTC
You may be able to workaround this by removing the unofficially deprecated xf86-video-intel driver. I have no such problem with modesetting on Kaby Lake:

# inxi -bxx
System:    Host: gb250 Kernel: 4.19.7-1-default x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: IceWM 1.4.2 dm: XDM
           Distro: openSUSE Tumbleweed 20181213
Machine:   Type: Desktop System: Gigabyte product: B250M-D3H v: N/A serial: N/A
           Mobo: Gigabyte model: B250M-D3H-CF v: x.x serial: N/A UEFI: American Megatrends v: F9 date: 04/10/2018
CPU:       Dual Core: Intel Core i3-7100T type: MT MCP arch: Kaby Lake speed: 800 MHz min/max: 800/3400 MHz
Graphics:  Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel bus ID: 00:02.0
           chip ID: 8086:5912
           Display: server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa alternate: intel
           resolution: 1920x1200~60Hz
           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.1.7 compat-v: 3.0
           direct render: Yes
Info:      Processes: 173 Uptime: N/A Memory: 15.55 GiB used: 212.6 MiB (1.3%) Init: systemd v: 239 runlevel: 5
           target: multi-user.target Compilers: gcc: 8.2.1 alt: 8 Shell: bash v: 4.4.23 running in: xterm
           inxi: 3.0.28
Comment 2 Tejas Guruswamy 2018-12-16 03:43:55 UTC
(In reply to Felix Miata from comment #1)
> You may be able to workaround this by removing the unofficially deprecated
> xf86-video-intel driver. I have no such problem with modesetting on Kaby
> Lake:

I uninstalled xf86-video-intel{,-32bit}, then remade the initrd, but still the same result. 4.18 kernels work, and 4.19 kernels do not.

> inxi -bxx
System:    Host: hobbes Kernel: 4.18.15-1-default x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.14.4 
           tk: Qt 5.11.2 wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20181213 
Machine:   Type: Laptop System: PC Specialist product: N7x0WU v: N/A serial: <root required> Chassis: No Enclosure type: 10 
           serial: <root required> 
           Mobo: CLEVO model: N7x0WU serial: <root required> UEFI: American Megatrends v: 5.12 date: 11/28/2017 
Battery:   ID-1: BAT0 charge: 40.5 Wh condition: 41.2/43.8 Wh (94%) volts: 16.8/14.6 model: Notebook BAT serial: 0001 
           status: Charging 
CPU:       Quad Core: Intel Core i7-8550U type: MT MCP arch: Kaby Lake speed: 800 MHz min/max: 400/4000 MHz 
Graphics:  Device-1: Intel UHD Graphics 620 vendor: CLEVO/KAPOK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5917 
           Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa alternate: intel compositor: kwin_x11 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 18.1.7 compat-v: 3.0 
           direct render: Yes 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: CLEVO/KAPOK driver: r8169 v: 2.3LK-NAPI 
           port: e000 bus ID: 01:00.1 chip ID: 10ec:8168 
           Device-2: Intel Wireless-AC 9260 driver: iwlwifi v: kernel port: e000 bus ID: 02:00.0 chip ID: 8086:2526 
Drives:    Local Storage: total: 232.89 GiB used: 183.40 GiB (78.7%) 
Info:      Processes: 265 Uptime: N/A Memory: 7.67 GiB used: 1.73 GiB (22.5%) Init: systemd v: 239 runlevel: 5 
           target: runlevel5.target Compilers: gcc: 8.2.1 alt: 8 clang: 6.0.1 Shell: bash v: 4.4.23 running in: yakuake 
           inxi: 3.0.28
Comment 3 Takashi Iwai 2018-12-18 12:33:44 UTC
Could you check whether the problem still present in 4.20-rc kernel, e.g. the kernel package in OBS Kernel:HEAD repo?
If the issue still exists, we need to report to upstream.
Comment 4 Tejas Guruswamy 2018-12-20 01:04:17 UTC
Yep, issue still exists with kernel-default-4.20.rc7-1.1.g4731528.x86_64 from Kernel:HEAD .

The ratio of screen on to off time seems to vary boot-to-boot, but the repeatable indicator of this issue is that I see the UEFI image again after GRUB instead of the usual splash screen. (Some sort of gfx memory issue? I have no idea). This never happens under kernel 4.18 and always happens for >= 4.19 in my testing.
Comment 5 Bill Wayson 2018-12-20 16:25:52 UTC
Created attachment 793172 [details]
Packages installed on 12-18-2018

I believe my two Tumbleweed PCs are experiencing this issue (after logging in, jagged, moving dark horizontal areas - tearing?; intermittent flashing of partial desktop elements and icons; an unusable desktop; etc.).  Note that the problem occurs only after logging in.  The login screen is fine.

I am not sure the problem is with the kernel, at least exclusively.  I first experienced it after installing updates the afternoon of 12-18-2018 and rebooting.  By that time, I had run several versions of the 4.19 kernel with no problem.  Here is the order of their installation on one of my PCs:

4.19.2	2018-11-20
4.19.4	2018-11-27
4.19.5	2018-12-4
4.19.7	2018-12-11

Each of my two Tumbleweed PCs multiboots openSUSE Tumbleweed and Leap, and one includes Windows 7.  They keep the current and immediately preceeding kernel versions installed.  On one PC (I will not be able to test the other until tonight, at the earliest), the screen issue now occurs even when I boot into the 4.19.5 kernel.

The problem may be Plasma-related.  I normally use the out-of-the-box Plasma desktop.  This morning, I tried the Plasma (Wayland) desktop, and the screen was normal and stable -- there was no problem.  I am not familiar enough to know which logs to look in for any clues as to the root cause if the screen issue.  I have attached the portion of the /var/log/zypp/history file showing every package installed on one PC on 12-18-2018.  If you'd like me to check something specific, I am happy to do so.

I now see bug 1120090 Flickering screen since 20181214.  Perhaps these two bugs are the same.
Comment 6 David Rosky 2018-12-20 20:01:28 UTC
I've been debating whether to file a new bug report, but the issue I'm having is similar enough to this, that it could be a manifestation of the same problem, so I'll post some info here for now.

Symptoms:

1. Tumbleweed install can't bring up graphical installer on a new machine with a z390 chipset and i9-9900k and Intel graphics.  It falls back to text install, so I do a text install.

2. After text install, X won't start (I installed with default runlevel for console and then use "startx").

3. The quick summary:  The installer doesn't even install xf86-video-intel, so Xorg generates a "module not found" error, then falls back to Vesa, which hangs and fails.  I'm not sure why Vesa fails, but maybe it doesn't support the 4k mode or something.  I deleted the vesa driver, then X falls back to framebuffer, and X finally runs in the framebuffer, but horribly slow, far slower than either Ubuntu or Arch with framebuffer.

4. If I force install xf86-video-intel, the module is found, but it can't find a display: i915 seems to be having trouble connecting to the hardware.

5. Ubuntu 18.10 liveCD: same problem - falls back to framebuffer, but Ubuntu's framebuffer is significantly faster than Tumbleweed's.  Arch:  Same problem - X won't start, removing xf86-video-intel causes fallback to vesa, which fails. Removing vesa causes fallback to framebuffer, which works, at about the same speed as the Ubuntu framebuffer.

Some additional info:

This seems to be a known problem with an upstream fix in a weird place.  Check out this Arch bug report:

https://bbs.archlinux.org/viewtopic.php?id=242465

Someone referred the OP to a "drm-tip" kernel, which worked for the OP.  In Arch, there is a AUR packagebuild for this, and I tried it, and it worked on my system as well.  Here is the drm-tip project referred to in the thread:

https://github.com/freedesktop/drm-tip

This drm-tip kernel is based on 4.20-rc6, BUT, the 4.20-rc6 kernel in the OpenSuSE kernel:HEAD repository does not work for me.  The drm-tip kernel must have additional, bleeding-edge drm development code that works properly on newer processors and chipsets.

My suggestion is that if it is desired that Tumbleweed work on the newest hardware, the OpenSuSE kernel developers may want to look at the drm-tip kernel and backport whatever changes are necessary.

One more additional piece of info:  While the Ubuntu 18.10 liveCD does not work (it works, but falls back to framebuffer), the Ubuntu 19.04 BETA liveCD *does* work.  So far, that's been the only out-of-the-box version of either Ubuntu, OpenSuse, or Arch that has worked.  It seems the Ubuntu devs have possibly backported the necessary changes for a functional Intel graphics system.

NOTE: If this is determined to be a different issue, I would be happy to post this information into a new bug.
Comment 7 Tejas Guruswamy 2018-12-21 06:48:54 UTC
Testing further I do *not* experience the issue in IceWM or TWM. But again, I *do* see it in tty1-6 console, sddm, and in plasma.
Even more weird, it gets noticeably worse (screen spends more time off) when my laptop is on AC power and better when on battery. Some weird firmware/memory corruption issue? But I don't think it is an actual hardware problem, as the issue *never* occurs with 4.18.

Bill Wayson, David Rosky: I see complete screen blanking (not tearing), this occurs for me with all 4.19 kernels, and occurs on the console as well, outside of KDE/Plasma, so sounds like you both are describing something else.
David, note that xf86-video-intel is not recommended anymore (see earlier in this bug for example), the system should be using the "modesetting" driver instead. Works fine on my machine.
You could try installing http://download.opensuse.org/history/20181112/tumbleweed/repo/oss/x86_64/kernel-default-4.18.15-1.2.x86_64.rpm anyway to see if it helps. If it does not, I suggest opening a new bug.
Comment 8 David Rosky 2018-12-21 19:05:44 UTC
Tejas, thanks for the comment.  The older, 4.18 kernel did not improve things.

Also, the installer did not install xv86-video-intel, so it is apparently doing the right thing by not installing it.  The modesetting driver does get loaded, but X still cannot connect to the card.  It is starting to sound like this is a different issue, so I'll start a new bug.

Thanks..
Comment 9 Takashi Iwai 2019-01-02 10:33:49 UTC
Can anyone try to open a bug report on the upstream bugzilla.freedesktop.org?
Feel free to put me (tiwai@suse.de) to Cc, so that I can follow / help.  Thanks.
Comment 10 Tejas Guruswamy 2019-01-03 16:25:06 UTC
(In reply to Takashi Iwai from comment #9)
> Can anyone try to open a bug report on the upstream bugzilla.freedesktop.org?
> Feel free to put me (tiwai@suse.de) to Cc, so that I can follow / help. 
> Thanks.

Reported as https://bugs.freedesktop.org/show_bug.cgi?id=109215 and added you as cc, thanks.
Comment 11 David Rosky 2019-01-03 22:17:13 UTC
Since this seems to be kernel-related, and the only logged error you see is drm-related, it might be worth trying the development kernel from drm-tip.  In case you weren't following it (I opened a new bug), this ended up solving the problem I was having that I reported here a few comments back.  The symptoms are different, but it might be worth a try.  Besides addressing newer processors, it may be that some regressions were introduced in the DRM code that are just now getting cleared up.

After a bit of searching, the DRM development kernel turned out to be pretty easy to compile according to instructions in a post I found that is linked to in the bug I opened (which I've since closed):

https://bugzilla.opensuse.org/show_bug.cgi?id=1120254

-D
Comment 12 Bart Van Assche 2019-01-04 02:21:17 UTC
FWIW: there are two other bug reports reporting trouble with the kernel v4.19 + sddm combination.
Comment 13 Seppe hoogzaad 2019-01-06 19:24:21 UTC
I have (had) the same problem. Kernel 4.19 did boot, but no screen, just some flashes. No text or graphic screen. I did see the tumbleweed logo, but that was it. Also noting strange in the log files. 

I just had a new computer. Installing tumbleweed did not work because the kernel of the installer image did not boot properly. I therefore installed openSUSE Leap 15.0 first, then upgraded to tumbleweed. Then i got in the same problem like described here. I previous got the live tumbleweed image (version 20181224) working by setting the kernel option "xvideo=1920x180". This also resulted in flickering screens, but that was related to wayland, recording to the journal. So choosing Xorg would keep me out op those problems. I therefore was not expecting problems when upgrading to tumbleweed. 

I had the 4.12 kernel from Leap 15.0, which worked, so i have kept this to boot the system, which worked. I also booted the 4.19 kernel and uses ssh to log in remotely. This to find a difference in the log, but the only difference between a working kernel and 4.19 i found is below.
Kernel 4.12:
[    3.626842] [drm] Initialized i915 1.6.0 20171222 for 0000:00:02.0 on minor 0
[    4.426469] [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:58:eDP-1] Link Training failed at link rate = 270000, lane count = 2
Kernel 4.19:
[    3.393198] [drm] Initialized i915 1.6.0 20180719 for 0000:00:02.0 on minor 0
(note the different date on the i915)

Using the "xvideo=1920x180" kernel parameter was not recommended, so i did not tried this. I looked at this bug, since it described my problem. I just found that (for me) the option "i915.fastboot=1" solved my problem with the 4.19 kernel. It now boots properly, suspend works.

May be this can help some others.
 

Information about my machine, running the 4.19.11-1 kernel:

> inxi -bxx
System:
  Host: linux-6axq Kernel: 4.19.11-1-default x86_64 bits: 64 compiler: gcc 
  v: 8.2.1 Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 wm: xfwm4 dm: LightDM 
  Distro: openSUSE Tumbleweed 20181224 
Machine:
  Type: Desktop System: GOOGLE product: Lulu v: Pilot 
  serial: <root required> Chassis: type: 3 serial: <root required> 
  Mobo: N/A model: N/A serial: N/A BIOS: coreboot v: N/A date: 03/28/2016 
Battery:
  ID-1: BAT0 charge: 49.2 Wh condition: 70.0/67.0 Wh (104%) volts: 11.8/11.4 
  model: SMP-LIS DELL MJ serial: 0340 status: Discharging 
CPU:
  Dual Core: Intel Core i3-5005U type: MT MCP arch: Broadwell speed: 798 MHz 
  min/max: 500/2000 MHz 
Graphics:
  Device-1: Intel HD Graphics 5500 driver: i915 v: kernel bus ID: 00:02.0 
  chip ID: 8086:1616 
  Display: x11 server: X.Org 1.20.3 driver: intel 
  unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) 
  v: 4.5 Mesa 18.3.1 compat-v: 3.0 direct render: Yes 
Network:
  Device-1: Intel Wireless 7260 driver: iwlwifi v: kernel port: 1840 
  bus ID: 01:00.0 chip ID: 8086:08b1 
Drives:
  Local Storage: total: 111.79 GiB used: 9.58 GiB (8.6%) 
Info:
  Processes: 254 Uptime: 5h 33m Memory: 3.79 GiB used: 944.8 MiB (24.4%) 
  Init: systemd v: 239 runlevel: 5 target: graphical.target Compilers: 
  gcc: N/A Shell: bash v: 4.4.23 running in: xfce4-terminal inxi: 3.0.29
Comment 14 Takashi Iwai 2019-01-19 09:58:50 UTC
The boot logo carried from EFI is the intentional behavior, BTW.
This is a new feature for "flicker-less" boot on the recent kernel, enabled via CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER option.

Might this have some negative effect?  This needs to be checked, perhaps...
Comment 15 Seppe hoogzaad 2019-01-19 13:51:41 UTC
(In reply to Takashi Iwai from comment #14)
> The boot logo carried from EFI is the intentional behavior, BTW.
> This is a new feature for "flicker-less" boot on the recent kernel, enabled
> via CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER option.
> 
> Might this have some negative effect?  This needs to be checked, perhaps...



Yesterday i tried the drm-tip kernel. This is without the CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER option.

> git clone git://anongit.freedesktop.org/drm-tip
> make defconfig
> make
> sudo make modules_install
> sudo make install

This is with kernel version 5.0.0, r2. The problem was the same, like in the 4.20.3 kernel. With "i915.fastboot=1" booting correct. Without this kernel parameter: no screen, just some flickering. I also found that the following commands gave the same flickering screen from which i can not recover in an normal way:
> xset dpms force off
> xset dpms force standby
> xset dpms force suspend

Maybe this is related, since it gives the same effect.

I will report these two bugs (booting and the xset) also at:
https://01.org/linuxgraphics/documentation/how-report-bugs
I will do this later and include a video of the screen. I will refer to this report also. 


Note that none of this does happen with the 4.12.14 kernel from Opensuse Leap 15.0.
Comment 16 Seppe hoogzaad 2019-01-20 11:20:49 UTC
I have made two bug reports.

Booting gives black screen with flickering. No recovery possible:
https://bugs.freedesktop.org/show_bug.cgi?id=109398

Xset dpms forces off gives black flickering screen:
https://bugs.freedesktop.org/show_bug.cgi?id=109399
Comment 17 Tejas Guruswamy 2019-01-22 01:29:44 UTC
(In reply to Takashi Iwai from comment #14)
> The boot logo carried from EFI is the intentional behavior, BTW.
> This is a new feature for "flicker-less" boot on the recent kernel, enabled
> via CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER option.

Ugh, mine is ugly! But ok, thanks, I guess that is a red herring then.
(based on this hint I found "fbcon=nodefer" restores the old behaviour)

(In reply to sep hoogzaad from comment #15)
> This is with kernel version 5.0.0, r2. The problem was the same, like in the 
> 4.20.3 kernel. With "i915.fastboot=1" booting correct. Without this kernel 
> parameter: no screen, just some flickering.

"i915.fastboot=1" indeed fixes the black screen/flickering problem on 4.20 and 5.0rc, thank you for the suggestion. I will pass this info on to my upstream bug (https://bugs.freedesktop.org/show_bug.cgi?id=109215). Any advice on providing more useful logs would be appreciated. Still don't see any errors in the expected places.
Comment 18 Seppe hoogzaad 2019-01-22 19:32:14 UTC
I saw David write: "(I opened a new bug), this ended up solving the problem I was having that I reported here a few comments back." 

I therefore thought the problem was solved, while this was not the case for me. I missed there was an other report, which looks similar ans is still not solved.  


About log information: information about providing useful logs can be found below: 
https://01.org/linuxgraphics/documentation/bugs-and-debugging/how-get-kernel-backtrace
and
https://01.org/linuxgraphics/documentation/how-get-gpu-error-state


I found no error anywhere in any log or kernel output. In de dmesg i can see a loop which tries to get the GPU running, but keeps failing. This loop causes flashing of the screen (i assume). I can't see at what point is fails. Else this would be a good place to start digging.
Comment 19 David Rosky 2019-01-23 17:20:10 UTC
I may not have stated things clearly, but the suggestion to try the drm-tip kernel was only a "shot in the dark", so to speak, something easy to try. The latest DRM development code had solved the problem with DRM failing to connect with the i915 driver on Intel's newest chips, but apparently not this problem.
Comment 20 Seppe hoogzaad 2019-01-26 09:14:02 UTC
solution (on the mainline kernel of any kernel later than 4.19.2):
git revert 49218c83e25b6f0708f246b07d570b2c43a98223

The problem is caused by the commit 49218c83e25b6f0708f246b07d570b2c43a98223
"drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode".

I have not dig into this code, but only tried if reverting helps. It does. The problem is gone without this commit.

I have reported this solution also on the two bug-reports i made:
Booting problem:
https://bugs.freedesktop.org/show_bug.cgi?id=109398

xset dpms force off:
https://bugs.freedesktop.org/show_bug.cgi?id=109399

Both bugs are solved by reverting this commit 49218c8 introduced with the release of kernel 4.19.3.

Now hoping that someone will revert this commit or change the code so it works properly....


@David. Thanks for pointing me to the development kernel from drm-tip!
Comment 21 Takashi Iwai 2019-01-27 09:25:43 UTC
Thanks, this is a really helpful information!

I'm building a test kernel that reverts the suggested commit on top of the latest stable kernel now.  It's being built in OBS home:tiwai:bsc1119621 repo, and will appear at:
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1119621/standard/

Can people test it later and see whether it really covers all this reported cases, not only for Sep's machine?
Comment 22 David Rosky 2019-01-27 17:27:31 UTC
Takashi,  will that also include backporting of whatever changes have been made in the DRM development kernel (drm-tip) which solved the other problem, involving DRM not connecting with the i915 driver (could not open /dev/dri/card0, bug 1120254)?  If so, I will try it too.  I closed that bug with RESOLVED UPSTREAM, but I'm not sure when work done in drm-tip gets merged into the mainstream kernel and then appear in OpenSuSE kernel builds..
Comment 23 Takashi Iwai 2019-01-27 19:36:14 UTC
(In reply to David Rosky from comment #22)
> Takashi,  will that also include backporting of whatever changes have been
> made in the DRM development kernel (drm-tip) which solved the other problem,
> involving DRM not connecting with the i915 driver (could not open
> /dev/dri/card0, bug 1120254)?  If so, I will try it too.  I closed that bug
> with RESOLVED UPSTREAM, but I'm not sure when work done in drm-tip gets
> merged into the mainstream kernel and then appear in OpenSuSE kernel builds..

Your problem sounds likely different, maybe some mixed up.

Here we're tracking a regression that happened in 4.20 (and 4.19.y stable) for i915, and I'm asking people to test the kernel to see whether we're chasing a single bug or not.

So, it's still helpful if you can test the kernel, too, but better not to expect too much :)
Comment 24 Tejas Guruswamy 2019-02-10 22:35:00 UTC
(In reply to Takashi Iwai from comment #21)
> Thanks, this is a really helpful information!
> 
> I'm building a test kernel that reverts the suggested commit on top of the
> latest stable kernel now.  It's being built in OBS home:tiwai:bsc1119621
> repo, and will appear at:
>   http://download.opensuse.org/repositories/home:/tiwai:/bsc1119621/standard/
> 
> Can people test it later and see whether it really covers all this reported
> cases, not only for Sep's machine?

I finally had a chance to test again. Summary is unfortunately kernel-default-4.20.5-1.1.ge544b4e.x86_64 from home:tiwai did not fix my problem. i915.fastboot=1 still works though.

I have rechecked the following kernels:
drm-tip (5.0-rc3)
5.0-rc5
4.20.6
4.20.5 from home:tiwai
4.18.15

For all kernels after 4.18.15, only if /sys/module/i915/parameters/fastboot=Y do I get a stable display. Note that fastboot=Y appears to be the default in 4.20.6 and drm-tip.
Comment 25 Takashi Iwai 2019-02-11 09:20:55 UTC
(In reply to Tejas Guruswamy from comment #24)
> I finally had a chance to test again. Summary is unfortunately
> kernel-default-4.20.5-1.1.ge544b4e.x86_64 from home:tiwai did not fix my
> problem. i915.fastboot=1 still works though.

Thanks for testing.  That's what I was afraid of :-<
So apparently we're looking at multiple issues.

> Note that
> fastboot=Y appears to be the default in 4.20.6 and drm-tip.

Really?  I couldn't find anything that changed the default in the kernel source.

In theory we can flip fastboot=y as default.  It's been disabled due to the regression seen on a Chromebook with some funky firmware.
But it's no right "fix", and the option can be given easily via boot option, let's try to track the right cause for now.
Comment 26 Tejas Guruswamy 2019-03-02 05:25:26 UTC
(In reply to Takashi Iwai from comment #25)
> (In reply to Tejas Guruswamy from comment #24)
> > I finally had a chance to test again. Summary is unfortunately
> > kernel-default-4.20.5-1.1.ge544b4e.x86_64 from home:tiwai did not fix my
> > problem. i915.fastboot=1 still works though.
> 
> Thanks for testing.  That's what I was afraid of :-<
> So apparently we're looking at multiple issues.
> 
> > Note that
> > fastboot=Y appears to be the default in 4.20.6 and drm-tip.
> 
> Really?  I couldn't find anything that changed the default in the kernel
> source.

Sorry, this may have just been a side effect of running drm-tip.
 
> In theory we can flip fastboot=y as default.  It's been disabled due to the
> regression seen on a Chromebook with some funky firmware.
> But it's no right "fix", and the option can be given easily via boot option,
> let's try to track the right cause for now.

Progress at last! I found the same, or at least very similar, issue filed at Arch (https://bugs.archlinux.org/task/60841) and it turns out intel_idle.max_cstate=4 fixes my issue more reliably than i915.fastboot=1.

Not clear why cpu c-states are affecting the gpu but the root bug may in fact be this one:
https://bugs.freedesktop.org/show_bug.cgi?id=103229

This issue has turned up on many Skylake systems with different possible causes but the same symptoms (flickering/black screen) and workaround (reduce max cstate from 9 to 4).
https://bugs.freedesktop.org/buglist.cgi?quicksearch=SKL%20flicker%20underrun&list_id=667366
Comment 27 Seppe hoogzaad 2019-03-05 21:38:22 UTC
(In reply to Tejas Guruswamy from comment #26)

Thanks for the suggestion.

We already concluded that your issue is different from mine. I did try the intel_idle.max_cstate=4 kernel parameter, but, as expected, with no success.

I accidentally found that updating/replacing the BIOS, did solve my problem also,  apart from the "git revert 49218c83e25b6f0708f246b07d570b2c43a98223" solution.

details are in: https://bugs.freedesktop.org/show_bug.cgi?id=109398

Since i do not have any problems anymore and, as we later found out, having an other problem anyway, i will leave.

It was funny. The comments in this post set me thinking that the problem i/we had, could be caused by a recent kernel change. This appeared to be true. But even all the symptoms were the same, the cause was something else. Bugs appear to walk in strange ways. 

Good luck with yours!
Comment 28 Jiri Slaby 2019-04-15 10:41:14 UTC
So the issue is fixed by this commit:
commit 21635d7311734d2d1b177f8a95e2f9386174b76d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 5 10:52:20 2019 +0300

    drm/i915/dp: revert back to max link rate and lane count on eDP

I assume?

If not, please reopen.
Comment 29 Tejas Guruswamy 2019-04-19 00:52:09 UTC
(In reply to Jiri Slaby from comment #28)
> So the issue is fixed by this commit:
> commit 21635d7311734d2d1b177f8a95e2f9386174b76d
> Author: Jani Nikula <jani.nikula@intel.com>
> Date:   Fri Apr 5 10:52:20 2019 +0300
> 
>     drm/i915/dp: revert back to max link rate and lane count on eDP
> 
> I assume?
> 
> If not, please reopen.

No, unfortunately this is a different bug. It started in 4.19 most likely because of a99790bf5c7f3d68d8b01e015d3212a98ee7bd57 : r8169: Reinstate ASPM Support
and I can still reproduce on 5.1-rc5 with fastboot=0 and max_cstate=9.
Comment 30 Miroslav Beneš 2020-01-14 10:09:14 UTC
Meanwhile, TW moved to 5.4 kernel version. All referenced upstream bug reports are resolved for a while, so closing. If the issue persists nevertheless, please reopen.