The machine fi-byt-j1900 warned about an atomic update failure on pipe A when running the test igt@kms_flip@basic-flip-vs-dpms on CI_DRM_2508. Relevant line in dmesg: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=2 end=3) time 15868 us, min 763, max 767, scanline start 24, end 791 Full results: https://intel-gfx-ci.01.org/CI/CI_DRM_2508/fi-byt-j1900/igt@kms_flip@basic-flip-vs-dpms.html
Now also seen on igt@kms_flip@basic-flip-vs-modeset
(In reply to Martin Peres from comment #0) > The machine fi-byt-j1900 warned about an atomic update failure on pipe A > when running the test igt@kms_flip@basic-flip-vs-dpms on CI_DRM_2508. > > Relevant line in dmesg: > [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe > A (start=2 end=3) time 15868 us, min 763, max 767, scanline start 24, end 791 > ~16 ms to write a few registers! Sweet.
(In reply to Ville Syrjala from comment #2) > (In reply to Martin Peres from comment #0) > > The machine fi-byt-j1900 warned about an atomic update failure on pipe A > > when running the test igt@kms_flip@basic-flip-vs-dpms on CI_DRM_2508. > > > > Relevant line in dmesg: > > [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe > > A (start=2 end=3) time 15868 us, min 763, max 767, scanline start 24, end 791 > > > > ~16 ms to write a few registers! Sweet. Maybe it is time to check out if there isn't any lock contention that could generate this condition? Linux-rt has great tools for that! Given that we have this bug on multiple platforms, it's possible that we could substantially improve our chances to make the deadline. This is gonna be even more necessary for 120Hz screens on weston (which delays the queuing of the flip roughly mid-way through the complete scanout). So, after all, queuing updates in a pushbuffer does not sound so stupid in this scenario!
Adding tag into "Whiteboard" field - ReadyForDev The bug still active *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set
Updating statistics: Last seen on igt@kms_flip@basic-flip-vs-modeset: 2017-05-10 Statistics: Failure rate 6/175 run(s) (3%) Last seen on igt@kms_flip@basic-flip-vs-dpms: 2017-05-08 Statistics: Failure rate 4/179 run(s) (2%)
Do we still consider this as issue and fix needed. Does that maxcpu=2 matters here and some other fix done?
Still not seen. Lets close this for now as not reproducible
Whitelisted on CI.
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.