Presumably, this happens in case a perf counter overflows. This might be a hardware bug, which needs a workaround. We don't have enough knowledge to fix it or investigate further. Since the issue is rare and can't lead to system crash, we can close our eye on it. Nevertheless, it taints the kernel, which results in test failure. To avoid that, let's replace WARN with pr_warn.
https://jira.sw.ru/browse/PSBM-49258 Signed-off-by: Vladimir Davydov <[email protected]> --- arch/x86/kernel/cpu/perf_event_intel.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c index 5106e8378d96..9f2a12e5e553 100644 --- a/arch/x86/kernel/cpu/perf_event_intel.c +++ b/arch/x86/kernel/cpu/perf_event_intel.c @@ -1579,8 +1579,13 @@ static int intel_pmu_handle_irq(struct pt_regs *regs) again: intel_pmu_ack_status(status); if (++loops > 100) { - WARN_ONCE(1, "perfevents: irq loop stuck!\n"); - perf_event_print_debug(); + static bool warned = false; + if (!warned) { + pr_warn("perfevents: irq loop stuck!\n"); + dump_stack(); + perf_event_print_debug(); + warned = true; + } intel_pmu_reset(); goto done; } -- 2.1.4 _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
