https://bugs.winehq.org/show_bug.cgi?id=48052 --- Comment #3 from Jacek Caban <jacek(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.