Just tested on my own ASRock X370 Gaming K4 platform with arch and 4.16.3 kernel and I can’t reproduce this Virtualbox behavior.
It just works, even when I break the clocksource into hpet mode. Hpet is real slow btw.
This btw is the full extent of iommi kernel events when dealing when starting a VBox VM in my system.
Is indeed hpet. Can you tell me/link me to more information about this?
As for Vbox I’m not exactly sure what’s going on there. It’s creating IOMMU domains and freeing them before the log ends. Chances are that the log is also not fully written out to disk when the crash occurs.
I just want to be clear that it’s the virtual machine that hangs, not the host machine. I’ve not been able to access any of the virtual machines over SSH, one of those demonstrated in the video is a vagrant machine which fails to provision as it always hangs before SSH is started.
Also I think that the IOMMU domains are being created/destroyed correctly, it was just hard to see in the earlier log, when looking at the output of journalctl you can see those actions were a few minutes apart, enough time to start the machine and for it to hang:
Apr 23 20:07:16 smeg kernel: VBoxNetFlt: attached to 'vboxnet0' / 0a:00:27:00:00:00
Apr 23 20:07:16 smeg kernel: device vboxnet0 entered promiscuous mode
Apr 23 20:07:16 smeg kernel: vboxdrv: 0000000001a6ec03 VBoxDDR0.r0
Apr 23 20:07:16 smeg kernel: vboxpci: created IOMMU domain 00000000746b3096
Apr 23 20:12:53 smeg kernel: vboxpci: freeing IOMMU domain 00000000746b3096
Apr 23 20:13:00 smeg kernel: device vboxnet0 left promiscuous mode
Apr 23 20:13:00 smeg kernel: vboxnetflt: 0 out of 4 packets were not sent (directed to host)
The fact that it’s the VM that hangs is crucial, I was under impression that the entire host crashed.
First lets find a way to get your clocksource onto tsc.
Set your system to baseline stock clocks. It MUST be stable on stock settings and default to tsc again.
If it is not you may well have a hardware (mainboard/cpu) issue at hand.
Yep. I reset to UEFI defaults and enabled CPU virtualisation, now running stock CPU and memory clocks. All three virtual machines featured in the video booted fine first time.
Note how calibration fails twice and then matches first hpet and then acpi_pm.
There’s something up with Ryzen and the clocksource calibration, particularly when overclocking.
Interesting how this has the same timer calibration problem. Then succeeds later.
Something is up with the TSC Calibration code for Ryzen, in particular when overclocking via the BIOS things go out of whack.
Unfortunately kernel timers is not my specialty, I know enough to poke around but this may require an expert to review what exactly is going on here.
Of Note:
On an Intel Ivy Bridge system, not even a single failure of any sort.
Yeah this is pretty much narrowed down to clocksource calibration now.
VM’s in particular are sensitive to this.
Possibly somewhere in between the BIOS update, tsc calibration and overclocking something has broken for sure. I do remember that TSC calibration wasn’t always an issue. On early BIOS versions I had some mad overclocks + running VM’s without any timer issues.
So, I updated the ASRock x370 Taichi BIOS 4.60 to 4.70, and also updated the kernel. Now I have this exact same problem. I suspect the BIOS update caused it.
Performance in my Win10 VM in VirtualBox now sucks.
Not sure if you resolved the issue but I ran into the same issue last night after upgrading from v3.2 to v3.4/v4.90. Stumbled upon your thread to confirm I wasn’t the only one with this issue thought I am using windows instead of linux. But I was also using virtualization for linux… though window vm was having the same performance issue.
created 3 threads in reddit but didn’t get an answer.
You must flash to bridge 3.4 and then to a stable firmware… for me that was v3.2… I don’t trust v3.3
I hope this helps.
I’m running windows 10 pro 1803
System details: Graphics Chipset - Radeon ™ RX 480 Graphics Windows Version - Windows 10 (64 bit) System Memory - 16 GB CPU Type - AMD Ryzen 5 1600 Six-Core Processor