https://bugs.winehq.org/show_bug.cgi?id=48052
--- Comment #3 from Jacek Caban jacek@codeweavers.com --- So the actual problem is in get_thread_context(), which is triggered by this test. That's something I plan to look at, it may improve debugger stability as well, but it's not something for the code freeze.
(In reply to François Gouget from comment #2)
Normally all the Home Edition Windows VMs are configured with 1 processor and 2 cores (*). For instance if I open the Resource Monitor in Windows 10 1809 I do see the usage on each of the two CPU cores. I probably kept a single core machine so we do have one like this somewhere.
And the Professional and Server editions should have 2 processors with 1 core each because licensing.
The build and Wine VMs not being encumbered with licensing issues and needing to do builds, they get as many cores as possible. That would be 4 on vm3 and vm4 and 8 (counting hyperthreading) on vm1, but presented as as many single core processors because that' the QEmu default. But I could change that to present a more interesting CPU topology.
We could give the Windows VMs more processors & cores but:
- Given that the tests don't take advantage of multi-threading this does not
seem useful (except for the build and Wine VMs).
- The more cores the fewer concurrent VMs we can hope to one day run
concurrently without interference.
(*) Initially I had just specified 2 cores and let QEmu deal with the topology but then I noticed Windows was reporting a single core. That's when I realized it was because by default QEmu presents each core as a separate processor and Windows licensing did not allow it to use more than one processor.
I found that I was checking it in a wrong way. Still, it's weird that those timeouts happen.