This problem is already solved, but I thought I would describe it for posterity.
I had a small form factor device, Jetway JBC373 Intel Atom D525, running first pfsense then opnsense right up to FreeBSD 11.1, acting as the main broadband router, decoding the PPPoE from the ISP. The device would lock up and then drop the PPPoE connection and break the session, forcing a restart after the device itself started responding. I noted the issue seemed to occur when both children were at home streaming video and starting watching the output of systat -vm during this episodes, I noted this always corresponded to a massive spike in the number of HPET interrupts, getting up to around 1150 per second, with about 50% CPU spent in interrupts and a nearly completely unresponsive system.
After a bit of google searching, I noted that more a few people were obliged to disable HPET to recover a locked machine and I tried that via
That did work to eliminate the issue, but it also slowed down the interactive response time of the system, both in the shell and the web interface. A bit more research found the suggestion that the right thing to was disable the MSI-X migration capability via
and that was more effective. That eliminated the issue and maintained reasonsable latency in the CLI and web interface. I am unsure if implies a bug in the motherboard or a bug in FreeBSD, but that's a solution for anyone else.
I had a small form factor device, Jetway JBC373 Intel Atom D525, running first pfsense then opnsense right up to FreeBSD 11.1, acting as the main broadband router, decoding the PPPoE from the ISP. The device would lock up and then drop the PPPoE connection and break the session, forcing a restart after the device itself started responding. I noted the issue seemed to occur when both children were at home streaming video and starting watching the output of systat -vm during this episodes, I noted this always corresponded to a massive spike in the number of HPET interrupts, getting up to around 1150 per second, with about 50% CPU spent in interrupts and a nearly completely unresponsive system.
After a bit of google searching, I noted that more a few people were obliged to disable HPET to recover a locked machine and I tried that via
hint.hpet.0.clock=0 That did work to eliminate the issue, but it also slowed down the interactive response time of the system, both in the shell and the web interface. A bit more research found the suggestion that the right thing to was disable the MSI-X migration capability via
machdep.disable_msix_migration=1and that was more effective. That eliminated the issue and maintained reasonsable latency in the CLI and web interface. I am unsure if implies a bug in the motherboard or a bug in FreeBSD, but that's a solution for anyone else.