Created attachment 130351 [details] kern.log System Environment ======= Ubuntu 16.10 libdrm-2.4.75-7-gf6499b1 from http://cgit.freedesktop.org/mesa/drm cairo 1.15.4-6-g5854dd9 from http://cgit.freedesktop.org/cairo Kernel: 4.10.0-15ccc64 branch drm-tip from https://cgit.freedesktop.org/drm-tip commit 15ccc648be8c8717d0e7b7d6ac6038394c15f898 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Mon Feb 27 09:13:30 2017 +0200 drm-tip: 2017y-02m-27d-07h-11m-41s UTC integration manifest Regression ======= Tested for the first time Bug detailed description ======= This problem only affect eDP so far, but is sending FIFO under run in dmesg after changing resolutions and having other programs running in the background Reproduce Steps ============== Enter in UI with your credentials Open Libreoffice Open glxgears Open a terminal, change resolution Xrandr --output eDP-1 --mode 1024x768 xrandr --output eDP-1 --mode 640x480 xrandr --output eDP-1 --mode 1920x1080 Expected Result ============= dmesg should be clean of FIFO underun caused by kernel Actual Result =========== [ 399.346861] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [ 399.346967] [drm:intel_fbc_underrun_work_fn [i915]] Disabling FBC due to FIFO underrun.
I noticed watermark programming differences for GLK in bspec, but fixing those didn't help, I can still reproduce these underruns. git@github.com:anderco/linux.git wip-glk-wm
The underrun happens immediately after enabling the edp transcoder in haswell_crtc_enable(). But I still don't know why.
Updated to highest/blocker due to impact on Alpha results.
I still haven't found the root cause for this, but I was enable to narrow it down further: - The underrun only happens with eDP because it is triggered by using the pipe scaler. If I force HDMI to use panel fitting, the underrun is also triggered. - The underrun happens only the first time the scaler is used. After reverting to the panel native resolution, a subsequent modeset won't trigger the underrun again. However, the underrun can be triggered once after a suspend/resume cycle. - Using the scaler to scale a plane before the modeset that triggers the scaler usage by the pipe will also prevent the underrun.
Created attachment 130742 [details] [review] Workaround patch I haven't been able to root cause the issue. The attached patch works around it by disabling underrun reporting on the first frame when enabling the pipe scaler. I'm now also seeing an underrun with FBC, but that happens even without changing resolution and goes away with i915.enable_fbc=0.
Created attachment 130896 [details] [review] Workaround patch I found a better workaround. If DPF clock gating is disabled before the pipe scaler is enabled, the underrun doesn't happen.
Hi Luis, Please check with the patch attached. Thanks.
(In reply to Ander Conselvan de Oliveira from comment #6) > Created attachment 130896 [details] [review] [review] > Workaround patch > > I found a better workaround. If DPF clock gating is disabled before the pipe > scaler is enabled, the underrun doesn't happen. With this patch there is no FIFO underruns, I used this config: ====================================== Software ====================================== kernel version : 4.11.0-rc7-drm-tip-patch-ander-underrun-f7dd93d+ architecture : x86_64 bios revision : 43.30 bios release date : 04/11/2017 ksc : 1.25 xf86-video-intel (tag) : 2.99.917 xf86-video-intel (commit) : 2.99.917-771-gb57abe2 xorg-xserver : 1.18.4 libdrm : 2.4.80 vaapi (intel-driver) : Intel i965 driver for Intel(R) Geminilake - 1.8.2.pre1 (1.7.3-382-gdbe582c) cairo : 1.15.5 xserver : X.Org X Server 1.19.99.1 dmc version : 1.4
Thanks. Status updated to resolved / fixed. It will be tested again when patch will be merged and this bug will be closed if still not reproduced.
Let's keep this open until the patch is merged. https://patchwork.freedesktop.org/series/24100/
I guess not yet merged?
Same situation still. Waiting some confirmation.
workaround patch still not merged...
Hi Ander, do you have any updates about patch merge?
(In reply to Luis Botello from comment #14) > Hi Ander, do you have any updates about patch merge? No, I'm not working on this (or Intel anymore). Maybe Imre can help?
(In reply to Ander Conselvan de Oliveira from comment #15) > (In reply to Luis Botello from comment #14) > > Hi Ander, do you have any updates about patch merge? > > No, I'm not working on this (or Intel anymore). Maybe Imre can help? Thanks Ander for your input. I just tested with top of drm-tip, issue still present: commit 30d8319f3f0974c3f116620627b428a7db307e78 Author: Imre Deak <imre.deak@intel.com> AuthorDate: Mon Jul 24 17:53:34 2017 +0300 Commit: Imre Deak <imre.deak@intel.com> CommitDate: Mon Jul 24 17:53:34 2017 +0300 drm-tip: 2017y-07m-24d-14h-53m-05s UTC integration manifest
Fix from Imre on review: https://patchwork.freedesktop.org/series/31094/
v2 now under review.
author Imre Deak <imre.deak@intel.com> 2017-10-02 07:55:57 (GMT) committer Imre Deak <imre.deak@intel.com> 2017-10-03 09:09:16 (GMT) commit ed69cd40685c949ec9c65701758bbf9e6840240f tree 72c71dcd4167579b4af494756a948dbe0aee2436 parent 495001c6457124e553ebeec30a42e75367724e4b drm/i915/glk, cnl: Implement WaDisableScalarClockGating
Luis please verify
Issue is not seen anymore with latest drm-tip: commit ce6163933673902f8cabd7111c04766b0fcd6e3d Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Date: Wed Oct 4 19:50:23 2017 +0300 drm-tip: 2017y-10m-04d-16h-49m-44s UTC integration manifest
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.