bhyve taking 100% CPU on wifibox startup

[ltning]

Since upgrading from 1.0.0 to 1.1.1 (wifibox, -core and -alpine), I can no longer get wifibox to work. The wifibox start command returns OK, but the bhyve process sits at 100% CPU forever.

Had to revert to iwlwifi to write this bug report :)

Not sure which parts of the config you'd want to see (reminds me - I couldn't find any upgrade instructions despite a "breaking change" notificaiton on the releases page)..

[pgj]

Hi @ltning, thanks for the report and the feedback! There are no specific upgrade instructions to move between releases. Most of the cases a simple reinstall is the easiest way to upgrade. In the release notes, I tried to summarize what implies the "breaking" tag that can suggest the nature of the expected breakage. Currently it is a one-man project, that is what I could come up with. I try to avoid breaking things but sometimes it happens, sorry for that.

For the analysis, first I think it would be good to see a dmesg output from the guest that you can find at /var/log/run/wifibox/appliance/log/dmesg. I suspect that the kernel could not boot for some reason (maybe the memory allocated for the guest is too low) so it stuck and that is what causes the spinning with the high CPU usage.

[ltning]

I know it's a one man project and if it wasn't clear (how would it be... all I do is complain ;) ) I'm immensely grateful for your efforts. Wifibox has served me well for a long time now!

I can't find anything in /var/run/wifibox other than directories. No log files. And /var/log/wifibox.log is empty.

Restarting wifibox is a bit of a dangerous thing here; quite often both nvme and other devices just drop off the bus or start timing out, after a while the thing just panics and reboots. I'm assuming it has to do with the PCI passthrough code in bhyve.

I'm running stable/13-n252019-158071c51a1f, built a few days ago. Upgraded wifibox today, was looking forward to easier config of NAT rules..

[pgj]

Oh, I see, so the guest could not even boot up. The /var/log/wifibox.log is not that talkative by default but you can change this by increasing the log level to e.g. debug in core.conf at $ETCDIR/wifibox. It should at least show that wifibox tries to launch the VM.

Regarding the issue about restarting: yeah, that sounds much like a bhyve or even a vmm kernel module problem. I have seen similar things when experimenting with the FreeBSD 11 port: the PCI pass-through started to interfere with the USB driver and the reason was the incomplete way of interacting with VT-d. That particular problem has been fixed a while now, but apparently many similar things are lurking in the shadows.

[pgj]

@ltning this seems to be related to #29 -- please read the comments and see if the problem could be solved in the same way. This could help to see if this is different issue or not.

[ltning]

I've attached the log file here. It seems like wifibox (the script) believes the VM is up and all is hunk-a-dory, but .. it is not. wifibox console connects but gives no output/reaction.

When it reaches 2022-08-14T22:22:04+0200 INFO End: wifibox start bhyve is already churning away at 100% of a CPU core.

wifibox.log

[pgj]

@ltning is this still an issue? Could you please test it again with a more recent development version (e.g. 20230916) from pgj/freebsd-wifibox-port?

[pgj]

I am now closing this in lack of response. Please re-open it and open a new issue if this shows up on recent versions.