This week I tweaked the configuration of some VMs. Specifically:
* All Windows 7+ VMs now use Spice for 'display'; remote access really and it goes further than just display like VNC, it also includes forwarding the audio to the client and more.
But none of this should matter really since nobody connects to the VMs while they are running the tests. Still switching the remoting method from VNC to Spice fixes a bunch of audio tests!
If I remember correctly we only had two holdouts: w7u and w8. So we'll see if their test results improve (those of this friday may not reflect the new state 100% yet).
* w7pro64 and w864 seem to be doing reasonably well sound-wise: w864 does have one failure in the 64 bit mmdevapi:capture & render but not in the 32 bit ones. The w1064 results are not so rosy but it's Windows 10 so it's still kind of expected. So maybe removing the soundcard from 64 bit VMs won't be necessary? I'll let Hans and Andrew verify.
* All Windows 7+ VMs also got a new beta TestAgentd which is no longer run from an iconized cmd window. Instead it simply detaches from the console and thus runs without a window. This is meant to help with some Direct3D tests and I hope Stefan can remind me of the details.
* I have also created a standalone testcase for the Windows 10 64 bit crash and reported it to QEMU in the hope they can do something about it: https://bugs.winehq.org/show_bug.cgi?id=40240 https://bugs.launchpad.net/qemu/+bug/1658141
* I also created a standalone testcase for the Spice audio issue mentionned above. I added it to the bug I created 15 months ago in the hope it can help someone reproduce and fix the bug. But given that there's no indication anyone even looked at this bug that's probably a foolish hope. https://bugs.winehq.org/show_bug.cgi?id=39442 https://bugs.launchpad.net/qemu/+bug/1499908
* But I think bugs sometimes get fixed: I tried to reproduce the rasapi32:rasapi Windows 8 64 bit bug and couldn't. That probably means it got fixed by last week's QEMU and Linux kernel upgrades. Yay! https://bugs.winehq.org/show_bug.cgi?id=42185
* Tonight the build VM failed to rebuild Wine: https://testbot.winehq.org/JobDetails.pl?Key=27894
It turns out that some build processes fell victim to the OOM killer! I guess the issue is that 512 MB is not always enough for parallel builds, particularly when one process is building an ~80 MB winetest.exe (though when investigating this I also got the issue with makedep once!).
So I splurged and doubled the RAM allocated to the VM. The balloon driver will hopefully prevent that from having too much of a performance impact on snapshot reverts.