You are not logged in.
Thanks ! I will keep you informed.
Offline
Hello,
I think there is a mistake. Pablo confirm that there is no need to revert anything on 6.4.15.
Offline
Do you need a new kernel built?
Offline
If possible …
I built a new from vanilla 6.4.15 without any patch with the same config from 6.4.12. But I am not sure that everything is fine…
Offline
Hi,
just rebooted to a vanilla 6.4.15. I have used this PKGBUILD http://ix.io/4G7K with this config http://ix.io/4G7L. Hope everything is right.
Tried to lower nft set timeout to 2m for about 1000 elements in a set. All elements were purged correctly without any error message.
But, I have not tested this on previous 6.4.12 or 6.3.9...
Waiting for about 48-72h now and see...
Last edited by cyayon (2023-09-12 06:52:23)
Offline
Hi,
No crash since 3 days with 6.4.15.
I will wait again a few days but it should be ok, many thanks !
I asked Pablo N to know if the patch / revert has been merged to 6.5.3, waiting his answer…
Offline
I asked Pablo N to know if the patch / revert has been merged to 6.5.3, waiting his answer…
Do you have a commit ID or subject for the patch / revert from any kernel? The seven netfilter commits back-ported to 6.4.13 were all in 5.3 and I can not see any netfilter commits in 6.4.14 or 6.4.15.
Offline
Oh, no...
This morning crash again .
Here is the journald log : http://ix.io/4Gvd
Offline
trace looks vastly different, though.
intel_idle.max_cstate=1 processor.max_cstate=1
You do have https://wiki.archlinux.org/title/Microcode ?
Offline
Yes I have intel-ucode 20230808-1
grub.cfg :
linux /slot1/boot/vmlinuz-linux root=UUID=df6ae634-3fbe-4d7b-9a0b-0fd35d2402da rw rootflags=subvol=slot1 consoleblank=0 pcie_aspm=off nvme_core.default_ps_max_latency_us=0
initrd /slot1/boot/intel-ucode.img /slot1/boot/initramfs-linux.img
grep microcode /proc/cpuinfo
microcode : 0xf4
microcode : 0xf4
microcode : 0xf4
microcode : 0xf4
microcode : 0xf4
microcode : 0xf4
microcode : 0xf4
microcode : 0xf4
Last edited by cyayon (2023-09-16 07:06:22)
Offline
Should I add these params to the boot command line ?
Remove microcode ?
Offline
Yes and No.
(The backtraces all feature cpu idling, but oc there's also a 26s stall, so that might be a red herring)
µcode patches are almost mandatory.
Offline
ok, done. thanks.
I also removed flowtable offload on my ip4/ip6 nftables ruleset (call trace referred to).
Which is strange is that I use this cpu with archlinux since about 6 or 7 years and never had any kernel panic / crash.
I regularly upgrade the system / kernel (about every month).
Since > 6.3.7, unable to have uptime > 4 or 5 days...
waiting now...
Last edited by cyayon (2023-09-16 13:58:29)
Offline
Hi,
no crash since 6 days with intel_idle.max_cstate=1 processor.max_cstate=1 and kernel 6.4.15.
I also disabled nft flowtables rules (fastpath).
If no crash for the week-end, I will re-enable nft flowtables and let's see...
I will keep you informed.
Offline
Hi,
No more crash with 6.4.15 and 6.5.5.
I do not really understand what params intel_idle.max_cstate=1 processor.max_cstate=1 are doing. Could you please explain ?
Thanks.
Offline
They prevent the CPU from entering higher c-states
https://en.wikipedia.org/wiki/ACPI#Processor_states
(The gist is that you're making Greta a very sad girl by using more energy, how dare you!)
Try "intel_idle.max_cstate=4 processor.max_cstate=4", the higher you raise the number, the more likely you'lll experience crashes again.
For an intel CPU, you only need "intel_idle.max_cstate=4" and for an AMD CPU "processor.max_cstate=4"
Offline
Thanks it is clear now !
Offline
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline