Bug 106103

Bumping the priority to highest, because otherwise, we lose all coverage on cnl-psr for frontbuffer_tracking!

(In reply to Martin Peres from comment #1)
> Bumping the priority to highest, because otherwise, we lose all coverage on
> cnl-psr for frontbuffer_tracking!

Martin is this display/PSR & CRC related?

(In reply to Marta Löfstedt from comment #2)
> (In reply to Martin Peres from comment #1)
> > Bumping the priority to highest, because otherwise, we lose all coverage on
> > cnl-psr for frontbuffer_tracking!
> 
> Martin is this display/PSR & CRC related?

Yeah, quite likely given how only this one is affected.

Needs a kernel fix to not wait for CRC's when PSR is enabled.

Martin - Same question here - "idle run" only, and how often?

(In reply to James Ausmus from comment #5)
> Martin - Same question here - "idle run" only, and how often?

On every idle run, this produces hundreds of failures on fi-cnl-psr. 

It also affects BAT in almost every run (which would warrant HIGHEST if there wasn't that many of these :s). Here is an example:

 - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4338/fi-hsw-4200u/igt@kms_frontbuffer_tracking@basic.html
 - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4337/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html

Now, I don't see the logic with de-prioritising issues found in "idle runs". They may not be part of the problem of noise in CI, but it that does not make them less relevant to the users. I know PSR is disabled by default, but plenty of users do enable it anyway: https://www.google.fi/search?ei=wo0pW8GfO8Od6ATUg5KQCw&q=i915.enable_psr%3D1&oq=i915.enable_psr%3D1&gs_l=psy-ab.3..0j0i10i30k1.2350.3905.0.4294.5.5.0.0.0.0.239.759.0j4j1.5.0....0...1c.1.64.psy-ab..0.5.757...0i7i10i30k1j0i13k1.0.ULXDYBTGlIc

(In reply to Martin Peres from comment #6)
> (In reply to James Ausmus from comment #5)
> > Martin - Same question here - "idle run" only, and how often?
> 
> On every idle run, this produces hundreds of failures on fi-cnl-psr. 
> 
> It also affects BAT in almost every run (which would warrant HIGHEST if
> there wasn't that many of these :s). Here is an example:
> 
>  -
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4338/fi-hsw-4200u/
> igt@kms_frontbuffer_tracking@basic.html
>  -
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4337/fi-hsw-peppy/
> igt@kms_frontbuffer_tracking@basic.html
> 
Wrong links? Not sure why you think these two failures are PSR related.

Result: dmesg-fail
[  399.553943] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A
[  399.554300] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

> Now, I don't see the logic with de-prioritising issues found in "idle runs".
> They may not be part of the problem of noise in CI, but it that does not
> make them less relevant to the users. I know PSR is disabled by default, but
> plenty of users do enable it anyway:
> https://www.google.fi/search?ei=wo0pW8GfO8Od6ATUg5KQCw&q=i915.
> enable_psr%3D1&oq=i915.enable_psr%3D1&gs_l=psy-ab.3..0j0i10i30k1.2350.3905.0.
> 4294.5.5.0.0.0.0.239.759.0j4j1.5.0....0...1c.1.64.psy-ab..0.5.757...
> 0i7i10i30k1j0i13k1.0.ULXDYBTGlIc

Is this issue still seen? Looks like cnl-psr is not in CI anymore.

PSR is in the right stage for us to look at CRC errors. If this is still happening, I'd like to take a look at the logs.

(In reply to Dhinakaran Pandiyan from comment #9)
> PSR is in the right stage for us to look at CRC errors. If this is still
> happening, I'd like to take a look at the logs.

Sure thing! CI Bug Log is your best place to get this information (just click on the reproduction rate link). However, the filing is just terrible for this bug and it catches a lot of unrelated issues (no idea how it came to that state :o).

I'll work on it next week to sort this mess :o In the mean time, I will close it as INVALID because it is just worthless in this state.

(In reply to Martin Peres from comment #10)
> (In reply to Dhinakaran Pandiyan from comment #9)
> > PSR is in the right stage for us to look at CRC errors. If this is still
> > happening, I'd like to take a look at the logs.
> 
> Sure thing! CI Bug Log is your best place to get this information (just
> click on the reproduction rate link). However, the filing is just terrible
> for this bug and it catches a lot of unrelated issues (no idea how it came
> to that state :o).
> 
> I'll work on it next week to sort this mess :o In the mean time, I will
> close it as INVALID because it is just worthless in this state.

Oopsie, never got to do it, but it looks fixed anyway :D