<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [CI] igt@* - dmesg-warn/fail - *ERROR* Potential atomic update failure on pipe [ABC]" href="https://bugs.freedesktop.org/show_bug.cgi?id=106678#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [CI] igt@* - dmesg-warn/fail - *ERROR* Potential atomic update failure on pipe [ABC]" href="https://bugs.freedesktop.org/show_bug.cgi?id=106678">bug 106678</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 Dhinakaran Pandiyan from <a href="show_bug.cgi?id=106678#c7">comment #7</a>) > "drm/i915/psr: vbt change for psr" changed the exit link training time from > 500 us to 2.5 ms on these machines. The frame counter is possibly stuck for > a longer duration now and pipe_update_start() is not aware that the counter > is stuck and warns. > > We've been discussing this problem for some time now and the VBT change > appears to have made it more likely to occur. > > Related discussion can be found in the April email archives under: > "[Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to > handle PSR exit" > > I wish this was caught in pre-merge instead of these drm-tip runs. The failure is still happening... If making a patch to fix this issue is taking too long, why has this patch not been reverted yet? We need to be more aggressive at keeping the bug count low...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>