Paul V. wrote:
As we are slowly progressing towards a more green test.winehq.org there are still some conformance tests that fail either on all platforms or with a specific configuration (like IE7).
Here's some data. On my new box (CPU: Core 2 Duo e8400, graphics: nVidia Corporation GeForce 8500 GT (rev a1) window manager: metacity 2.25.0 built from source) distro: 32 bit Hardy), out of 212 full runs of 'make -k test', here's a count of failures by test name:
6 d3d9 device 6 comdlg32 printdlg 8 wininet http 14 kernel32 thread 19 comctl32 tooltips 24 ddraw visual 32 riched20 editor 46 user32 win 137 user32 input 215 user32 msg 216 dsound ds3d 216 winmm wave 216 urlmon protocol 216 dsound ds3d8
In my perfect world, those tests would all pass, every time, even if you ran them 100 times. That would make patchwatcher a lot more useful, since then it wouldn't have to blacklist these tests.
Here's a little script to tickle just the flaky tests I found:
#!/bin/sh try() { cd dlls/$1/tests rm $2.ok make $2.ok cd ../../.. } set -e set -x while true do try comctl32 tooltips try comdlg32 printdlg try d3d9 device try ddraw visual try dsound ds3d8 try kernel32 thread try riched20 editor try user32 input try user32 win try wininet http done
This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup? - Dan
On Sat, Sep 6, 2008 at 7:43 AM, Dan Kegel dank@kegel.com wrote:
This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup?
Ask Alexandre for a Ghost image of his machine. =P
Dan Kegel schrieb:
This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup?
- Dan
These tests run without any issue for me (200 times) - in virtual desktop mode and fbo (haven't checked the default settings yet): comdlg32 printdlg dsound ds3d8 riched20 editor wininet http
kernel32 thread: This crashes randomly.
comctl32 tooltips: This fails always in virtual desktop mode but in full screen mode the test runs without problems, it only fails if I move the mouse.
d3d9 device: This works with OffscreenRenderingMode = backbuffer or pbuffer without any problems. But with fbo it always crashes.
ddraw visual: This works with OffscreenRenderingMode = backbuffer. But not with pbuffer and fbo (random error).
user32 input: If I move the mouse in the upper left corner the test fails. It always fails if "Allow the window manager to control the windows" is enabled (this is the default, isn't it?) otherwise it runs fine.
user32 win: This always fails.
Cheers Rico
2008/9/6 Rico Schüller kgbricola@web.de:
Dan Kegel schrieb:
This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup?
- Dan
d3d9 device: This works with OffscreenRenderingMode = backbuffer or pbuffer without any problems. But with fbo it always crashes.
ddraw visual: This works with OffscreenRenderingMode = backbuffer. But not with pbuffer and fbo (random error).
I know there are some issues with FBOs in recent nvidia drivers, but personally I haven't seen these crashes since commit 4b6887b8e374826156305094ba547b42b5673da5. I just ran d3d9 device & ddraw visual for an hour without crashing or failures.
For what it's worth: OpenGL renderer string: GeForce Go 7900 GS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 177.70 KDE 3.5.9 on Gentoo
Henri Verbeet schrieb:
2008/9/6 Rico Schüller kgbricola@web.de:
Dan Kegel schrieb:
This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup?
- Dan
d3d9 device: This works with OffscreenRenderingMode = backbuffer or pbuffer without any problems. But with fbo it always crashes.
ddraw visual: This works with OffscreenRenderingMode = backbuffer. But not with pbuffer and fbo (random error).
I know there are some issues with FBOs in recent nvidia drivers, but personally I haven't seen these crashes since commit 4b6887b8e374826156305094ba547b42b5673da5. I just ran d3d9 device & ddraw visual for an hour without crashing or failures.
For what it's worth: OpenGL renderer string: GeForce Go 7900 GS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 177.70 KDE 3.5.9 on Gentoo
I updated my drivers but it is the same thing.
d3d9 device uses 100%cpu (didn't go further) and I have to kill them in test_depthstenciltest(). This is the problematic code (only with fbo): hr = IDirect3DDevice9_SetDepthStencilSurface(pDevice, NULL); ok(hr == D3D_OK, "IDirect3DDevice9_SetDepthStencilSurface failed with %08x\n", hr);
ddraw visual fails in "if(!D3D1_createObjects()) {" and in "D3D3_ViewportClearTest();" with a crash. I'll take a closer look at this two things.
OpenGL renderer string: GeForce 8800 GTS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 177.70 gnome 2.22.3 on FC9 (x86_64)
Henri Verbeet schrieb:
2008/9/6 Rico Schüller kgbricola@web.de:
Dan Kegel schrieb:
This aborts for me in just five seconds. Can *anyone* run it for an hour without failure? If so, how can I duplicate your setup?
- Dan
d3d9 device: This works with OffscreenRenderingMode = backbuffer or pbuffer without any problems. But with fbo it always crashes.
ddraw visual: This works with OffscreenRenderingMode = backbuffer. But not with pbuffer and fbo (random error).
I know there are some issues with FBOs in recent nvidia drivers, but personally I haven't seen these crashes since commit 4b6887b8e374826156305094ba547b42b5673da5. I just ran d3d9 device & ddraw visual for an hour without crashing or failures.
For what it's worth: OpenGL renderer string: GeForce Go 7900 GS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 177.70 KDE 3.5.9 on Gentoo
It's exactly that patch which broke this test for me!
Cheers Rico