# [FreeBSD 13] High CPU Usage - rand_harvestq



## deltatux (May 17, 2021)

Hi all,

Recently I installed a fresh copy of FreeBSD 13 as a KVM guest on my Linux server and was wondering why one of the CPU cores is always pegged at 100%.

When issuing the top -SP command, I see that the rand_harvestq process is consuming 100% of CPU3 on my VM and I'm unsure why, it feels like this could be a bug but not sure.

Here's a screenshot of what I'm seeing:





I did some digging and this blogger seems to be experiencing the same problem that I'm facing, the blogger notes that high CPU usage from rand_harvestq happens when the VirtIO RNG is being used. The poster said that this issue was resolved when the "Intel Secure Key RNG" is being used instead. Unfortunately, I don't believe my home server hardware has the Intel Secure Key RNG available.









						VirtIO RNG may cause high CPU utilization by rand_harvestq in FreeBSD 13 VM
					

VirtIO RNG may cause high CPU utilization by rand_harvestq in FreeBSD 13 VM  I found my home server suddenly got increased power consumption. Its difference was up to 30W, so it's not obviously error.  It was caused by powering up FreeBSD VM on ProxmoxVE, but I had no reasonable reasons. When I...




					decomo.info
				




Was wondering if anyone else has run into this issue as well and may have a potential workaround or a bug report is required.

Any suggestions would be much appreciated.

Thank you.


----------



## Alain De Vos (May 18, 2021)

What's the output of,

```
sysctl kern.random.random_sources
```


----------



## covacat (May 18, 2021)

kern.random.random_sources='Sony Secure Key RNG'  
not very random, but light on cpu








						Hackers obtain PS3 private cryptography key due to epic programming fail? (update) | Engadget
					

The 27th annual Chaos Communication Conference already hacked encrypted GSM calls with a $15 cellphone, but there was a second surprise in store this morn -- the souls who unlocked the Nintendo Wii's homebrew potential (and defended it time and again) claim to have broken into the PlayStation 3...




					www.engadget.com


----------



## Alain De Vos (May 18, 2021)

I found a maybe related bugreport,





						230808 – rand_harvestq high CPU utilization
					






					bugs.freebsd.org


----------



## deltatux (May 18, 2021)

Alain De Vos said:


> What's the output of,
> 
> ```
> sysctl kern.random.random_sources
> ```


Thanks for your reply, much appreciated, the output I got was:


> kern.random.random_sources: 'VirtIO Entropy Adapter'





Alain De Vos said:


> I found a maybe related bugreport,
> 
> 
> 
> ...


I'm not sure if it's the same bug but it looks like it might be related. I see that bug was fixed back in 2019, maybe there's a regression for FreeBSD 13? I have another VM on the server that's currently running FreeBSD 12 and doesn't exhibit the same issue. It's rather odd for sure.

EDIT: I think I found a bug report that's for FreeBSD 13.0 for the same issue. The workaround posted seems to suggest to blacklist virtio_random on rc.conf.





						254513 – virtio_random: random_harvestq spinning on a CPU with Q35 virtio random device
					






					bugs.freebsd.org
				




EDIT2: It looks like the workaround in Bug ID 254513 seems to have worked but I'm not sure what the performance penalty is for disabling virtio_random. Hopefully it'll get fixed soon.

EDIT3: Additional digging seems to suggest that you can't combine the Q35 chipset with the VirtIO RNG Adapter, the combination causes issues. Either remove the VirtIO RNG Adapter from the VM or switch to the I440FX chipset emulation to resolve this issue.


----------



## D-FENS (Dec 26, 2021)

+1 I have the same issue. Logged a duplicate thread here before discovering this one.


----------



## grahamperrin@ (Dec 30, 2021)

roccobaroccoSC said:


> * Shutting down does not always work. Sometimes the system just hangs and does not properly shut down.



Incidentally (not seeking support) this symptom is commonplace with FreeBSD guests in VirtualBox, where EFI is enabled for the guest. Typically: `shutdown -p now` concludes with the USB-related lines, then I power off the guest.


----------

