Re: Question about a freeze under Xenomai 3.2.1

[Julien Aube <julien.aube@smile.fr>]

Hello,

Le 05/05/2023 à 15:21, Jan Kiszka a écrit :
> On 05.05.23 09:36, Schuman Eelco (DC-AE/ESW5) wrote:
>> Hi,
>>
>>>> I think we saw this issue a while ago.  I can't remember if a proper
>>>> patch was submitted.  Let me take a look at my setup here.  I test
>>>> ipipe on both zynq7000 and Ultrascale boards.  I had a dovetail
>>>> environment to test zynq 7000 since there were some small issues
>>>> reported in the past. I should have some time to boot something
>>>> similar this weekend and see.
>>>>
>>>> -Greg
>> I had an issue like this some time ago, also with a Zynq 7000, Linux Dovetail 5.15, Xenomai 3.2 and a Buildroot build.  Processes would freeze after executing
>> some kind of delay e.g. sleep(). It looked like the default timer for the Zynq did not generate timer events for the proxy tick interrupts. I'm now trying a setup with
>> the Zynq global timer as source of events. That seems to run Ok so far.
>>
> Now I recall: There is very likely some adaptation needed for that
> default timer /wrt dovetail. Someone would have to dig into the details,
> looking left and right on other board/SoC enablements.


With your suggestions I finally had a working setup with SMP:

The culprit shown itself when I printed the original timer that is 
proxied by the timer_proxy,

On the non-SMP kernel the timer is set to "arm_global_timer", while on 
SMP it was set to "local_timer" :


 > IRQ pipeline: high-priority Xenomai stage added.
 > CPU0: proxy tick device registered (333.33MHz)
 > CPU0: proxy original clock: arm_global_timer

vs

 >CPU0: proxy original clock: local_timer
 >CPU1: proxy original clock: local_timer

 From what I understood, there is one timer per CPU , while the 
arm_global_timer is global to the system.

Digging a little more, I found out that the local_timer was implemented 
by the "scutimer" on the zynq7000 platform.
As a first approach, I just disabled this timer in the DTS.

With that the proxy original clock is now arm_glocal_timer for both CPU 
and it work.

However.... I have a bad feeling about this, it look like I did not go 
down to the real issue which is that the scutimer does not
generate timer events as it should.

Eelco , is that how you resolved the situation on your side ?

Many thanks for your help an tips for this issue,

Julien Aube