Bug 109215 - intermittent display on kaby lake/i915 from kernel 4.19 onwards
Summary: intermittent display on kaby lake/i915 from kernel 4.19 onwards
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-03 16:19 UTC by masterpatricko
Modified: 2019-07-13 17:30 UTC (History)
4 users (show)

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


Attachments
Dmesg with fastboot off, intermittent display (717.00 KB, text/x-log)
2019-01-27 04:08 UTC, masterpatricko
no flags Details
output of intel_watermark without intel_idle.max_cstate=4 (during black/flickering screen) (5.61 KB, text/plain)
2019-04-04 01:35 UTC, masterpatricko
no flags Details
output of intel_watermark with intel_idle.max_cstate=4 (issue not present) (5.61 KB, text/plain)
2019-04-04 01:35 UTC, masterpatricko
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description masterpatricko 2019-01-03 16:19:47 UTC
Kernels 4.19 onwards (most recent test with kernel-default-4.20.rc7-1.1.g4731528.x86_64) consistently exhibit the following on my laptop (Kaby Lake/Intel i7-8550U/UHD 620):

* After bootloader, system manufacturer image from UEFI is displayed again instead of splash screen

* After bootloader, display is intermittent (sometimes completely black, sometimes working), usually switching in bursts a few times a second, then stable for a few seconds
  This occurs on console, SDDM, kwin_x11, kwin_wayland, but NOT with IceWM or TWM.
  Switching from working TWM/IceWM to vt1 (or similar) doesn't work
  Ratio of screen working to black is better on battery, worse on AC power
  Underlying system is functional the entire time

Both of these issues are never observed under kernel 4.18 or previous, with no configuration changes.

No obvious errors in /var/log/messages or Xorg. Dmesg looks normal except (on >kernel 4.19) for one instance per boot of
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

kernel-default-4.20.rc7-1.1.g4731528.x86_64 (not working)
> dmesg | grep -E 'intel|i915|drm'
[    2.715201] intel_idle: MWAIT substates: 0x11142120
[    2.715202] intel_idle: v0.4.1 model 0x8E
[    2.715901] intel_idle: lapic_timer_reliable_states 0xffffffff
[    2.742959] intel_pstate: Intel P-state driver initializing
[    2.743643] intel_pstate: HWP enabled
[    2.764581] intel_pmc_core:  initialized
[    4.636640] fb0: switching to inteldrmfb from EFI VGA
[    4.636755] [drm] Replacing VGA console driver
[    4.638002] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    4.638003] [drm] Driver supports precise vblank timestamp query.
[    4.638755] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    4.639090] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    4.932886] [drm] Initialized i915 1.6.0 20180921 for 0000:00:02.0 on minor 0
[    4.943550] fbcon: inteldrmfb (fb0) is primary device
[    4.943553] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    5.768688] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    5.902718] intel_rapl: Found RAPL domain package
[    5.902720] intel_rapl: Found RAPL domain core
[    5.902721] intel_rapl: Found RAPL domain uncore
[    5.902722] intel_rapl: Found RAPL domain dram
[    6.143342] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   11.070529] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

kernel 4.18 (working) dmesg is similar except for version string and no underrun error:
[    5.074997] [drm] Initialized i915 1.6.0 20180514 for 0000:00:02.0 on minor 0



System:    Host: hobbes.site 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.12.0 wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20181224
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.3.1 compat-v: 3.0 
           direct render: Yes 


previously discussed at https://bugzilla.opensuse.org/show_bug.cgi?id=1119621
Comment 1 masterpatricko 2019-01-22 01:33:43 UTC
I now understand the UEFI image is intended, and not related to the main issue (old behaviour can be restored with fbcon=nodefer).

Main issue (black screen/flickering) still exists on 5.0.0-rc2 if no extra boot options are provided.

