https://bugs.winehq.org/show_bug.cgi?id=40191
Bug ID: 40191 Summary: ntdll:rtl test regression Product: Wine Version: 1.9.3 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
The commit below introduced a test failure on Windows 8, 8.1 and 10.
Failure: rtl.c:2079: Test failed: expected SpinCount == 0, got 33556432
ntdll:rtl results on test.winehq.org: https://test.winehq.org/data/tests/ntdll:rtl.html
commit 2689b7b1be096c8b7755ac3e75d2d366cb3debab Author: Sebastian Lackner sebastian@fds-team.de Date: Tue Feb 16 08:41:21 2016 +0100
ntdll/tests: Add tests for RtlInitializeCriticalSectionEx.
Signed-off-by: Sebastian Lackner sebastian@fds-team.de Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=40191
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase URL| |https://test.winehq.org/dat | |a/tests/ntdll:rtl.html Regression SHA1| |2689b7b1be096c8b7755ac3e75d | |2d366cb3debab
https://bugs.winehq.org/show_bug.cgi?id=40191
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- I've sent a patch to fix this issue. I am really wondering though - why are errors like this not visible when doing a manual testbot run / when submitting a patch?
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #2 from François Gouget fgouget@codeweavers.com --- Based on the WineTest results: * It only fails on real hardware and the TestBot only runs it on QEMU VMs. * It fails the same way whether the machine is running Windows 8, 8.1 or 10. * It fails the same way for 32 and 64 bit tests. * In every failing case the the SpinCount value is 33556432 or 0x020007d0. Does this value mean anything?
Maybe it's a CPU topology issue: all VMs emulate a dual single-core processor systems while the failures happen on single multi-core processor machines.
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #3 from Sebastian Lackner sebastian@fds-team.de --- (In reply to François Gouget from comment #2)
Based on the WineTest results:
- It only fails on real hardware and the TestBot only runs it on QEMU VMs.
- It fails the same way whether the machine is running Windows 8, 8.1 or 10.
- It fails the same way for 32 and 64 bit tests.
- In every failing case the the SpinCount value is 33556432 or 0x020007d0.
Does this value mean anything?
Maybe it's a CPU topology issue: all VMs emulate a dual single-core processor systems while the failures happen on single multi-core processor machines.
The exact value of SpinCount does not matter in this case and the test was written to show a different aspect (mainly the DebugInfo field) - so marking this behavior on Win 8+ as broken should be fine.
Most likely it has to do with the different number of cores, spin-locking is only useful on multiprocessor systems. Nevertheless, is there any chance that we could also get a testbot VM with more than one core, to find such issues a bit earlier in the future? It could also be interesting for other synchronization related functions which might behave different on multiprocessor systems.
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- (In reply to Sebastian Lackner from comment #3)
The exact value of SpinCount does not matter in this case and the test was written to show a different aspect (mainly the DebugInfo field) - so marking this behavior on Win 8+ as broken should be fine.
That's OK for now, but I don't think it can legitimately be considered broken. It looks like 0 means use a default spin count, which we'll probably want to support at some point.
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Alexandre Julliard from comment #4)
(In reply to Sebastian Lackner from comment #3)
The exact value of SpinCount does not matter in this case and the test was written to show a different aspect (mainly the DebugInfo field) - so marking this behavior on Win 8+ as broken should be fine.
That's OK for now, but I don't think it can legitimately be considered broken. It looks like 0 means use a default spin count, which we'll probably want to support at some point.
My understanding is that Wine currently targets more Win 7 than Win 8+, and there a value of 0 consistently sets SpinCount = 0, even on multicore systems (at least my systems, and I'm not aware of any test failures). Of course broken() doesn't mean that we'll not consider implementing it, when we change our focus to new Windows versions or have applications which depend on it.
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- (In reply to Sebastian Lackner from comment #5)
My understanding is that Wine currently targets more Win 7 than Win 8+, and there a value of 0 consistently sets SpinCount = 0, even on multicore systems (at least my systems, and I'm not aware of any test failures). Of course broken() doesn't mean that we'll not consider implementing it, when we change our focus to new Windows versions or have applications which depend on it.
Wine does not "target" a Windows version, and there's no reason not to implement a Win8 behavior if it's considered useful. Of course we don't need this right now, and it's unlikely that an app is going to break because of this, so it doesn't make much difference. But in general, broken() should be only for things that we consider undesirable to implement, also in the future.
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #7 from François Gouget fgouget@codeweavers.com --- I have done tests with the w8 QEMU VM and they confirmed that this issue is related to single-core vs. multi-core/hyperthreading: * The tests succeed on single-core processors, * and fail if the processor has either multiple cores or hyperthreading.
With these tests I also discovered that Windows 8 (standard Home edition) will only use one processor, instead of up to two for all versions up to Windows 7.
This means that currently all Windows 8+ VMs only use a single single-core processor. I have now changed the w8 VM configuration to a single dual-core non-hyperthreading processor.
Here's the new result: https://testbot.winehq.org/JobDetails.pl?Key=20836
https://bugs.winehq.org/show_bug.cgi?id=40191
--- Comment #8 from François Gouget fgouget@codeweavers.com --- Final notes from my TestBot timeline: * Configuring a QEMU VM to have 'two logical CPUs' results in a dual processor machine by default. However regular versions of Windows (i.e. non-Pro / Enterprise) are restricted to only use a single CPU. They will start on multi-processor machines but make use of only one. This is not an issue for our Windows 7 VMs as Pro and Ultimate versions can use up to two processor. But our Windows 8 and 10 VMs use regular editions. So they need QEMU to be configured with a single multi-core processor instead to properly test 'SMP' configurations. * On Windows 8+ the SpinCount value of the RtlInitializeCriticalSectionEx() tests in ntdll:rtl is different on a multi-core or hyperthreaded CPU than on a single single-core non-hyperthreaded one. On Window s7 SpinCount is 0 no matter what the processor configuration: multi-processor, multi-core or hyperthreading. So this is a Windows 8+ thing. On Windows 8 SpinCount may also take non-zero values on systems with multiple single-core non-hyperthreaded processors but we cannot test that configuration. * I changed wtbw8 to use a single dual-core processor. wtbwvista, wtbw864 and wtbw1064 will need similar changes.
https://bugs.winehq.org/show_bug.cgi?id=40191
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |dcf914857c1e29b64a31a67685b | |123a09db1bae1 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #9 from Sebastian Lackner sebastian@fds-team.de --- (In reply to François Gouget from comment #8)
Final notes from my TestBot timeline:
- Configuring a QEMU VM to have 'two logical CPUs' results in a dual
processor machine by default. However regular versions of Windows (i.e. non-Pro / Enterprise) are restricted to only use a single CPU. They will start on multi-processor machines but make use of only one. This is not an issue for our Windows 7 VMs as Pro and Ultimate versions can use up to two processor. But our Windows 8 and 10 VMs use regular editions. So they need QEMU to be configured with a single multi-core processor instead to properly test 'SMP' configurations.
- On Windows 8+ the SpinCount value of the RtlInitializeCriticalSectionEx() tests in ntdll:rtl is different on a multi-core or hyperthreaded CPU than on a single single-core non-hyperthreaded one. On Window s7 SpinCount is 0 no matter what the processor configuration: multi-processor, multi-core or hyperthreading. So this is a Windows 8+ thing. On Windows 8 SpinCount may also take non-zero values on systems with multiple single-core non-hyperthreaded processors but we cannot test that configuration.
- I changed wtbw8 to use a single dual-core processor. wtbwvista, wtbw864
and wtbw1064 will need similar changes.
We do not necessarily have to adjust all VMs, I think its just good to test with a big variety of different systems, to catch test failures as early as possible.
Since http://source.winehq.org/git/wine.git/commit/dcf914857c1e29b64a31a67685b123a... the test failure should be gone, so marking this bug as FIXED.
https://bugs.winehq.org/show_bug.cgi?id=40191
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.5.
-
wine-bugs＠winehq.org