https://bugs.winehq.org/show_bug.cgi?id=53227
Bug ID: 53227 Summary: dxgi:dxgi - test_swapchain_present() fails on Windows 10 1709 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
dxgi:dxgi - test_swapchain_present() fails on Windows 10 1709:
dxgi.c:4735: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4737: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4754: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4782: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4784: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4790: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4792: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4814: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4816: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4826: Test failed: Test 0: Got unexpected fullscreen status. dxgi.c:4833: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4839: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4849: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4852: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4856: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4876: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4881: Test failed: Test 0: Got unexpected fullscreen status. dxgi.c:4886: Test failed: Test 0: Got unexpected hr 0x8007000e. dxgi.c:4888: Test failed: Test 0: Got unexpected hr 0x887a0001. dxgi.c:4735: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4737: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4754: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4782: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4784: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4790: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4792: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4814: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4816: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4833: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4836: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4849: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4852: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4856: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4860: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4865: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4867: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4870: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4872: Test failed: Test 1: Got unexpected hr 0x887a0001. dxgi.c:4881: Test failed: Test 1: Got unexpected fullscreen status. dxgi.c:4886: Test failed: Test 1: Got unexpected hr 0x8007000e. dxgi.c:4888: Test failed: Test 1: Got unexpected hr 0x887a0001.
https://test.winehq.org/data/patterns.html#dxgi:dxgi
Note that despite being systematic these failures could cause false positives due to the test multi-threading (see bug 53212).
https://bugs.winehq.org/show_bug.cgi?id=53227
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=53227
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #1 from Eric Pouech eric.pouech@gmail.com --- (In reply to François Gouget from comment #0)
dxgi:dxgi - test_swapchain_present() fails on Windows 10 1709:
dxgi.c:4735: Test failed: Test 0: Got unexpected hr 0x8007000e.
0x800700e is E_OUTOFMEMORY another low memory situation in test env
https://bugs.winehq.org/show_bug.cgi?id=53227
--- Comment #2 from François Gouget fgouget@codeweavers.com --- Created attachment 73683 --> https://bugs.winehq.org/attachment.cgi?id=73683 Memory usage on w1064v1709
I think the issue is that Windows Update is still installing stuff in that VM. It takes a while for it to actually start so it's not obvious right after boot. Also the network connection is metered so it should not be downloading new updates. But I think it already had some updates downloaded and ready to install before the snapshot was taken.
It should still have enough memory: the task manager says "Committed 0.8/4.0 GB" after boot and it never goes above 1.3/4/0 when Windows Update is running. But Windows Update is known to break the tests in weird ways when it runs.
I'll update that snapshot (see 54158) and we'll see if that helps.
https://bugs.winehq.org/show_bug.cgi?id=53227
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- that could explain.
this in fact opens two several questions: 1) how to make sure windows update doesn't interfere with the tests? 2) how to upgrade the snapshots...
1) we could either disable once for all Windows update or let winetest/testbot (not sure which) disable the update service while running the tests (it could even be a better idea to disable more services) 2) this requires a dedicated process, not run when a test is run, for upgrading the snapshot.
but for the stability of the tests, it's also a bad idea to let the snapshot be upgraded without testing what has changed (IMO, this could even be covered by a different snapshot name as we're testing something different)
https://bugs.winehq.org/show_bug.cgi?id=53227
--- Comment #4 from François Gouget fgouget@codeweavers.com --- To answer your questions:
1) In pre-Windows 10 versions the trick was simply to set Windows Update to manual but starting with Windows 10 Microsoft made it impossible to disable Windows Update.
So instead the trick is to set the network connection to metered. Then Windows Update will not be able to download any updates and thus won't do anything (though it may still check for updates to tell you how much you're missing).
The hitch is that apparently one should really wait a bit (5-10 minutes?) after setting the connection to metered to make sure Windows Update is done installing anything it downloaded right before. And maybe a reboot is needed too in case it's not starting the install until a hung download is done.
That process is described in the Wiki (and I may make some adjustments to that page after this): https://wiki.winehq.org/Wine_TestBot_VMs#Windows_configuration
2) The snapshots are not upgraded, at least not from one Windows version to another. For each test configuration there is one powered off snapshot and one or more live snapshots. So for instance for w1064v1709 there is a 1709 powered off snapshot.
What I will do is revert to that snapshot, boot the VM and wait for Windows Update to do its thing, power off the VM and retake the 1709 snapshot (there's actually more like restoring and re-backing up the VM). So after that it's likely that a few dlls will have changed but that should not have much impact. Then the TestBot will recreate the corresponding live snapshot (1709-live).
When a new Windows version comes around I put the VM in maintenance mode to have exclusive access, revert it to the most recent snapshot (e.g. 21H2), turn metering off, apply all Windows updates, go through the full Wiki checklist (upgrades sometimes undo some of the configuration), turn metering back on, and take a new powered off snapshot (e.g. 22H2, + VM backup, etc). Then in the TestBot I add a new 'VM' for that test configuration.
but for the stability of the tests, it's also a bad idea to let the snapshot be upgraded without testing what has changed
The procedure I use now is to configure the TestBot to only run the nightly WineTest suite on the new test configuration; then monitor the WineTest results for failures that the TestBot identifies as new, and add known failure entries (https://testbot.winehq.org/FailuresList.pl) for those so they are not flagged as new anymore. Once the nightly WineTest runs don't produce new failures the test configuration is ready to be marked as a base test configuration that all patches are tested on. Note that during that process developers can manually run jobs on the new test configuration whenever they want.
In the past I could not really follow that procedure because the known failures mechanism did not exist.
https://bugs.winehq.org/show_bug.cgi?id=53227
--- Comment #5 from Eric Pouech eric.pouech@gmail.com ---
That process is described in the Wiki (and I may make some adjustments to that page after this): https://wiki.winehq.org/Wine_TestBot_VMs#Windows_configuration
nice recap... more admin work to do... sigh wonder if some powershell script wouldn't be helpful here
for disabling windows update, it seems I can do it on win10 VM (not pro though)
and from mr!1830, it's likely there's some services opening freshly closed files (can't tell which)
https://bugs.winehq.org/show_bug.cgi?id=53227
--- Comment #6 from François Gouget fgouget@codeweavers.com --- Created attachment 73745 --> https://bugs.winehq.org/attachment.cgi?id=73745 Only keep run_on_d3d12(test_swapchain_present)
(In reply to Eric Pouech from comment #1)
(In reply to François Gouget from comment #0)
[...]
dxgi.c:4735: Test failed: Test 0: Got unexpected hr 0x8007000e.
0x800700e is E_OUTOFMEMORY another low memory situation in test env
The nice thing is that the failure is easy to reproduce by running dxgi:dxgi on its own so I did some tests. * Sadly fixing the "Windows Update not idle" issue did not help. * Also increasing the RAM from 4 GB to 8 and even 12 GB made no difference. * Switching the GPU from VGA to QXL does not help. * Upgrading the QXL driver to 10.0.0.21000 (virtio-win-0.1.221.iso) does not help. * Even switching to the Virtio 'GPU' with the 100.91.104.22100 VirtIO GPU DOD driver makes no difference. * test_swapchain_present() is called twice and it's specifically the un_on_d3d12(test_swapchain_present) case that fails, even if all the rest of the code is commented out. * dxgi:dxgi also crashes systematically on this test configuration but that comes from the Direct3D 12 test_mode_change() case and is unrelated.
So I don't think it's a driver issue but a Windows Direct3D 12 issue on Windows 1709.
https://bugs.winehq.org/show_bug.cgi?id=53227
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #7 from Eric Pouech eric.pouech@gmail.com --- looking again at the results, an unexpected behavior in 1709 only is the most evident answer I don't understand the details the tests, nor if there are other possibilities than just bailing out when we get hese errors we should ask the d3d maintainers about this cc:ing Zebediah and Jan
https://bugs.winehq.org/show_bug.cgi?id=53227
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsikorski@codeweavers.com
-
WineHQ Bugzilla