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 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.

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.

IOW, close, but no cigar. Back to the drawing board.

-- 
Philippe.