Adding i915.fastboot=1 fixes the problem. Not clear how to isolate the issue further.
Comment 2 masterpatricko 2019-01-22 01:40:52 UTC
(In reply to masterpatricko from comment #1)
> I now understand the UEFI image is intended, and not related to the main
> issue (old behaviour can be restored with fbcon=nodefer).
> 
> Main issue (black screen/flickering) still exists on 5.0.0-rc2 if no extra
> boot options are provided.
> 
> Adding i915.fastboot=1 fixes the problem. Not clear how to isolate the issue
> further.

To be clear "fbon=nodefer" alone does *not* fix the problem; i915.fastboot=1 is required (works with or without fbcon=nodefer).
Comment 3 Felix Miata 2019-01-22 02:55:56 UTC
Could another workaround be disabling the manufacturer's GUI splash screen? I have B250 Kaby Lake Asus and Biostar UEFI motherboards, each with Tumbleweed and Buster, and have yet to experience this complaint. The only times I see a BIOS splash on my own hardware is when brand new out of the box, or when I forgot to turn it back off after a BIOS reset. I don't have Plymouth installed either.
Comment 4 James Ausmus 2019-01-22 23:15:44 UTC
Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.


Build instructions: https://01.org/linuxgraphics/documentation/build-guide-0
Comment 5 masterpatricko 2019-01-27 04:08:30 UTC
Created attachment 143233 [details]
Dmesg with fastboot off, intermittent display
Comment 6 masterpatricko 2019-01-27 04:14:32 UTC
I am able to reproduce with 5.0-rc3 drm-tip from git 08f37be937e0f3c2904d4250b0858e9ea9d72623 .
i915.fastboot=1 gives stable (within observation time) display, while i915.fastboot=0 exhibits intermittent display. 
Kernel 4.18 is still working in all cases.
Also seems dependent on whether the system is on AC power, on battery the display is mostly working with only occasional blanking, while on AC the display is mostly black with only very occasional moments showing the system is actually working.

Previous attachment is dmesg shortly after booting 5.0-rc3 from drm-tip (and with drm.debug=0x1e log_buf_len=4M) with fastboot=0. The problem was occurring as this log was saved.

Issue is quite reproducible so let me know if more logs (or "good" logs with fastboot=1) would help.
Comment 7 Lakshmi 2019-02-22 08:49:29 UTC
Ville, I see FIFO underrun from the log. Can you help here?
Comment 8 Ville Syrjala 2019-03-01 18:54:44 UTC
Is there a BIOS update available for this machine? Looks like some kind of oddball "PC specialist" machine. I couldn't immediately find any BIOS page for such things.
Comment 9 masterpatricko 2019-03-02 05:18:35 UTC
PCSpecialist is just a reseller for Clevo laptops, this is a Clevo N750WU. I have not found any BIOS updates.

I recently found the following filed in Arch -- https://bugs.archlinux.org/task/60841 -- which triggered me to try booting with intel_idle.max_cstate=4 .
This fixes my issue on kernels > 4.18 

Therefore this bug *may* be another variant of https://bugs.freedesktop.org/show_bug.cgi?id=103229 .
Comment 10 umesh 2019-03-11 18:31:24 UTC
I tried to reproduce the issue on Kaby Lake, but not able to reproduce it.
Comment 11 Ville Syrjala 2019-03-11 19:45:03 UTC
(In reply to masterpatricko from comment #6)
> I am able to reproduce with 5.0-rc3 drm-tip from git
> 08f37be937e0f3c2904d4250b0858e9ea9d72623 .
> i915.fastboot=1 gives stable (within observation time) display, while
> i915.fastboot=0 exhibits intermittent display. 
> Kernel 4.18 is still working in all cases.
> Also seems dependent on whether the system is on AC power, on battery the
> display is mostly working with only occasional blanking, while on AC the
> display is mostly black with only very occasional moments showing the system
> is actually working.
> 
> Previous attachment is dmesg shortly after booting 5.0-rc3 from drm-tip (and
> with drm.debug=0x1e log_buf_len=4M) with fastboot=0. The problem was
> occurring as this log was saved.
> 
> Issue is quite reproducible so let me know if more logs (or "good" logs with
> fastboot=1) would help.

Output from intel_watermark (from git://anongit.freedesktop.org/xorg/app/intel-gpu-tools) for the fastboot=0 flickering case and the fastboot=1 non-flickering case would be nice.
Comment 12 masterpatricko 2019-04-04 01:34:05 UTC
(In reply to Ville Syrjala from comment #11)
> 
> Output from intel_watermark (from
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools) for the fastboot=0
> flickering case and the fastboot=1 non-flickering case would be nice.

As mentioned in comment#9 I found my issue is actually better solved with intel_idle.max_cstate=4.

I have saved the output of watermark with and without (during the black screen/flickering), please see the latest attachments.

Tested with kernel 5.0.5-1-default from openSUSE.
Comment 13 masterpatricko 2019-04-04 01:35:22 UTC
Created attachment 143858 [details]
output of intel_watermark without intel_idle.max_cstate=4 (during black/flickering screen)
Comment 14 masterpatricko 2019-04-04 01:35:45 UTC
Created attachment 143859 [details]
output of intel_watermark with intel_idle.max_cstate=4 (issue not present)
Comment 15 Lakshmi 2019-07-13 17:30:42 UTC
Ville, What are the next steps?


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.