Re:Re: schedule delay 15ms

[JerryJun <jerryjun123@163.com>]

Strangely enough, this delay wasn't present on the 4.19.89-ipip kernel - it only emerged after upgrading to 5.10.199-dovetail, despite no changes being made to the power management policy or thermal throttling settings during the update. Could this be related to potential instability in the HPET or TSC clock sources? And does upgrading to a new kernel version also necessitate a BIOS update?

At 2025-11-14 13:38:36, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>On 14.11.25 03:48, JerryJun wrote:
>> 
>>   We added some trace event information, but from this gap point (6208.695948-> 6208.708726), it appears that the Cobalt kernel was frozen and no interrupt handling occurred.
>>    include trace point events :
>>     irq_vectors:call_function_entry                    
>>     irq_vectors:call_function_exit                     
>>     irq_vectors:call_function_single_entry             
>>     irq_vectors:call_function_single_exit   
>> 
>
>If there are no interrupt in that phase while, e.g., some timer
>interrupt should have occurred, then you should definitely check for
>hardware/firmware related delays that the OS cannot influence. Or for
>power-saving / thermal-throttling causes.
>
>Jan
>
>> 在 2025-11-13 13:31:54，"Jan Kiszka" <jan.kiszka@siemens.com> 写道：
>>> On 13.11.25 05:00, JerryJun wrote:
>>>>
>>>> We conducted tests on the kernel version v5.10.245-cip65-dovetail1. The test results are attached. During this period, we also performed latency tests, which showed a 10ms delay at 7174.313414 -> 7174.323086.  irq 114 is net driver interrupt 。
>>>>
>>>
>>>         swapper     0 [003]  7174.313414:                     irq:irq_pipeline_entry: irq=114
>>>         swapper     0 [003]  7174.323086:                     irq:irq_pipeline_entry: irq=33027
>>>
>>> So, that is the gap. Did you also turn on irq_pipeline_exit? I'm not 
>>> seeing that event in the trace. Furthermore, I always for get about 
>>> that, it is useful to have irq_vectors events because those include 
>>> timer irqs. But it is unlikely that we missed any in that gap because 
>>> they tend to trigger activities like cobalt_core:cobalt_timer_expire.
>>>
>>> What is more likely here is that your hardware or firmware is not 
>>> letting IRQs through. We could confirm that if the issue is reproducible 
>>> while have function tracing enabled. That comes with high overhead, but 
>>> the detailed result can tell us what the kernel did while there were no 
>>> interrupts.
>>>
>>> There is also native tooling by the kernel to detect "hardware noise",
>>> see https://docs.kernel.org/tools/rtla/rtla-hwnoise.html. Due to its 
>>> nature, this noise would affect Xenomai equally.
>>>
>>> Jan
>>>
>>> -- 
>>> Siemens AG, Foundational Technologies
>>> Linux Expert Center
>
>
>-- 
>Siemens AG, Foundational Technologies
>Linux Expert Center