Arch Linux User Repository

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

@iseja ty for the heads up!! rebuilds coming up.

Please enable CONFIG_UNICODE, casefolding on ext4 needs that.

Okay well I'll commit that change regardless. I think this is a really random thing (like a race timing condition like mentioned) and its not worth losing your mind over...

@eggz 1. It seems I was wrong because linux-cachyos-lto 6.5.9 shows the same message. 2. ArchLinux Zen 6.5.8 doesn't 3. Your kernel whith CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE=n shows the message.

On second thought I think it might be CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE that does it. Let me fire up a build for you. (because I am going to disable it regardless)

They both have CONFIG_CRYPTO_JITTERENTROPY=yso that makes not much sense to me on first sight.

By the way, I'm using other kernels eventually (cachyos-lto and ArchLinux zen version) but the message appears only with this kernel.

Interesting. While I'm sure this error is not intended and a bug indeed, since it seems to pop up pretty commonly (and popped up fairly recently), the impact is effectively zero. I'll dig in the commits if I have some spare time to see what commit might have caused this behaviour none the less as it is interesting indeed.

@eggz, "I assume that error does not concern this specific kernel version, because it seems to be a common error"

That is correct. I saw this error en latest kernel versions (not sure but maybe 3 or 4) but not before. I'll let it go because everything seems to be ok.

Thanks again

@Anarconda, I assume that error does not concern this specific kernel version, because it seems to be a common error:

This is what I could dig up:

with AMD 2nd generation EPYC (Rome) CPUs seems to report this error more frequently than other systems, but all x86 servers (both Intel and AMD CPUs) can experience this error.

Since that article was made back in the day, I assume its a thing for all zenv2+ CPUs.

A race condition between calibrating the TSC clock source and initializing the jitterentropy crypto code. This will remove the the jitterentropy source of entropy, but the kernel and rngd daemon can use other sources such as a hardware TRNG or the RDRAND/RDSEED instructions on newer x86 CPUs.
Source: https://access.redhat.com/solutions/4384951

This rings true, modern (AMD) CPUs use RDRAND/RDSEED now:

AMD’s Family 17h processor and other products of 2016 and beyond are equipped
with Cryptographic Co-processor 5.0 hardware that enables the generation of
cryptographically secure random numbers. 

Source: https://www.amd.com/content/dam/amd/en/documents/pdfs/developer/aocl/amd-secure-random-number-generator-library-2.0-whitepaper.pdf

The Cryptographic Co-processor is indeed capable of RDSEED/RDRAND.

As far as I can understand, this is really not worth losing any sleep over. The thing that failed seems to be legacy and superseeded by more modern means to generate random numbers by using capabilities already present on your CPU. I am always open to the contrary, but this seems to rings true to me.