[rng-tools] 100% CPU usage on Odroid C1

This forum is for topics dealing with problems with software specifically in the ARMv7h repo.

[rng-tools] 100% CPU usage on Odroid C1

Postby slydder » Thu Jan 07, 2021 1:08 pm

After the latest update of rng-tools the CPU usage of the rngd deamon is at 100% on Odroid C1:
Code: Select all
7467  root     20   0   81196   1700   1248 S 323.8   0.2   1:10.93 rngd

Packet versions:
rng-tools 6.10-3
jitterentropy 3.0.0-2
linux-odroid-c1 3.10.107-4

As I understood from the changelog in rng-tools 6.10-3 the linking was fixt with jitterentropy 3.0.0-2.

The workaround curently is to downgrade rng-tools or disable jitterentropy.
Posts: 28
Joined: Sat Dec 05, 2015 11:40 am

Re: [rng-tools] 100% CPU usage on Odroid C1

Postby windozupdat3 » Sat Jan 09, 2021 9:09 am

I can can confirm the issue on odroid C1 even with mainline kernel.
Posts: 30
Joined: Tue Aug 29, 2017 9:07 am

Re: [rng-tools] 100% CPU usage on Odroid C1

Postby pwr33 » Tue Jan 12, 2021 8:13 pm

same problem on raspberry pi zero that has the 1wire overlay enabled on gpio-10 and doing some i2c reads, rngd = 99% cpu

however on another arch pi zero problem does not exist, running mpd playing a network stream 90% idle with rngd running rngd = 0% cpu

edit: was working OK but upgraded that zero to latest raspberry firmware and rngd started hogging cpu there as well
(maybe a red herring as sure I did an upgrade on that one yesterday, maybe did not reboot it until today...)


rngd does not seem to be filling the entropy pool
cat /proc/sys/kernel/random/entropy_avail

haveged works ok if you disable rngd

edit 2:

just tested on a third arch zero and same thing, was OK on rng-tools 6.10-3, after upgrade rng-tools 6.11-1 not working

edit 3:


sudo nano /etc/conf.d/rngd

RNGD_OPTS="-x jitter"

edit 4:

reading up on if haveged and rngd co-exist OK seems opinion/fact is they do, and a few days later all seems no noticeable conflict problem...

maybe 1 of manifold kernel and bootloader upgrades has fixed it meantime?

problem with arch is have to regularly revert temporary fixes to see if it has been globally fixed eh!

turns out the aur of rpi.gpio would have worked, but I had actually installed it via pip and that had not got the gcc10 compiler fix in its build.....

upgrade of python is a pita in that the previously installed pip packages go in current python dot version lib directory and not a common major version directory.... dependencies eh!

edit 5:

Of Course! venv is doubly important in arch.... or a bit dangerous LOL

probability of snapshot being very very good eh!
Posts: 7
Joined: Sat Mar 14, 2020 3:21 pm

Return to ARMv7h

Who is online

Users browsing this forum: No registered users and 2 guests