Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=120073
Your paranoid android.
=== w7u_adm (32 bit report) ===
winmm:
midi.c:1039: Test failed: bad message 1e/0 from midiStreamOut, expect 3c9/22f940
midi.c:1048: Test failed: bad message 3c9/22f940 from midiStreamClose, expect 3c8/0
=== w7u_el (32 bit report) ===
winmm:
midi.c:988: Test failed: bad message 1e/0 from midiStreamOpen, expect 3c7/0
midi.c:1039: Test failed: bad message 3c7/0 from midiStreamOut, expect 3c9/22f940
midi.c:1048: Test failed: bad message 3c9/22f940 from midiStreamClose, expect 3c8/0
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=120071
Your paranoid android.
=== w8adm (32 bit report) ===
ddraw:
ddraw7.c:18888: Test failed: Got unexpected color 0x0000ff00.
=== w864 (32 bit report) ===
ddraw:
ddraw7.c:18888: Test failed: Got unexpected color 0x0000ff00.
=== w1064_tsign (32 bit report) ===
ddraw:
ddraw7.c:18888: Test failed: Got unexpected color 0x00000040.
=== debian11 (32 bit Chinese:China report) ===
Report validation errors:
ddraw1: Timeout
=== debian11 (build log) ===
WineRunWineTest.pl:error: The task timed out
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=120063
Your paranoid android.
=== w10pro64_ja (64 bit report) ===
mshtml:
htmldoc.c:2541: Test failed: unexpected call UpdateUI
htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS
htmldoc.c:350: Test failed: expected Exec_SETTITLE
htmldoc.c:2859: Test failed: unexpected call Exec_SETTITLE
=== w10pro64_zh_CN (64 bit report) ===
mshtml:
htmldoc.c:2541: Test failed: unexpected call UpdateUI
htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS
htmldoc.c:350: Test failed: expected Exec_SETTITLE
htmldoc.c:2859: Test failed: unexpected call Exec_SETTITLE
Hi All,
In the wake of the new WOW64 implementation (recent explanation [1]),
there has been discussion in informal channels about how to we are going
to handle pointers to mapped graphics resource memory which we receive
from the graphics API, as the possibility exists that it will fall
outside of the 32-bit address space.
Over time, a few creative solutions have been proposed and discussed,
with a common theme being that we need changes in either the kernel or
the graphics drivers to do this properly. As we already know the
requirements for a solution to this problem, I think it would be
responsible to hash this out now and then work with the relevant project
maintainers earlier as to avoid blocking work on the wine side too long
and to possibly allow more users to test the new path earlier.
The solutions which I've seen laid out so far:
- Use the mremap(2) interface, allowing us to duplicate the mapping we
receive into the 32-bit address space. This solution would match what
is already done for Crossover Mac's 32on64 support using Mac's
mach_vm_remap functionality [2]. However, right now it is not possible
to use the MREMAP_DONTUNMAP flag with mappings that aren't private and
anonymous, which rules out there use on mapped FDs from libdrm. Due to
this, a kernel change would be necessary.
Pro: A uniform solution across all APIs, which could help in the
future with any unforeseen need to access host-allocated memory in
32-bit windows code.
Cons: Requires a kernel change, which of all the options may take
the longest to get up-streamed and in the hands of users.
- Work with Khronos to introduce extensions into the relevant APIs
enabling us to tell drivers where in the address space we want resources
mapped.
Pro: Wouldn't require going around the backs of the driver,
resulting in a more hardened solution. (Out there, but what if a
creative driver returns a mapping without read or write permission and
handles accesses through a page fault handler?)
Cons: The extension would have to be implemented by each individual
vendor for every relevant API. This would implicitly drop support for
those with cards whose graphics drivers are no longer being updated.
- Hook the driver's mmap call when we invoke memory mappings function,
overriding the address to something in the 32-bit address space.
Pro: Unlike the other solutions, this wouldn't require any
changes to other projects, and shares the advantage of the first solution.
Cons: Susceptible to breakage if the driver uses their own
mapping mechanism separate from mmap. (Custom IOCTL, CPU driver
returning something from the heap)
1: https://www.winehq.org/pipermail/wine-devel/2022-April/213677.html
2: https://www.codeweavers.com/crossover/source - see function
`remap_memory` in `wine/dlls/winemac.drv/opengl.c`
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=120062
Your paranoid android.
=== w10pro64 (64 bit report) ===
mshtml:
htmldoc.c:2541: Test failed: unexpected call UpdateUI
htmldoc.c:2853: Test failed: unexpected call Exec_UPDATECOMMANDS
htmldoc.c:350: Test failed: expected Exec_SETTITLE
htmldoc.c:2859: Test failed: unexpected call Exec_SETTITLE