<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BAT][BYT] Atomic update failure on pipe A when running basic-flip-vs-dpms on CI" href="https://bugs.freedesktop.org/show_bug.cgi?id=100652#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BAT][BYT] Atomic update failure on pipe A when running basic-flip-vs-dpms on CI" href="https://bugs.freedesktop.org/show_bug.cgi?id=100652">bug 100652</a> from <a class="email" href="mailto:martin.peres@free.fr" title="Martin Peres <martin.peres@free.fr>"> Martin Peres</a> <pre>(In reply to Ville Syrjala from <a href="show_bug.cgi?id=100652#c2">comment #2</a>) > (In reply to Martin Peres from <a href="show_bug.cgi?id=100652#c0">comment #0</a>) > > 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!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>