| 1 | | I thought of opening a new ticket, but I think I'll post here for now. A similar issue is occuring with Windows 10 1803 64 bit, running as a guest on Windows 10 1803 64 bit or on Debian 10 64 bit as host. I've observed the issue after Windows 10 1803 was released. On Windows 10 as host, the EMT thread CPU usage, of the VM process, drops if I start another paused VM, but even then the CPU usage is still indicative something is still spinning in the EMT thread. In full spin, the CPU usage is higher of the EMT thread is higher on the Windows 10 host, consuming 100% of the processing time of one CPU core. I'm attaching a log from the Debian host, but also a screenshot of some process profiling done with Visual Studio, on an OSE build VirtualBox process, some time ago, running Windows 10 1803 64 bits as guest. You should be able to reproduce this just by booting the installation ISO and letting it reach the first setup GUI. This issue doesn't occur with Windows 10 1709. |
| | 1 | I thought of opening a new ticket, but I think I'll post here for now. A similar issue is occuring with Windows 10 1803 64 bit, running as a guest on Windows 10 1803 64 bit or on Debian 10 64 bit as host. I've observed the issue after Windows 10 1803 was released. On Windows 10 as host, the EMT thread CPU usage, of the VM process, drops if I start another paused VM, but even then the CPU usage is still indicative something is still spinning in the EMT thread. In full spin, the CPU usage is higher of the EMT thread is higher on the Windows 10 host, consuming 100% of the processing time of one CPU core. I'm attaching a log from the Debian host, but also a screenshot of some process profiling done with Visual Studio, on an OSE build VirtualBox process, some time ago, booting the Windows 10 1803 and 1709 64 bits ISOs, with the same VM uptime for both VM instances. You should be able to reproduce this just by booting the installation ISO and letting it reach the first setup GUI. This issue doesn't occur with Windows 10 1709. |
