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
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.
(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).
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.
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
Created attachment 143233 [details] Dmesg with fastboot off, intermittent display
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.
Ville, I see FIFO underrun from the log. Can you help here?
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.
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 .
I tried to reproduce the issue on Kaby Lake, but not able to reproduce it.
(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.
(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.
Created attachment 143858 [details] output of intel_watermark without intel_idle.max_cstate=4 (during black/flickering screen)
Created attachment 143859 [details] output of intel_watermark with intel_idle.max_cstate=4 (issue not present)
Ville, What are the next steps?
The point was to get the output with and without fastboot, not max.cstate anyway, test 5.3rc which others have found to work without workarounds
Reporter, as Timo said can you please verify the issue with latest drmtip (https://cgit.freedesktop.org/drm-tip).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/208.
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.