Synd

Sorry can't share the diagnostic @JorgeB (there's Engineering Sample equipment on my unraid, i can't do that due to NDAs) model name : AMD EPYC 7B13 64-Core Processor root@Megumin:~# grep -c ^processor /proc/cpuinfo 128 The big difference from my look at both of them is the multiple GPUs vs my 1 (which is a converged accelerator, which is the ES part) root@Megumin:~# du -sh /run/udev/* | sort -h | tail -3 0 /run/udev/tags 0 /run/udev/watch 17M /run/udev/data (this is my udev size) I know there was changes on the kernel on udev for multiple gpus due to issues at booting them "fast" enough on AI clusters. (just don't remember which 6.1 version got it, but it's one between 6.12.6 and 6.12.8, still looking at patches to see where it was applied, as we upgraded to 6.6 at work to have the patch before it was on 6.1) So, one thing i should think is making the udev 64MB for 6.13 (which would help for weird and complex systems.) I know Rome vs Milan also do udev differently, as it was an updated architecture on the cpu side. Mobo: Asrock Rack RomeD8-2T CPU: Epyc 7B13 Ram: 1TB PCIe Expensions: 1 x LSI 9400-8i (x8) 3 x ASUS Hyper M.2 card filled with m.2 1 x Nvidia A100X ES 1 x Connectx-5 pro 2 x Oculink to U.2 2 x M.2 (On-board) Those are all my specs as i posted yesterday on Discord to confirm where the issue could be.

Done, and found the regression in the kernel itself going thru our gits at work + the ticketering system. Dummy waits are applied to AMD with kernel 5.19 and was patched for 6.0. I shared a lot more details to staff in a private discord channel due to bringing internal work data into the conversation.

Which is what we found on Discord that Intel is not affected too. @Fuggin and @Kilrah did a parity, but only AMD builds are slowing down. @AgentXXL @Pri and me are running Epyc. I know @The_Mountain also has the issue on Epyc. This is a specific AMD bug after testing with multiple setups in the #offtopic channel of the Discord.

To add onto this, after more discussions, we found it's all the people with Epyc systems that have a slower parity since 6.11 like this bug presents. The Xeons users are usually fine with the Discord mods all running tests with some of the most active Discord users.

After update to RC4, the eth1 nic completely dissapeared, and only eth3 is left. So reboots have both nics working together. Reduced Priority to annoyance and added a new diagnostics to help compare with the rc3o, rc3 and rc4, if there's something to be seen that could cause it for the future. Thanks. megumin-diagnostics-20220319-2132.zip