Hi,
I noticed that on my machine the screen starts to flicker after I suspend and resume my machine, on the main laptop display if an external display is attached with kernel v4.1-rc1. I tracked the regression down to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)"), and sent a patch that fixes that behavior at [1] about two weeks ago, although I'm not sure it's the right thing to do, as I'm not very familiar with the code. The same bug still exists in vv4.1-rc3.
Jan Niehusmann confirmed the behavior, but there has been no further discussion on the topic. I also forgot to cc the people that were involved in the patch that caused the regression (sorry about that).
Is there anything else that I can do to help fixing this issue?
Thanks, Thomas
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
On Tue, 12 May 2015, Thomas Gummerer t.gummerer@gmail.com wrote:
Hi,
I noticed that on my machine the screen starts to flicker after I suspend and resume my machine, on the main laptop display if an external display is attached with kernel v4.1-rc1. I tracked the regression down to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)"), and sent a patch that fixes that behavior at [1] about two weeks ago, although I'm not sure it's the right thing to do, as I'm not very familiar with the code. The same bug still exists in vv4.1-rc3.
Jan Niehusmann confirmed the behavior, but there has been no further discussion on the topic. I also forgot to cc the people that were involved in the patch that caused the regression (sorry about that).
Is there anything else that I can do to help fixing this issue?
Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
BR, Jani.
Thanks, Thomas
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
Hi,
On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
The visible effect in the video is similar to what I see on the LVDS display. I also see some influence of the mouse pointer position on the blanked areas.
The effect on the external screen is more like single scan lines jumping to the right and back, at a high (but still visible) frequency.
What I'm missing in the report, are some log entries I'm seeing on my notebook:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
Jan
On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
Hi,
On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
The visible effect in the video is similar to what I see on the LVDS display. I also see some influence of the mouse pointer position on the blanked areas.
The effect on the external screen is more like single scan lines jumping to the right and back, at a high (but still visible) frequency.
What I'm missing in the report, are some log entries I'm seeing on my notebook:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
hi, I also have the similar entries in my dmesg, though my problem is a little different from yours and my bisect lead to another commit. And that also is still not fixed (last tested with 4.0).
http://patchwork.freedesktop.org/patch/46071/
regards sudip
Jan
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
What I'm missing in the report, are some log entries I'm seeing on my notebook:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
hi, I also have the similar entries in my dmesg, though my problem is a little different from yours and my bisect lead to another commit. And that also is still not fixed (last tested with 4.0).
(Please note that I didn't do a bisect - that was Thomas. I only noted that I can confirm his observations and that his patch helps to prevent or hide the issue.)
Perhaps these are two completely unrelated issues?
Jan
On Wed, May 13, 2015 at 01:10:11PM +0200, Jan Niehusmann wrote:
On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
What I'm missing in the report, are some log entries I'm seeing on my notebook:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
hi, I also have the similar entries in my dmesg, though my problem is a little different from yours and my bisect lead to another commit. And that also is still not fixed (last tested with 4.0).
(Please note that I didn't do a bisect - that was Thomas. I only noted that I can confirm his observations and that his patch helps to prevent or hide the issue.)
Perhaps these are two completely unrelated issues?
yes, maybe unrelated issue. since I am also having similar errors in dmesg and also having a similar type of problem so replied here.
regards sudip
Jan
Sudip Mukherjee sudipm.mukherjee@gmail.com writes:
On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
hi, I also have the similar entries in my dmesg, though my problem is a little different from yours and my bisect lead to another commit. And that also is still not fixed (last tested with 4.0).
Thank you for the pointer, but this seems to be an unrelated issue. I tried applying the patch, but it doesn't fix the issues that I'm experiencing.
regards sudip
On Wed, May 13, 2015 at 01:27:06PM +0200, Thomas Gummerer wrote:
Sudip Mukherjee sudipm.mukherjee@gmail.com writes:
On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote: http://patchwork.freedesktop.org/patch/46071/
Thank you for the pointer, but this seems to be an unrelated issue. I tried applying the patch, but it doesn't fix the issues that I'm experiencing.
thanks for confirming. I am out of this thread now :)
regards sudip
regards sudip
Jan Niehusmann jan@gondor.com writes:
Hi,
On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
The visible effect in the video is similar to what I see on the LVDS display. I also see some influence of the mouse pointer position on the blanked areas.
I can see the same thing, though it looks slightly different to me, but the slight difference might be unrelated.
The effect on the external screen is more like single scan lines jumping to the right and back, at a high (but still visible) frequency.
I don't see the behavior on my external screen. Maybe some more information that might help:
The laptop is a dell XPS 15 9530, screen resolution 3200x1800. The external display is connected via DisplayPort, resulution 1920x1080. Output from lspci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:04.0 Signal processing controller: Intel Corporation Device 0c03 (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5) 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5) 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05) 00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset Family Thermal Management Controller (rev 05) 02:00.0 3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1) 06:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) 07:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5249 PCI Express Card Reader (rev 01)
What I'm missing in the report, are some log entries I'm seeing on my notebook:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
I see the last two messages in my dmesg output, but not the first two.
Jan
On Tue, May 12, 2015 at 09:54:07PM +0200, Thomas Gummerer wrote:
Hi,
I noticed that on my machine the screen starts to flicker after I suspend and resume my machine, on the main laptop display if an external display is attached with kernel v4.1-rc1. I tracked the regression down to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)"), and sent a patch that fixes that behavior at [1] about two weeks ago, although I'm not sure it's the right thing to do, as I'm not very familiar with the code. The same bug still exists in vv4.1-rc3.
Jan Niehusmann confirmed the behavior, but there has been no further discussion on the topic. I also forgot to cc the people that were involved in the patch that caused the regression (sorry about that).
Is there anything else that I can do to help fixing this issue?
Thanks, Thomas
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
Sorry, I missed your patch when you first sent it. That type of fix looks like an okay workaround while we do a more in-depth rework of the watermark system. However I think your patch could cause a crash if we disable the primary plane via the universal plane interface; if we do that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending the primary plane is always enabled, ilk_wm_fbc() can eventually get called and use that 0 in the denominator of a division operation.
If you just squash the following change into your patch, I think it should be safe:
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index eb97cbe..99fa8ee 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2076,7 +2076,7 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc, p->pri.bytes_per_pixel = crtc->primary->state->fb->bits_per_pixel / 8; else - p->pri.bytes_per_pixel = 0; + p->pri.bytes_per_pixel = 4;
p->cur.bytes_per_pixel = 4; /*
Matt
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)") fixes a null pointer dereference. Setting the primary and cursor panes to false in ilk_compute_wm_parameters to false does however give the following errors in the kernel log and causes the screen to flicker.
[ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A [ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Always setting the panes to enabled fixes this error.
Helped-by: Matt Roper matthew.d.roper@intel.com Signed-off-by: Thomas Gummerer t.gummerer@gmail.com ---
Sorry, I missed your patch when you first sent it. That type of fix looks like an okay workaround while we do a more in-depth rework of the watermark system. However I think your patch could cause a crash if we disable the primary plane via the universal plane interface; if we do that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending the primary plane is always enabled, ilk_wm_fbc() can eventually get called and use that 0 in the denominator of a division operation.
If you just squash the following change into your patch, I think it should be safe: [...]
Thank you very much for the suggestion, here is an updated version of the patch.
drivers/gpu/drm/i915/intel_pm.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index fa4ccb3..555b896 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc, p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal; p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
- if (crtc->primary->state->fb) { - p->pri.enabled = true; + if (crtc->primary->state->fb) p->pri.bytes_per_pixel = crtc->primary->state->fb->bits_per_pixel / 8; - } else { - p->pri.enabled = false; - p->pri.bytes_per_pixel = 0; - } + else + p->pri.bytes_per_pixel = 4; + + p->cur.bytes_per_pixel = 4; + /* + * TODO: for now, assume primary and cursor planes are always enabled. + * Setting them to false makes the screen flicker. + */ + p->pri.enabled = true; + p->cur.enabled = true;
- if (crtc->cursor->state->fb) { - p->cur.enabled = true; - p->cur.bytes_per_pixel = 4; - } else { - p->cur.enabled = false; - p->cur.bytes_per_pixel = 0; - } p->pri.horiz_pixels = intel_crtc->config->pipe_src_w; p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)") fixes a null pointer dereference. Setting the primary and cursor panes to false in ilk_compute_wm_parameters to false does however give the following errors in the kernel log and causes the screen to flicker.
[ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A [ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Always setting the panes to enabled fixes this error.
Helped-by: Matt Roper matthew.d.roper@intel.com Signed-off-by: Thomas Gummerer t.gummerer@gmail.com
Seems like a reasonable short-term workaround and returns us to how the code used to behaves.
Reviewed-by: Matt Roper matthew.d.roper@intel.com
Sorry, I missed your patch when you first sent it. That type of fix looks like an okay workaround while we do a more in-depth rework of the watermark system. However I think your patch could cause a crash if we disable the primary plane via the universal plane interface; if we do that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending the primary plane is always enabled, ilk_wm_fbc() can eventually get called and use that 0 in the denominator of a division operation.
If you just squash the following change into your patch, I think it should be safe: [...]
Thank you very much for the suggestion, here is an updated version of the patch.
drivers/gpu/drm/i915/intel_pm.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index fa4ccb3..555b896 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc, p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal; p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
- if (crtc->primary->state->fb) {
p->pri.enabled = true;
- if (crtc->primary->state->fb) p->pri.bytes_per_pixel = crtc->primary->state->fb->bits_per_pixel / 8;
- } else {
p->pri.enabled = false;p->pri.bytes_per_pixel = 0;- }
- else
p->pri.bytes_per_pixel = 4;- p->cur.bytes_per_pixel = 4;
- /*
* TODO: for now, assume primary and cursor planes are always enabled.* Setting them to false makes the screen flicker.*/- p->pri.enabled = true;
- p->cur.enabled = true;
- if (crtc->cursor->state->fb) {
p->cur.enabled = true;p->cur.bytes_per_pixel = 4;- } else {
p->cur.enabled = false;p->cur.bytes_per_pixel = 0;- } p->pri.horiz_pixels = intel_crtc->config->pipe_src_w; p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
-- 2.4.0.184.g8e1974e
On Thu, 14 May 2015, Matt Roper matthew.d.roper@intel.com wrote:
On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)") fixes a null pointer dereference. Setting the primary and cursor panes to false in ilk_compute_wm_parameters to false does however give the following errors in the kernel log and causes the screen to flicker.
[ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A [ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Always setting the panes to enabled fixes this error.
Helped-by: Matt Roper matthew.d.roper@intel.com Signed-off-by: Thomas Gummerer t.gummerer@gmail.com
Seems like a reasonable short-term workaround and returns us to how the code used to behaves.
Reviewed-by: Matt Roper matthew.d.roper@intel.com
Pushed to drm-intel-fixes, thanks for the patch and review.
BR, Jani.
Sorry, I missed your patch when you first sent it. That type of fix looks like an okay workaround while we do a more in-depth rework of the watermark system. However I think your patch could cause a crash if we disable the primary plane via the universal plane interface; if we do that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending the primary plane is always enabled, ilk_wm_fbc() can eventually get called and use that 0 in the denominator of a division operation.
If you just squash the following change into your patch, I think it should be safe: [...]
Thank you very much for the suggestion, here is an updated version of the patch.
drivers/gpu/drm/i915/intel_pm.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index fa4ccb3..555b896 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc, p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal; p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
- if (crtc->primary->state->fb) {
p->pri.enabled = true;
- if (crtc->primary->state->fb) p->pri.bytes_per_pixel = crtc->primary->state->fb->bits_per_pixel / 8;
- } else {
p->pri.enabled = false;p->pri.bytes_per_pixel = 0;- }
- else
p->pri.bytes_per_pixel = 4;- p->cur.bytes_per_pixel = 4;
- /*
* TODO: for now, assume primary and cursor planes are always enabled.* Setting them to false makes the screen flicker.*/- p->pri.enabled = true;
- p->cur.enabled = true;
- if (crtc->cursor->state->fb) {
p->cur.enabled = true;p->cur.bytes_per_pixel = 4;- } else {
p->cur.enabled = false;p->cur.bytes_per_pixel = 0;- } p->pri.horiz_pixels = intel_crtc->config->pipe_src_w; p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
-- 2.4.0.184.g8e1974e
-- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795
dri-devel@lists.freedesktop.org
-
Jan Niehusmann -
Jani Nikula -
Matt Roper -
Sudip Mukherjee -
Thomas Gummerer