Haveged 1.9.15-1

I have not gotten to recompiling the kernel to test yet. The setting in the kernel are RPi’s default config and appears to be not a factor with the other kernels. So I will compile this kernel later on with it enabled and test to see what happens.

2 Likes

I compiled the latest linux-rpi4-rc 5.15-rc3 with CONFIG_CRYPTO_JITTERENTROPY=y and it turned out with the same results as I had suspected as with CONFIG_CRYPTO_JITTERENTROPY=m in the other kernels was not a problem. Again, I believe the issue is in the code in the linux-rpi4-rc 5.15-rc3 kernel it’s self setting the initial entropy pool value.

entropy

1 Like

Maybe. It was just the most obvious difference between a working kernel (linux) and a non-working kernel (linux-rpi4) regarding entropy.

1 Like

I really do know whose fault it will wind up to be. I guess I could boot your latest upstream linux-rc kernel on the pi4 and if it is ok gather the command line outputs and and add the command line outputs for the RPi kernel and create an issue with the Rpi kernel git. I am reluctant to deal with them. Sometimes they are accommodating with their non default kernels and other times all I get is this kernel is not meant for use as it is a WIP.

1 Like

I installed your upstream linux-rc 5.15.0-rc3 on my pi4 image and it is the same old sad story.

1 Like

Very odd indeed.

I just noticed though, that the entropy is a Crypto thing. And Raspberry Pi has notoriously bad support for anything crypto. Could that be a reason for the low “idle” entropy count?

1 Like

At this point I have no clue whose fault it is. It looks like something has changed in the kernel after 5.14. If the other devices do not have this issue with your linux-rc 5.15.0-rc3 then it looks like someone (upstream or downstream) has to make a change some where if it is a pi specific issue.

The entropy pool starts low on both their kernel and the upstream kernel and it will increase over time with disk activity / mouse movement so in part it is working but starts too low. There is not as much disk activity during boot loading up things like a x86 would do and with the pi it may not be aware of fan movement.

I was following your rng-tools idea and I’ve got this post from archlinux arm Arch Linux ARM • View topic - [SOLVED] better entropy for raspberry pi?

At the bottom of this thread they indicate an old blog post dealing with hardware random number generator “Well, that was unexpected…”: The Raspberry Pi’s Hardware Random Number Generator – We Saw a Chicken …
They are dealing with /dev/hwrng and bcm2708-rng. Would this be relevant?

Edit: edit last question.

I believe so from what I can ascertain from reading. It seems with out rng-tools it uses /dev/random. I did some tests today from the link you provided with and without rngd.service enabled and there is some better looking results with rngd.service enabled.

Left pane rngd.service disabled and right pane rngd.service enabled with a fresh boot between tests:

I have conducted tests too but no really significant results.
I have to admit that I find it difficult to form an opinion on the subject.
Have you decided what to do in general to keep the entropy at a reasonable value?

So far install haveged or rngd and wait for something to happen in the kernel for a fix.

tryi this ?:

cat /etc/conf.d/rngd
RNGD_OPTS="-x jitter -r /dev/hwrng"