Re: perf getting all-zeroes IP on STM32MP1

[Philippe Gerum <rpm@xenomai.org>]

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

> On Mon, 2026-09-07 at 14:41 +0200, Philippe Gerum wrote:
>> Florian Bezdeka <florian.bezdeka@siemens.com> writes:
>> 
>> > On Mon, 2026-09-07 at 10:57 +0200, Andrew MacPherson wrote:
>> > > On Fri, 4 Sept 2026 at 16:08, Florian Bezdeka
>> > > <florian.bezdeka@siemens.com> wrote:
>> > > > 
>> > > > 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.
>> > > > 
>> > > > @Philippe: Any additional thoughts? Should we take it already?
>> > > > 
>> > > > 
>> > > > @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
>> > > > 
>> > > > --
>> > > > Siemens AG, Foundational Technologies
>> > > > Linux Expert Center
>> > > > 
>> > > > 
>> > > 
>> > > Hi Florian,
>> > > 
>> > > I've submitted a patch now against dovetail 7.2, let me know if you
>> > > need anything else and thanks for the help!
>> > > 
>> > > 
>> > 
>> > Thanks! We might consider merging that while working on a better
>> > solution - as suggested by Philippe.
>> > 
>> 
>> Unfortunately, thinking a bit more/better, we'd still have an issue with
>> what I suggested. i.e. There are three contexts we need to care about in
>> this case:
>> 
>> 1. when a timer tick can be immediately delivered to its handler
>>    (i.e. hw irqs on) from a line tagged with IRQF_OOB.
>> 
>> 2. when a timer tick can be immediately delivered (i.e. in-band stage is
>>    installed) from a line set for in-band delivery (i.e. not tagged with
>>    IRQF_OOB). In this case, the interrupt log is synchronized before
>>    leaving handle_irq_pipelined_finish().
>> 
>> 3. when a timer tick /should/ but cannot be delivered to the in-band stage
>>    because the latter is stalled, i.e. need for deferral via the
>>    interrupt log.
>> 
>> In the first two cases, postponing the copy logic to
>> clockevents_handle_event() would be ok, because the interrupt frame of
>> the timer event would still be active, therefore using get_irq_regs() to
>> find the regs to copy would be correct.
>
> Agree.
>
>> 
>> In case #3, we have a deferral, therefore the interrupt frame is
>> certainly gone when the in-band stage is unstalled. Since other
>> interrupts could happen in between, we are toast.
>> 
>
> Hm, when setting up the proxy device, we mark the affected IRQs as OOB
> IRQs. Doesn't that mean that we end up in clockevents_handle_event() for
> those IRQs as well? That seems to be the case, if my debugging here is
> right.
>
> We want to copy the registers of the last OOB timer tick, no? That looks
> doable, but I might miss something or just did not run into the "inband
> stalled" case.

We want to copy those registers every time the profiling code may
consume them, including when the tick is delivered to the in-band stage
only. The proxy tick infrastructure allows for enabling only a subset of
the CPU range for oob traffic, other CPUs would keep on receiving timer
events from the in-band stage.

In order to extend the test case, I would tweak oob_cpus and look at the
perf results for a task affine to a non-oob processor.

-- 
Philippe.