Re: perf getting all-zeroes IP on STM32MP1

[Philippe Gerum <rpm@xenomai.org>]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

> Hi Andrew,
>
> [CC + Philippe]
>
> On Fri, 2026-09-04 at 15:26 +0200, Andrew MacPherson wrote:
>> Hello,
>> 
>> We're working on an STM32MP1-based system running Xenomai and found
>> that perf top shows every symbol as "unknown [00000000]", i.e.
>> profiling is collecting samples, but they all point at address zero.
>> 
>> I'm not a kernel developer but went through a few debug kernel builds
>> with an agent which eventually led to the attached patch. This change
>> does resolve the issue with perf, however I'm not sure if it's the
>> correct solution.
>> 
>> The reasoning is that arm_arch_timer.c's percpu IRQ registration never
>> sets IRQF_TIMER, so Dovetail's copy_timer_regs() never populates
>> tick_regs, leaving get_irq_regs() to always return an all-zero
>> pt_regs, which in turn breaks perf's sample IP.
>
> Yep, that is wrong. The patch you provided looks OK to me. I'm just
> wondering if that should be addressed in Linux as well / first.
>

In fact, Dovetail is somewhat abusing IRQF_TIMER in that the only bit in
that mask we should care about is __IRQF_TIMER, which is only used for
recovering from misrouted IRQs these days, specifically excluding some
descriptors from the polling loop which tries to find a proper
handler. Problem is that we also carry the no-suspend semantics attached
to this mask when using it, which is not what we mean.

I think that the mainline code simply acknowledges the fact that per-CPU
interrupt handlers should never be polled for solving a misrouted IRQ
issue by definition, so there is no point in tagging those lines with
__IRQ_TIMER in the first place, which applies to the architected timer
interrupt as well. IIRC, that was the point of the recent set of
upstream changes to request_percpu_irq(), dropping those flags. Such
change prompted us to put back a secondary interface accepting flags so
that we can keep on passing IRQF_TIMER.

> @Philippe: Any additional thoughts? Should we take it already?
>

I believe that we should not live much longer with this hack, we should
provide a dedicated IRQF_* flag introduced by Dovetail instead that
would specifically say "this line generates deferred tick events" or
something along these lines.

>
> @Andrew: Could you please provide a formal patch with proper signed-off
> and LLM notice (assuming agent means AI ;-)) targeting the dovetail 7.2.
> branch? That should help to speed things up. Thanks!
>
> Florian

-- 
Philippe.