<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][SHARDS] igt@perf@gen8-unprivileged-single-ctx-counters - dmesg-fail - Failed assertion: ret >= 0, Cannot allocate memory" href="https://bugs.freedesktop.org/show_bug.cgi?id=111821#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][SHARDS] igt@perf@gen8-unprivileged-single-ctx-counters - dmesg-fail - Failed assertion: ret >= 0, Cannot allocate memory" href="https://bugs.freedesktop.org/show_bug.cgi?id=111821">bug 111821</a> from <a class="email" href="mailto:umesh.nerlige.ramappa@intel.com" title="umesh <umesh.nerlige.ramappa@intel.com>"> umesh</a> <pre>The test captures counter snapshots using MI RPC before and after a few render workloads. The batch consisting of the MI-RPC also does a PIPE_FLUSH and reads/stores the TIMESTAMP value from the render timestamp register. Since there may be a context switch during the execution of these workloads, the test also collects reports from the OA buffer between the OA timestamps collected from the MI RPCs. Is uses all these reports to calculate the actual delta between the counters A0, A21 and A26. The delta of the counters is expected to be a certain fixed value for the render copy performed. The failure is likely from a large deviance between "timestamp delta from MI RPC OA timestamps" and "timestamp delta between render timestamps collected along with MI-RPC". The large deviance causes the test to try again. Every time the test tries again, it allocates some resources. Eventually results in OOM. Machines: skl, kbl Repro rate: 5% Impact: Accuracy of perf snapshots from MI-RPC Severity: Medium Pririty: High</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>