[Bug 52647] New: wine-staging 7.3 fails to run on debian11 (but work on Debian10)
https://bugs.winehq.org/show_bug.cgi?id=52647 Bug ID: 52647 Summary: wine-staging 7.3 fails to run on debian11 (but work on Debian10) Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alois.schloegl(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- I'm try to run some CUDA application (Cuda-Z, Warpem) on Debian11. Both appliations are running find under wine-staging 7.3 on some Debian10 machines. When trying to install wine-staging on some Debian11 machines (either upgraded from Debian10, or installed Debian11 from scratch) and following the these instructions [1] of installing wine, wine fails to run, and switches into debug mode. Here is the short log, when the WINEPREFIX did alreay exist. 002c:fixme:winediag:LdrInitializeThunk wine-staging 7.3 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. wine: Unhandled page fault on execute access to 00007FB4D8B485C0 at address 00007FB4D8B485C0 (thread 0068), starting debugger... wine: Unhandled page fault on execute access to 00007FDE04B370D0 at address 00007FDE04B370D0 (thread 00c8), starting debugger... wine: Unhandled page fault on execute access to 00007FAD3A6C05C0 at address 00007FAD3A6C05C0 (thread 00dc), starting debugger... wine: Unhandled page fault on execute access to 00007F12CA1970D0 at address 00007F12CA1970D0 (thread 00f0), starting debugger... I remember that a few weeks ago, I could make wine-staging (v7.1?) running on Debian11. But I can not reproduce this anymore. I'm suspecting that some dependencies on libraries have changed, or some dependencies are not correct in the debian/control file. Or that some some differences in the build environment and my setup is in place I tried checking finding differences in the packages installed, and fixed a number of difference, but there are too many. And I've not been successful so far. Do you have any ideas how to proceed and identify what the problem might be ? [1] https://wiki.winehq.org/Debian -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 Sveinar Søpler <cybermax(a)dexter.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax(a)dexter.no --- Comment #1 from Sveinar Søpler <cybermax(a)dexter.no> --- Not really any other ideas than to scour the buildlogs from OBS to look for inconsistencies or library version differences (of which there are many i would say). Debian 10: https://build.opensuse.org/build/Emulators:Wine:Debian/Debian_10/x86_64/wine... Debian 11: https://build.opensuse.org/build/Emulators:Wine:Debian/Debian_11/x86_64/wine... Not seeing a lot of other reports indicating "completely broken" for the WineHQ builds, and it is not immediately clear to me if you are building wine yourself or what instructions you followed to install wine. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #2 from Sveinar Søpler <cybermax(a)dexter.no> --- Sorry (can't edit) but saw the link at the bottom after i posted. So, not compiled yourself, and the package installs without complaining when following the wiki then? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #3 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Yes, that's correct, I just installed winehq-staging according to these instructions [1], and there were no complains. [1] https://wiki.winehq.org/Debian -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #4 from Alois Schlögl <alois.schloegl(a)gmail.com> --- I tested now also with wine-staging 7.4 and see the same behaviour. I'm using nvidia/cuda from bullseye repository. When removing the kernel module nvidia-drm, I see a different behavior. Testing Cuda-Z, wine does not switch into debug mode anymore, and CUDA-Z reports "No compatible CUDA devices found! Please update your NVIDIA drivers and try again" . This message might not be surprising, but the fact that wine does not switch into debug mode, indicates that it is somehow cuda related. I've also tested with libcuda1, and nvidia-drivers from bullseye-backports, but see the same behaviour. Nevertheless, I'm wondering whether wine-staging for Debian11 is build on the stable repository only, or whether some packages from backports or testing are installed on the build machine. I guess could try compiling wine-staging from source, but that would take some time. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #5 from Sveinar Søpler <cybermax(a)dexter.no> --- What driver is that? 470 version nvidia driver? (Somewhat old'ish in that case). Could you perhaps run Cuda-Z with the following debug option: WINEDEBUG=-all,+nvcuda,+nvapi And attach the logfile to the post. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #6 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 71996 --> https://bugs.winehq.org/attachment.cgi?id=71996 log file running wine with and without nvidia-drm kernel module The attached file is the (unprocessed) log file with all control codes. I assume you can handle this. It starts with a new wineprefix, and nvidia-drm kernel module loaded. Running cuda-z as well as winefile, results in these error wine: Unhandled page fault on execute access to 00007FC243AA2070 at address 00007FC243AA2070 (thread 0050), starting debugger... wine: Unhandled page fault on execute access to 00007F5063378660 at address 00007F5063378660 (thread 0048), starting debugger... wine: Unhandled page fault on execute access to 00007F2A25A75660 at address 00007F2A25A75660 (thread 0148), starting debugger... wine: Unhandled page fault on execute access to 00007FE2871AE660 at address 00007FE2871AE660 (thread 015c), starting debugger... Then I'm trying to kill wine, wineserver, etc. to start new. At some point, I do rmmod nvidia-drm then the behaviour changes. That error does not occur anymore, and I can actually start "winefile". cuda-z starts as well, but fails with "no cuda-device available..." . At least the error above does not occur anymore. When loading the nvidia-drm kernel module again, the above errors appear again. We see also some libGL errors: libGL: libGL: Can't open configuration file /etc/drirc: No such file or directory.Can't open configuration file /etc/drirc: No such file or directory. Not sure what that means, and whether this is related -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #7 from Alois Schlögl <alois.schloegl(a)gmail.com> --- The log file is generated with nvidia-drivers 460.91, because this is the default version oin Debian11(Bullseye) [1]. I tried also the nvidia-drivers from backports which are 470.103, but did not see a difference. [1] https://tracker.debian.org/pkg/nvidia-graphics-drivers -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #8 from Sveinar Søpler <cybermax(a)dexter.no> --- Uhm.. That logfile did not really make much sense to me. Perhaps try this: :~$ WINEDEBUG=-all,+nvcuda,+nvapi wine /mnt/nfs/clustersw/shared/CUDA-Z/0.10.251/CUDA-Z-0.10.251-64bit.exe > debug.log 2>&1 The debug info should be in the debug.log file. Not really sure if it could play a part here, but is /mnt/nfs/ a network share? Could you perhaps try to run from a wineprefix in your $HOME folder someplace? Eg. just running wineboot -u will create a .wine folder in your $HOME, and then run CUDA-Z from within $HOME/.wine/drive_c/CUDA-Z or something like that. There is possibly some weirdness with file security++ when running stuff from nfs shares perhaps? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #9 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 71997 --> https://bugs.winehq.org/attachment.cgi?id=71997 clean debug log attached is the debug2.log from this command WINEDEBUG=-all,+nvcuda,+nvapi wine .wine/drive_c/CUDA-Z > debug2.log 2>&1 Before that , I removed ~/.wine and run "wineboot -u", and copied CUDA-Z into .wine/drive_c/CUDA-Z as suggested. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #10 from Sveinar Søpler <cybermax(a)dexter.no> --- Well that seemed to crash incredibly fast. This seems a bit iffy to me: Z:\nfs\scistore16\jonasgrp\schloegl\.wine\drive_c\CUDA-Z Where is this coming from? Are you running $HOME from a nfs drive? What i typed was just an example.. I run CUDA-Z like this: cd "$HOME/.wine/drive_c/Program Files/CUDA-Z" WINEDEBUG=+nvcuda wine ./CUDA-Z-64bit.exe If that crashes, you can run: WINEDEBUG=+loaddll wine ./CUDA-Z-64bit.exe and post that log. I do believe there have been some reports about permissions and stuff when running wine from a prefix on a nfs drive, but i am not saying that is absolutely not working.. i am just saying it is kind of weird wine immediately crashes for you, and you SEEM to be running from a nfs drive (for some reason). Could very well be some changes between Debian10 -> Debian11 when it comes to nfs mounting.. maybe kernel stuff or whatnot that could explain the differences if you are running it like that. If you are adamant on running wine from a mounted nfs drive, i am afraid i do not have knowledge enough to figure out what could be wrong tho. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #11 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 72005 --> https://bugs.winehq.org/attachment.cgi?id=72005 wine debug log when nvidia-drm module is loaded Yes, the $HOME is on NFS, but in order to exclude that possibility, I'll redo this on a local disk /localhome/schloegl/.wine, and use the suggested debug flags. Moreover, I'll run the following script with and without nvidia-drm kernel module loaded. export WINEPREFIX=/localhome/schloegl/.wine.with_nvidia_drm lsmod |grep nvidia export WINEDEBUG=+loaddll rm -rf $WINEPREFIX wineboot -u winefile cp /mnt/nfs/clustersw/shared/CUDA-Z/0.10.251/CUDA-Z-0.10.251-64bit.exe $WINEPREFIX/drive_c/CUDA-Z wine $WINEPREFIX/drive_c/CUDA-Z Without nvidia-drm, the script runs through, when the nvidia-drm is loaded, wine fails into debug mode and I killed the "winedbg" processes . -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #12 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 72006 --> https://bugs.winehq.org/attachment.cgi?id=72006 wine debug log when nvidia-drm kernel module is not loaded -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #13 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Please note, that winedbg is already triggered when running wineboot, and winefile. so that is unrelated to cuda-z. The winefile window is only opened when nvidia-drm is not loaded. And the issue is unrelated whether wineprefix is on a local or an NFS share. (machine is part of a larger computational cluster, so the home directories are on nfs). I've now compiled wine-staging 7.4 from source, and I do see the same behaviour. I do not know whether it matters, but I had to limit the stacksize, otherwise, I'd see this error: /opt/wine-staging/bin/wine: error while loading shared libraries: libpthread.so.0: cannot create shared object descriptor: Operation not permitted or this in the version I compiled from source. /nfs/scistore07/clustersw/debian/bullseye/wine-staging/7.4/bin/wine: error while loading shared libraries: out of memory: Operation not permitted Currently, I run the tests with these limits: $ ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 1031179 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 65530 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 665544 cpu time (seconds, -t) unlimited max user processes (-u) 1031179 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Let me know if I should run further tests, in order to identify the cause of this issue. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #14 from Sveinar Søpler <cybermax(a)dexter.no> --- 0218:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. when nvidia-drm IS loaded? Verify the following: vulkaninfo (should print vulkan info from your nvidia driver) - This is in the vulkan-tools package i think. nvidia-smi (should come installed with the nvidia driver) I am leaning towards that this is some sort of driver misconfiguration, and not a "wine bug" tbh, and perhaps better suited for the support forums here on WineHQ rather than discussing various distro configurations in a bugtracker. Good luck :) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #15 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Indeed, the vulkan setup is broken on that machine. Thanks for the hint. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 nj8ne5e16(a)mozmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nj8ne5e16(a)mozmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #16 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Alois Schlögl from comment #15)
Indeed, the vulkan setup is broken on that machine. Thanks for the hint.
Hello, Did fixing the vulkan setup make the issue away? If yes then please, mark the bug RESOLVED INVALID. (As the original reporter you are allowed to do it). Regards. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #17 from Alois Schlögl <alois.schloegl(a)gmail.com> --- so far I've not been able to fix it. I submitted this bug report to debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007832 I compiled vulkan-loader and vulkan-tools from source, but this did not change anything. I the course of investigating the issue, I came across these issues #175, #249, and #446 at https://github.com/KhronosGroup/Vulkan-Tools/issues?q=cuda I noticed also that unlike in Debian10, on Debian11, that the framebuffer is assigned to the first gpu. This is shown as "logical name: /dev/fb0" when running # lshw -C display *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci(a)0000:05:00.0 logical name: /dev/fb0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom fb configuration: depth=32 driver=nvidia latency=0 mode=1024x768 visual=truecolor xres=1024 yres=768 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c4000000-c4ffffff memory:27fe0000000-27fefffffff memory:27ff0000000-27ff1ffffff ioport:b000(size=128) memory:c5000000-c507ffff On Debian10, this is not the case. That is currently the most promising lead, but I do not have a solution yet. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 --- Comment #18 from Sveinar Søpler <cybermax(a)dexter.no> --- (In reply to Alois Schlögl from comment #17)
On Debian10, this is not the case. That is currently the most promising lead, but I do not have a solution yet.
If running vulkaninfo causes a segmentation fault for you, the bug does not seem like it is with wine. Vulkan does not really have anything to do with CUDA, in that you do not really need a working CUDA setup to use vulkan afaik. I looked at your logreport. I wonder if you have NVIDIA's icd loader someplace else than /usr/share/vulkan/icd.d/? Cos the 3 listed there is not it i think... There is a problem when using multiple icd's, as the system might be a bit confused if not specified. Could it be in /etc/vulkan/ perhaps? Eg run: VK_ICD_FILENAMES=/etc/vulkan/icd.d/nvidia_icd.json vkcube or something like that? (Should have nvidia_icd.json someplace, and if you compiled vulkan loader yourself, it might not follow the Debian default folder placement) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #19 from Alois Schlögl <alois.schloegl(a)gmail.com> --- I agree that this is not a bug in wine. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52647 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #20 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Closing INVALID. -- 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.
participants (1)
-
WineHQ Bugzilla