CodeWeavers has two machines that I have been running WineTest on, in Linux, Windows 8.1 and Windows 10, in 32 and 64 bit. They are identical except for the graphics cards: AMD HD6800 for cw1 and Nvidia GTX560 for cw2. During WineConf we decided that these should be able to run WineTest on Linux without any errors and thus become reference WineTest machines. We are not quite there yet so here is the current status starting with the 32 bit tests. * crypt32:chain Some of the certificates used by this test are present on Windows but missing on Linux, thus causing the error. Hans is looking into it and either the test will be modified to use other certificates present on both platforms, or the certificates will be added to these boxes. In the latter case this will be documented on the Wiki: https://wiki.winehq.org/Conformance_Tests#Running_WineTest_in_Wine * d2d1:d2d1, d3d10core:device These tests only fails on the GTX560. The reason is unknown. We need someone to look into it. * d3d8:device, d3d9:d3d9ex, d3d9:device, d3d9:visual Matteo fixed the radeon driver configuration and is looking into these failures, at least for the HD6800 case. It is possible some of these failures are caused by the window manager (currently xfwm from Xfce). Replacing the windows manager is no issue, we just need to know which one to pick. fvwm2? * kernel32:console, kernel32:process These failures happen because the tests are being run from cron, with their output redirected to a log file and thus they have no real terminal to work with. Interestingly the 64 bit tests are not failing. Vincent is investigating whether the tests should be modified or whether the test should be run from an xterm, screen session or some equivalent. * user32:winstation winstation.c:959: Test succeeded inside todo block: unexpected foreground window (nil) The cause for this failure has not been identified. Another window manager issue? * ws2_32:sock sock.c:2811: Test succeeded inside todo block: Test[2]: expected 0, got 0 We need someone to investigate this failure. It looks like it's random and relatively rare. Some tests just cannot be made to work reliably on Linux due to the asynchronous nature of X11 messaging. So another decision that was made that tests should be run up to 3 times until they succeed. It's not entirely clear if that applies to all tests or just to specific tests that are known to be flaky. The practical upshot is that people running 'make test' can re-run it a couple of times if it fails at first, and if it succeeds after 3 tries then you can consider that it's all good. These machines run WineTest so the results can be uploaded to test.winehq.org (with the relevant header describing the machine, the dlls, etc). So WineTest may need to be updated to deal with flaky tests according to policy. Here is more detail about these machines: * i7-2600K (4 cores+hyperthreading at 3.4GHz) * 16 GB of RAM * 768 GB of spinning disk * Debian 8.2 64 bit * cw1: AMD HD6800 running the open-source radeon driver. * cw2: Nvidia GTX560 running the proprietary driver. -- Francois Gouget <fgouget(a)codeweavers.com>
2016-11-19 18:02 GMT+01:00 Francois Gouget <fgouget(a)codeweavers.com>:
* d3d8:device, d3d9:d3d9ex, d3d9:device, d3d9:visual Matteo fixed the radeon driver configuration and is looking into these failures, at least for the HD6800 case.
It is possible some of these failures are caused by the window manager (currently xfwm from Xfce). Replacing the windows manager is no issue, we just need to know which one to pick. fvwm2?
FWIW, for the AMD box all those test failures but one in d3d9:visual are window messages-related and probably affected by the WM. Do you want to give a try to fvwm2 and see what happens? :D
On Tue, 22 Nov 2016, Matteo Bruni wrote: [...]
FWIW, for the AMD box all those test failures but one in d3d9:visual are window messages-related and probably affected by the WM.
Do you want to give a try to fvwm2 and see what happens? :D
Sure. I installed fvwm 1:2.6.5.ds-3 and that should now be used by default. Note that if you access the winetest account through the KVM things are now really bare. But you can access the fvwm menu through a left click and from there start an xterm. By the way, cw1 froze while running the 64 bit tests on Windows 10. The last traces we have are from kernel32:comm but with buffering the crash may have happened somewhat after that. I have uploaded the traces there and scheduled another run on Windows 10: http://fgouget.free.fr/tmp/cw1-winetest64-20161122.log http://fgouget.free.fr/tmp/cw1-winetest64-20161122.report Regarding the logs, do we have enough flushing to ensure we don't lose traces? -- Francois Gouget <fgouget(a)codeweavers.com>
Am 22.11.2016 um 14:31 schrieb Francois Gouget <fgouget(a)codeweavers.com>:
On Tue, 22 Nov 2016, Matteo Bruni wrote: [...]
FWIW, for the AMD box all those test failures but one in d3d9:visual are window messages-related and probably affected by the WM.
Do you want to give a try to fvwm2 and see what happens? :D
Sure. I installed fvwm 1:2.6.5.ds-3 and that should now be used by default. Note that if you access the winetest account through the KVM things are now really bare. But you can access the fvwm menu through a left click and from there start an xterm. Fwiw, I didn’t forget that I said I’d look into those :-) . But first I need bring my Non-Nvidia box back to life, which will take a while. On The Nvidia laptop I have mysterious mode setting problems with xfce, and I think they’re related to our fallback to randr 1.1.
The tests pass for me on KDE. Back when I wrote them they were reliable on fvwm2 when the focus behavior was set to click to focus. The default focus follows mouse works or fails depending on which windows you have in the top left corner of the screen. An early device.c test in d3d8/9 sets the mouse to 50/50, so the mouse position is somewhat deterministic unless you touch it while the test is running.
On Tue, 22 Nov 2016, Francois Gouget wrote:
On Tue, 22 Nov 2016, Matteo Bruni wrote: [...]
FWIW, for the AMD box all those test failures but one in d3d9:visual are window messages-related and probably affected by the WM.
Do you want to give a try to fvwm2 and see what happens? :D
Sure. I installed fvwm 1:2.6.5.ds-3 and that should now be used by default.
fvwm is using 'focus follows mouse' by default. I reconfigured it to 'click to focus' and will rerun the tests. Note that we did not get the WoW tests. I looked at wt-bot-cw1-hd6800-wow32.report and it looks like the X server (or fvwm) crashed: Starting up err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly. Error: Unable to create a window, the display driver is not working. Command exited with non-zero status 1 We'll see if it still happens with click to focus. -- Francois Gouget <fgouget(a)codeweavers.com>
On Wed, 23 Nov 2016, Francois Gouget wrote: [...]
Note that we did not get the WoW tests. I looked at wt-bot-cw1-hd6800-wow32.report and it looks like the X server (or fvwm) crashed:
Starting up err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly. Error: Unable to create a window, the display driver is not working. Command exited with non-zero status 1
We'll see if it still happens with click to focus.
I think I found why the X server was disppearing: lightdm sometimes fails to autologin so I have a script that checks whether the Xfce session is running which restarts lightdm if not. But now that it's fvwm instead of Xfce I had to update the script. I also tweaked wt-daily to better detect when the tests don't complete or the report upload fails and to not count the tests as done in those cases. That will give them another chance to run should the X server really crash. So we still have a failure for d3d9:device and d3d9:visual. Are those still related to the window manager? -- Francois Gouget <fgouget(a)codeweavers.com>
2016-11-24 19:00 GMT+01:00 Francois Gouget <fgouget(a)codeweavers.com>:
So we still have a failure for d3d9:device and d3d9:visual. Are those still related to the window manager?
The d3d9:device failure seems to have disappeared in the latest two builds. Let's see if that sticks. The visual test failure is not WM-related. It has to do with NaN handling in GLSL shaders and it's probably a driver bug (for reference, I can reproduce it here and it disappears when running the test with R600_DEBUG=nosb). I never got around to trying to figure out the issue, maybe I'll manage to this time...
Am 2016-11-25 um 23:41 schrieb Matteo Bruni:
The d3d9:device failure seems to have disappeared in the latest two builds. Let's see if that sticks. The d3d9:device failure in 703080afb4c9 seems to be different from the window minimization problems:
device.c:1781: Test failed: The cursor handle is 0x10022 That failure poped up in 2 of the 3 test runs of that build, and was a come-and-go in the previous tests, so I guess it is random and still needs to be fixed.
Am 2016-11-26 um 09:27 schrieb Stefan Dösinger:
device.c:1781: Test failed: The cursor handle is 0x10022
That failure poped up in 2 of the 3 test runs of that build, and was a come-and-go in the previous tests, so I guess it is random and still needs to be fixed. Yeah, they're still coming and going in d3d8:device and d3d9:device. I'll have a look.
Are the rest of the tests happy with fvwm2 in click-to-focus mode? Is it a configuration that's reasonable to keep? (Yeah, I realize we'll want to fix other configurations as well...)
On 19 November 2016 at 18:02, Francois Gouget <fgouget(a)codeweavers.com> wrote:
* d2d1:d2d1, d3d10core:device These tests only fails on the GTX560. The reason is unknown. We need someone to look into it.
For what it's worth, the d2d1 failure is somewhat of a known issue. We investigated it a while back, and it looks like it's perhaps a hardware floating point precision issue. Compare the rectangle in the centre of the CAYMAN (good) and NV50 (bad) output attached to this mail. The solution would likely be to depend less on the hardware's internal floating point precision, perhaps by slightly modifying the transformation matrix.
participants (4)
-
Francois Gouget -
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger