Re: Random system freezes with Linux 6.12 + Xenomai 3.3.1 on Intel Ultra 5 125H
刘杨 <[email protected]> Wed, 29 Jul 2026 16:04:44 +0800
| Newsgroups | dev.linux.lists.xenomai |
|---|---|
| Message-ID | <ed7c43ef85386e7d9b7bfcd2895307dc2948cb81.2cdf3bbf.6288.45f6.b5d6.9760f144d99c@feishu.cn> |
Thank you for your reply. Regarding kernel ftrace, do you have any suggesti= ons on which parts I should mainly trace? If I enable tracing for everythin= g, the output file will become extremely large > From: "Jan Kiszka"<[email protected]> > Date:=C2=A0 Wed, Jul 29, 2026, 15:54 > Subject:=C2=A0 Re: Random system freezes with Linux 6.12 + Xenomai 3.3.1 = on Intel Ultra 5 125H > To: "=E5=88=98=E6=9D=A8"<[email protected]> > Cc: "xenomai"<[email protected]>, "=E5=AE=8B=E5=81=A5=E7=8E=AE"<son= [email protected]> > On 29.07.26 08:57, =E5=88=98=E6=9D=A8 wrote: > > Hi, > > =C2=A0=C2=A0 We have already conducted long-term tests on the following= hardware platforms using kernel 6.12.55 with Xenomai 3.3.1: N100, N97, J64= 12, i5-12400, and AMD Ryzen 7 8845HS. I am using the 6.12.y-cip-dovetail-re= base=C2=A0branch, and the latest kernel version available in this branch is= 6.12.90. I can use the xenomai- >=C2=A0 > Ups, I guess I need to re-sync the v6.12.y-cip-dovetail to -rebase soon..= . >=C2=A0 > > image=C2=A0provided officially by Xenomai. Could you please provide a d= ownload link for the xenomai-image=C2=A0corresponding to the 6.12 kernel ve= rsion? >=C2=A0 > We do not offer pre-built images, but it should be rather simple to > generate one yourself, just following the README. >=C2=A0 > > If we completely disable the NVIDIA driver, our test programs may not r= un properly. I will disable the nvidia_uvm=C2=A0driver later for further ve= rification. > > For the 6.18 kernel, I compiled it from the 6.18.y-dovetail-rebase=C2= =A0branch. The 6.18 kernel exhibits the same issue: the system hangs after = running for a certain period. However, when using the 6.18 kernel, SSH rema= ins accessible even after the hang. > >=C2=A0 >=C2=A0 > Then you could try to let tracing run during the test and extract an > event trace after the hang. Maybe that reveal how the core(s) lock up, > over which exact workload. >=C2=A0 > Jan >=C2=A0 > --=C2=A0 > Siemens AG, Foundational Technologies > Linux Expert Center >=C2=A0