September 2019 - Wine-Bugs - list.winehq.org

[Bug 47695] Colony prospector (Steam) need unimplemented function msvcrt.dll._ftol2_sse

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47695 Giovanni Mariani <mc2374(a)mclink.it> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Giovanni Mariani <mc2374(a)mclink.it> --- (In reply to Piotr Caban from comment #1) > There's something wrong with this report. The _ftol2_see function is > implemented since wine 1.5.20 (Dec 2012). You are right: after your comment I checked my wine setup and indeed I had a rogue msvcrt.dll "native,builtin" in it; changing it fixes this particular issue. Closing and sorry for all the fuss... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 47855] New: Run tests in more than one VM at a time

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47855 Bug ID: 47855 Summary: Run tests in more than one VM at a time Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Some Wine tests have pretty stringent timing requirements: * Some audio tests play a short sound bite and make sure the playback lasted for the expected time within a few tens of seconds as a way to ensure audio is played at the right rate. But VMs are not always very good at respecting precise timing requirements when there is other activity on the host. * Some tests (msi) generate quite a bit of disk traffic and take a while to run. Running two of those simultaneously can sometimes push them over the 2 minutes limit, causing them to time out. That said there may be something else afoot here as these run times vary from ~20s to ~100s depending on the VM for seemingly no reason. As a consequence the TestBot is configured to only do one thing at a time: run at most one test or revert one VM. This is at odds with hardware evolution and new TestBot requirements: * SSDs are much faster than hard drives and thus should solve the disk bottleneck issues. * The builds for the Wine VMs take a lot more time than just producing PE executables for the Windows VMs. To speed up compilation it is necessary to increase the parallelism which means buying a machine with as many cores as possible and assigning as many as possible to the Wine VMs. * But while running single threaded tests in a single VM on a quad-core machine is bad enough, doing the same thing on a 16+ threads machine would truly be a waste. So a way to be able to run tests in more than one VM at a time should be found. The first step would be to verify that these issues still exist (this means distinguishing them from the usual random failures). If they don't then problem solved! Otherwise CPU-pinning is a solution that's usually mentioned in gaming circles. The questions are: * Would it actually help? * How to integrate it with the TestBot. Is this something that should be configured through Libvirt when restoring a live snapshot? Or is this something that should be defined 'statically' in the VM's configuration? * What happens if two VMs are pinned to the same CPU core? Will Libvirt prevent us from starting both at the same time or is it up to the TestBot Engine to make sure this does not happen? How? * What happens when a VM that's is pinned to CPU core 7 is moved to a 4 core host? Is the pinning ignored or does the administrator have to manually change its configuration? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 41783] FlatOut 2 crashes

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=41783 Bug 41783 depends on bug 24983, which changed state. Bug 24983 Summary: Multiple applications need support for DXTn texture compression in D3DXLoadSurfaceFromMemory() (Space Rangers 2, Memento Mori, fr-043) https://bugs.winehq.org/show_bug.cgi?id=24983 What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 24983] Multiple applications need support for DXTn texture compression in D3DXLoadSurfaceFromMemory() (Space Rangers 2, Memento Mori, fr-043)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=24983 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |376182062ff1ab8e7835fd67bc6 | |50da83c2cc75d Status|STAGED |RESOLVED --- Comment #34 from Matteo Bruni <matteo.mystral(a)gmail.com> --- This bug should be fixed now. Please open new bugs if there are still issues with the affected games. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 39442] Using Spice required to avoid failure in mmdevapi:capture

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=39442 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- All VMs use Spice now, including the Windows 10 ones, the only exception being wtbwvista (probably because it has not been updated in a long time). I don't see the failures mentioned in the original report anymore. There is still a couple failure on Windows 7 but it happens on real hardware too (see the Windows 8 tests on cw-rx460). So it's not related to VNC vs. Spice. capture.c:395: Test marked todo: only PulseAudio gets here capture.c:414: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 Windows 10 >= 1709 also has some failures (one of which happens on real hardware) but again that does not looks related to the original errors. So I think this is fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 47695] Colony prospector (Steam) need unimplemented function msvcrt.dll._ftol2_sse

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47695 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com --- Comment #1 from Piotr Caban <piotr.caban(a)gmail.com> --- There's something wrong with this report. The _ftol2_see function is implemented since wine 1.5.20 (Dec 2012). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 47854] New: Block Windows 10 updates

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47854 Bug ID: 47854 Summary: Block Windows 10 updates Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Windows Updates can interfere with the Wine tests in many ways: * By causing disk traffic they could slow down some tests, causing them to time out. (Some Wine tests are already somewhat slow. Obviously making them faster and/or improving QEmu's disk performance would be great but barring that preventing undue external disk traffic is necessary) * Windows installing an update at the same time WineTest is testing MSI installs could cause interference. * There is also a risk of Windows scheduling a reboot during a test, or popping up a window asking to reboot during Wine's windowing tests. And in any case Windows Updates are a waste of CPU, network and disk bandwidth since VMs will be reverted as soon as the test is completed. For these reasons pre-Windows 10 versions are configured with Windows updates disabled. But for Windows 10 that's not possible. So instead the 'Windows Update' service is disabled. However that does not survive reboots. So LibvirtTool could maybe run a command to re-disable that service when it creates a live snapshot. That command could also be repeated in WineRunTask before starting the tests. Also for Windows 10 >= 1703 it is possible to set the network connection to metered mode. This appears to prevent updates no matter what limit is set which means it's preferable to set a large limit to avoid notifications abut being past the limit. To set the network connection in metered mode: * In Windows >= 1703: Settings -> Ethernet -> Ethernet (Connected) -> 'Set as metered connection'. * In Windows >= 1809 This page also describes a regedit based approach. It's unclear if it works with older Windows 10 versions. https://www.winhelponline.com/blog/ethernet-metered-connection-windows-10-d… [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\DefaultMediaCost] "Ethernet"=DWORD:2 Note that this requries changing the ownership on DefaultMediaCost to the Administrators group and then back to its original owner, TrustedInstaller, aka "NT Service\TrustedInstaller" (use those Advanced buttons). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 47836] Crash when opening a clippings document type in Logos Bible Software

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47836 --- Comment #2 from m0rvj <johnpgoodman(a)gmail.com> --- Created attachment 65356 --> https://bugs.winehq.org/attachment.cgi?id=65356 Terminal from crash when tried to open a clippings file -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 47731] World of Warcraft BFA Crash with error 132 Memory could not be read.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47731 --- Comment #24 from Sveinar Søpler <cybermax(a)dexter.no> --- (In reply to Steve Ebey from comment #23) > Still crashed. Not sure what else to try. Not really sure what else to try. Might try toggling the BIOS option IOMMU to see if it is creating some weirdness, but i doubt it would be that. > Quote from https://download.nvidia.com/XFree86/Linux-x86_64/340.104/README/dma_issues.… On AMD's AMD64 platform, the size of the IOMMU can be configured in the system BIOS or, if no IOMMU BIOS option is available, using the 'iommu=memaper' kernel parameter. This kernel parameter expects an order and instructs the Linux kernel to create an IOMMU of size 32 MB^order overlapping physical memory. If the system's default IOMMU is smaller than 64 MB, the Linux kernel automatically replaces it with a 64 MB IOMMU. To reduce the risk of stability problems as a result of IOMMU space exhaustion on the X86-64 platform, the NVIDIA Linux driver internally limits its use of these interfaces. By default, the driver will not use more than 60 MB of IOMMU space, leaving at least 4 MB for the rest of the system (assuming a 64 MB IOMMU). I only mention this, as the use of "IOMMU" has come up as a troubleshooting thing on various DXVK posts. It might not be in the right direction, but probably will not hurt to try? :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019

[Bug 47822] Transcendence crashes on exit

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47822 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |40a4c782b7f77534535dfa7bb2a | |97049026fef47 Ever confirmed|0 |1 Component|-unknown |winegstreamer Severity|minor |normal Status|UNCONFIRMED |NEW Summary|In the game Transcendence |Transcendence crashes on |the music stopped working |exit |after upgrading wine to | |4.17 | Keywords| |regression --- Comment #4 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Ferdi from comment #3) > I have the gstreamer plugin packages installed on my system (the good, bad > and ugly ones too) but only the plugins-base is installed as 32 bit package. > > After installing the 32bit plugins-good, music works again. > > But then after closing Transcendence I got a crash from wine. will try to > reproduce later. I can confirm that. To make this report useful, let's make it about that crash. It looks like quartz is being unloaded while still in use. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Sept. 30, 2019