[Bug 51420] New: likely regression: heavy lag to the point of brokenness running anything in wine. 158:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0158, blocked by 0144, retrying (60 sec)
https://bugs.winehq.org/show_bug.cgi?id=51420
Bug ID: 51420 Summary: likely regression: heavy lag to the point of brokenness running anything in wine. 158:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0158, blocked by 0144, retrying (60 sec) Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: mouse@dayrep.com Distribution: ---
Debian bullseye using the winehq packages proprietary nvidia driver from Debian non-free
Tested versions that work fine as before: 6.0.1, 6.10 Broken versions: 6.11, 6.12, staging-6.12
Running any program in wine, included or otherwise, is causing extremely poor systems performance and is very slow. As in you can see the mouse cursor move in steps and lagging behind inputs, or the file selection window of the wine uninstaller takes seconds to display the icons for folder contents and loads the one by one. This stops as soon as the wine process is killed again.
Full difference in wine log between 6.10 (works fine) and 6.12 (bugged) reproduced below:
0158:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0158, blocked by 0144, retrying (60 sec) 0168:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0168, blocked by 0144, retrying (60 sec) 0180:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0180, blocked by 0144, retrying (60 sec) 0188:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0188, blocked by 0144, retrying (60 sec) 0198:err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0198, blocked by 0144, retrying (60 sec) 0208:fixme:console:default_ctrl_handler Terminating process 20 on event 0
[Also: What is an ergonomic way to downgrade to a previous winehq-devel and dependent wine package versions on Debian? Because synaptic in general and in this specific (force version) case handles amd64 packages with i386 dependencies very poorly. Basically what is the apt command line to fetch and install winehq-devel, wine-devel, wine-devel-amd64 and wine-devel-i386 all in the same older version number? like 6.9 for example.]
https://bugs.winehq.org/show_bug.cgi?id=51420
mouse mouse@dayrep.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian
https://bugs.winehq.org/show_bug.cgi?id=51420
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Please don't say "every application", at least not without naming specific examples. Does it happen with wine builtins (e.g. winecfg, explorer, regedit)?
Does it happen when creating a new prefix? See https://wiki.winehq.org/FAQ#Can_I_store_the_virtual_Windows_installation_somewhere_other_than_.7E.2F.wine.3F if you need instructions.
If you open a system monitor (e.g. top/atop/htop), does it show specific processes consuming CPU time (or memory, or disk)?
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #2 from mouse mouse@dayrep.com --- the process "Xorg" owned by root is at 99.7% CPU utilization while wine 6.11 or wine 6.12 are running.
I am writing every program as that is the case (any program would have been the better word). I mentioned the wine uninstaller above, winecfg is the same. I now tested with "wine -v", which immediately resulted in 99.7% CPU utilization and took 15 seconds to start displaying the the wineprefix in c is being updated message. Just switching to the gnome-terminal tab with htop and killing the terminal window after was quite the challenge. Yes, tests were done in clean/deleted wineprefixes as is best practice.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #3 from mouse mouse@dayrep.com --- Because I feel like haven't explicitly mentioned this: Yes, this behavior happens as well during the initial creation of a new Wineprefix (prompted by running winecfg in an empty home directory of a newly created user for example) on affected versions of Wine. As soon as anything wine is running it goes.
https://bugs.winehq.org/show_bug.cgi?id=51420
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|likely regression: heavy |Running any program in Wine |lag to the point of |causes 100% cpu usage in |brokenness running anything |Xorg |in wine. | |158:err:ntdll:RtlpWaitForCr | |iticalSection section | |7BC61360 | |"dlls/ntdll/loader.c: | |loader_section" wait timed | |out in thread 0158, blocked | |by 0144, retrying (60 sec) |
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- Sorry, I did miss that in your original message.
Is it just Xorg? No Wine process is taking up that much CPU time?
That strikes me as odd; it might be an X server bug. The best thing to do would be to perform a regression test in Wine, to find out what broke it. Switching to the free driver may also help.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #5 from mouse mouse@dayrep.com --- I don't think I will be able to help out with a regression test identifying a specific commit, as the multilib in Debian isn't complete enough to do a full wine build without custom chroots or other workarounds I don't feel I can pull off within a reasonable timeframe. What I do know is that it is a change between wine 6.10 and 6.11 (non-staging) which narrows it down quite a bit.
The other piece of info, that this message: err:ntdll:RtlpWaitForCriticalSection section 7BC61360 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 0158, blocked by 0144, retrying (60 sec) only shows up (and shows up repeatedly) on the borked versions might give a starting spot for an investigation.
I can also provide custom debug logs (as in WINEDEBUG=-whatever) in case that might help.
I feel like this is issue is appropriate for this bugtracker, at least until the cause is found, as a change in version number of wine, and not of Xorg or a Debian apt upgrade makes the issue show up and go away. (Even though of course we might still find out that it is a NOTOURBUG in the end.)
I didn't do any fancy profiling for the CPU usage, I just managed to get onto a terminal tab with top running in it. I saw Xorg was at close to 99.9% and every other process lower that 2%. Wine seems to otherwise work, it is just that everything takes forever and system responsiveness of course is very poor.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- (In reply to mouse from comment #5)
I don't think I will be able to help out with a regression test identifying a specific commit, as the multilib in Debian isn't complete enough to do a full wine build without custom chroots or other workarounds I don't feel I can pull off within a reasonable timeframe.
For what it's worth, you don't need to install all of the dependencies; in fact for an issue like this I think the only important dependencies will be the libX* ones. And as far as I know, the only broken multilib packages in Debian are GStreamer and libxml2 (is libxml2 still broken?)
https://bugs.winehq.org/show_bug.cgi?id=51420
Michael McGuire spoon0042@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spoon0042@hotmail.com
--- Comment #7 from Michael McGuire spoon0042@hotmail.com --- Presumably you could build 32-bit only which simplifies things. That's what I've done when regression testing on Debian anyway.
https://bugs.winehq.org/show_bug.cgi?id=51420
Kurt Kartaltepe kkartaltepe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kkartaltepe@gmail.com
--- Comment #8 from Kurt Kartaltepe kkartaltepe@gmail.com --- I am also experiencing this issue, I bisected to d171d1116764260f4ae272c69b54e5dfd13c6835
All of the cpu usage attributed to Xorg however is actually all kernel time in nvidia_drv.so, if that helps diagnose where this goes wrong for nvidia's driver.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #9 from Kurt Kartaltepe kkartaltepe@gmail.com --- reverting d171d1116764260f4ae272c69b54e5dfd13c6835 makes 6.12 behave as expected.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #10 from Kurt Kartaltepe kkartaltepe@gmail.com --- Perhaps unsurprisingly, removing the broken drivers xrandr 1.0 fallback that logs the now famous `Broken NVIDIA RandR detected, falling back to RandR 1.0` also works to resolve all performance issues.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #11 from Henri Verbeet hverbeet@gmail.com --- (In reply to Kurt Kartaltepe from comment #10)
Perhaps unsurprisingly, removing the broken drivers xrandr 1.0 fallback that logs the now famous `Broken NVIDIA RandR detected, falling back to RandR 1.0` also works to resolve all performance issues.
The issue is probably that RandR 1.0 doesn't have RRGetScreenResourcesCurrent(), so querying the current screen configuration ends up actually polling the hardware.
https://bugs.winehq.org/show_bug.cgi?id=51420
thomas-bugzilla-wine@24hoursparty.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas-bugzilla-wine@24hour | |sparty.de
https://bugs.winehq.org/show_bug.cgi?id=51420
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |nerv@dawncrow.de Status|UNCONFIRMED |NEW
--- Comment #12 from André H. nerv@dawncrow.de --- confirming on a notebook with nvidia driver reverting d171d1116764260f4ae272c69b54e5dfd13c6835 as per Comment 8 fixes the issue
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #13 from mouse mouse@dayrep.com --- Kurt Kartaltepe, what tooling did you use to find that "All of the cpu usage attributed to Xorg however is actually all kernel time in nvidia_drv.so, if that helps diagnose where this goes wrong for nvidia's driver." ?
I'd love to be able to make such an observation myself, and therefore be able to file better bug reports.
https://bugs.winehq.org/show_bug.cgi?id=51420
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #14 from Fabian Maurer dark.shadow4@web.de ---
The issue is probably that RandR 1.0 doesn't have RRGetScreenResourcesCurrent(), so querying the current screen configuration ends up actually polling the hardware.
How often is that called? Is caching an option?
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #15 from André H. nerv@dawncrow.de --- It seems to be fixed now, no clue which patch it might have been.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #16 from Kurt Kartaltepe kkartaltepe@gmail.com ---
Kurt Kartaltepe, what tooling did you use to find that "All of the cpu usage attributed to Xorg however is actually all kernel time in nvidia_drv.so, if that helps diagnose where this goes wrong for nvidia's driver." ?
I just ran perf while nothing was happening but this bug and from there you can use y our favorite visualization tool (such as flamegraphs) to see 90% of the cpu time was spent in xorg calling into this library.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #17 from mouse mouse@dayrep.com --- I tested again with the current Wine 6.19 winehq packages and couldn't find any change in behavior. This bug is still present.
The nvidia card used in the system I am testing this on is supported by the nvidia-legacy-390* series of packages from Debian non-free, but too old for the newer nvidia-driver package (which has version numbers 460.*). This may or may not be relevant.
[And just for the possible benefit of a reader of the tracker and in response to a question of mine in the initial message: "aptitude install wine-devel=6.10~bullseye-1 wine-devel-amd64=6.10~bullseye-1 wine-devel-i386=6.10~bullseye-1 winehq-devel=6.10~bullseye-1 && aptitude hold winehq-devel wine-devel wine-devel-i386:i386 wine-devel-amd64" is an ergonomic way to install specific versions of winehq packages for testing.]
https://bugs.winehq.org/show_bug.cgi?id=51420
matt gardotd426@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gardotd426@gmail.com
--- Comment #18 from matt gardotd426@gmail.com --- (In reply to mouse from comment #17)
I tested again with the current Wine 6.19 winehq packages and couldn't find any change in behavior. This bug is still present.
The nvidia card used in the system I am testing this on is supported by the nvidia-legacy-390* series of packages from Debian non-free, but too old for the newer nvidia-driver package (which has version numbers 460.*). This may or may not be relevant.
[And just for the possible benefit of a reader of the tracker and in response to a question of mine in the initial message: "aptitude install wine-devel=6.10~bullseye-1 wine-devel-amd64=6.10~bullseye-1 wine-devel-i386=6.10~bullseye-1 winehq-devel=6.10~bullseye-1 && aptitude hold winehq-devel wine-devel wine-devel-i386:i386 wine-devel-amd64" is an ergonomic way to install specific versions of winehq packages for testing.]
I can't reproduce this at all on 495.44 (and I've never seen it before on any driver version since I got the 3090 on launch day on 24 Sept. 2020), so I'm guessing this is probably limited to older drivers/cards now.
I'm running wine as I type this and perf top $(pgrep Xorg) shows like 12-20% for Nvidia. No different from before I started wine. I've never seen this in a single game or any other application running in Wine (which I do multiple times a day).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #19 from Kurt Kartaltepe kkartaltepe@gmail.com ---
I can't reproduce this at all on 495.44 (and I've never seen it before on any driver version since I got the 3090 on launch day on 24 Sept. 2020), so I'm guessing this is probably limited to older drivers/cards now.
It is trivially replicable on 6.21 by running regedit.exe and trying to use it. I am using a GTX 1070. I wouldn't classify this as "older drivers/cards" as basically all newer models are unattainable by the average user. As my wallet and time is not unlimited I dont have other hardware to test personally.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #20 from Kurt Kartaltepe kkartaltepe@gmail.com --- On the 495.44 drivers as well (Sorry I missed it in the last comment).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #21 from mitchell4136@gmail.com --- I am able to reproduce this bug on 495.44-13 driver published in the official arch repos on November 26th on an RTX 2060 super card. I'm willing to bet this is a multi monitor issue.
There is another big teport that also mentions an external monitor and is almost certainly a duplicate of this bug:
https://bugs.winehq.org/show_bug.cgi?id=51891
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #22 from matt gardotd426@gmail.com --- (In reply to Kurt Kartaltepe from comment #19)
I can't reproduce this at all on 495.44 (and I've never seen it before on any driver version since I got the 3090 on launch day on 24 Sept. 2020), so I'm guessing this is probably limited to older drivers/cards now.
It is trivially replicable on 6.21 by running regedit.exe and trying to use it. I am using a GTX 1070. I wouldn't classify this as "older drivers/cards" as basically all newer models are unattainable by the average user. As my wallet and time is not unlimited I dont have other hardware to test personally.
I have regedit open right now and Nvidia is at 2.23% with sudo perf top -p $(pgrep Xorg). I'm even compiling the kernel and it's not slowed down at all, and gotop doesn't show Xorg in the top 20 cpu processes.
Obviously this is still an issue for some people (that is weird though, that it's only some people that have the issue), but it would be nice if we could figure out why some people say it's fixed, some people say it's not, and others could never reproduce it in the first place.
I am able to reproduce this bug on 495.44-13 driver published in the official >arch repos on November 26th on an RTX 2060 super card. I'm willing to bet this >is a multi monitor issue.
There is another big teport that also mentions an external monitor and is almost >certainly a duplicate of this bug:
I have 2 monitors and have for the entire time I've had an Nvidia GPU (over a year), and haven't seen this issue once.
That doesn't mean it's not in some way related to monitor setup, but it's not "if you have an Nvidia GPU and multiple monitors you have this bug."
I was hoping I could reproduce it so I could maybe try and test some stuff to help debug it, but I can't do much if I've never had the issue and can't force it.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #23 from Kurt Kartaltepe kkartaltepe@gmail.com ---
I'm willing to bet this is a multi monitor issue.
I've got a DP and a DVI monitor attached on this system. So thats certainly possible.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #24 from mitchell4136@gmail.com --- Do you have the usual "fallback to Randr 1.0" log message? Seems to be related to this bug as a whole. I certainly get it while being on the proprietary driver. Someone earlier mentioned that Randr 1.0 reverts to polling actual hardware, hence the high xorg CPU usage.
https://bugs.winehq.org/show_bug.cgi?id=51420
mitchell4136@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mitchell4136@gmail.com
--- Comment #25 from mitchell4136@gmail.com --- I personally have a DVI-D as a primary output and HDMI going to my secondary monitor.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #26 from matt gardotd426@gmail.com --- (In reply to mitchell4136 from comment #24)
Do you have the usual "fallback to Randr 1.0" log message? Seems to be related to this bug as a whole. I certainly get it while being on the proprietary driver. Someone earlier mentioned that Randr 1.0 reverts to polling actual hardware, hence the high xorg CPU usage.
Where would that message be? In the console output when running Wine? In Xorg.0.log?
I've got a DP and a DVI monitor attached on this system. So thats certainly >possible.
I personally have a DVI-D as a primary output and HDMI going to my secondary >monitor.
Now we're getting somewhere. Mine are both DisplayPort. They also have the same capabilities. This very well may be limited to multimonitor setups using one (or at least one) DVI.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #27 from mitchell4136@gmail.com --- Forgot the exact wording but it's the decade old infamous "broken Randr driver, reverting to randr 1.0" something something yada yada message in xorg.0.log whenever you run nvidia proprietary driver with wine.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #28 from mitchell4136@gmail.com --- WineHQ FAQ even has a page on that infamous message:
https://wiki.winehq.org/FAQ#Broken_NVIDIA_RandR_detected.2C_falling_back_to_...
I've tried applying their fixes in xorg.conf to no avail. Of course running wine on Wayland (bypassing xorg all together) makes the problem go away.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #29 from matt gardotd426@gmail.com --- (In reply to mitchell4136 from comment #28)
WineHQ FAQ even has a page on that infamous message:
https://wiki.winehq.org/FAQ#Broken_NVIDIA_RandR_detected. 2C_falling_back_to_RandR_1.0
I've tried applying their fixes in xorg.conf to no avail. Of course running wine on Wayland (bypassing xorg all together) makes the problem go away.
Yeah this is sounding like an X11 or Nvidia driver bug that just happens to be triggered by Wine containing this commit for users with two monitors (with one of them being DVI). Which is insanity lol.
I'm trying to see if I can get a patch together that reverts some of the stuff to see if you can test it, but it's gonna take a bit because one of the files in question doesn't even exist (it was renamed), so it's not as simple as "git revert <badcommit>", and what's more that file has changed a bunch since then so I've had to modify it. But I'm almost done and then I'll check to make sure it builds and I'll post it. This would at least let you get the benefits of newer wine versions but without the bug (assuming it works).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #30 from matt gardotd426@gmail.com --- Created attachment 71183 --> https://bugs.winehq.org/attachment.cgi?id=71183 Patch to revert the bad stuff.
This is a patch doing as best I can to revert the equivalent stuff from this commit (some of the stuff from the commit isn't even there to revert anymore but it's changed). This patch applies cleanly and the build succeeds. Also works with staging (obviously needs to be applied before staging's patchset is applied).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #31 from matt gardotd426@gmail.com --- Guys I've uploaded a patch. See if it fixes it for you. Applies to current wine source before Staging patchset is applied. Patch applies clean and build succeeds (tested also with Staging).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #32 from matt gardotd426@gmail.com --- (In reply to matt from comment #31)
Guys I've uploaded a patch. See if it fixes it for you. Applies to current wine source before Staging patchset is applied. Patch applies clean and build succeeds (tested also with Staging).
Mitchell reports that the patch fixes the issue for them. So anyone who is still encountering this feel free to use the patch until this gets fixed upstream.
Also apply it *after* staging if you're gonna use the staging patchset (it works both ways, but still).
https://bugs.winehq.org/show_bug.cgi?id=51420
alecov@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alecov@mail.com
--- Comment #33 from alecov@mail.com --- *** Bug 51891 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=51420
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #34 from Sveinar Søpler cybermax@dexter.no --- Can't say i have ever experienced this, but i do not use a DVI monitor. Mine is DP on main, and HDMI on my second monitor.
Maybe it is some strange stuff with multi-monitors with one of them connected to DVI? I get around 1.3-2% 1-core load when running regedit.
RTX2070. Currently 470.62.13 driver, but did not have this with 495.44 either.
If you wonder where that strange "falling back to randr 1.0" message comes from: https://github.com/wine-mirror/wine/commit/f5e6c086f91749e9e302c1abf85880753...
Some of this is removed with the proton fshack patchset: https://github.com/ValveSoftware/wine/commit/352b0304a357f9e062695c45ed12d74...
Not sure if it is related to this bug, but you mentioned the message.. and it is logged in wine logs and (should) not in Xorg.0.log. Perhaps try WINEDEBUG=-all,+xrandr ?
Normal log: 0070:trace:xrandr:X11DRV_XRandR_Init Found XRandR 1.6.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #35 from matt gardotd426@gmail.com --- (In reply to Sveinar Søpler from comment #34)
Can't say i have ever experienced this, but i do not use a DVI monitor. Mine is DP on main, and HDMI on my second monitor.
Maybe it is some strange stuff with multi-monitors with one of them connected to DVI? I get around 1.3-2% 1-core load when running regedit.
RTX2070. Currently 470.62.13 driver, but did not have this with 495.44 either.
If you wonder where that strange "falling back to randr 1.0" message comes from: https://github.com/wine-mirror/wine/commit/ f5e6c086f91749e9e302c1abf858807535bc9775
Some of this is removed with the proton fshack patchset: https://github.com/ValveSoftware/wine/commit/ 352b0304a357f9e062695c45ed12d74e0cfc70db
Not sure if it is related to this bug, but you mentioned the message.. and it is logged in wine logs and (should) not in Xorg.0.log. Perhaps try WINEDEBUG=-all,+xrandr ?
Normal log: 0070:trace:xrandr:X11DRV_XRandR_Init Found XRandR 1.6.
Yeah as I said my theory is that it affects users with 2 monitors where one of them is connected via DVI. The fact that you don't experience the bug seems to bolster that theory a little bit more.
My patch posted here has been confirmed to fix the issue (at least for one of the users here who were affected), so while waiting for a true fix, anyone affected can use my patch if they're building from source (or using something like wine-tkg-git to build for them).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #36 from Kurt Kartaltepe kkartaltepe@gmail.com --- I feel like this post is the blind leading the deaf, the author of the offending code has even responded on this thread, but not deigned to explain the issue.
When nvidia drivers are detected wine falls back to xrandr 1.0/1.1 for querying modes. As the author notes in their commit this is because they didn't like the modes reported by newer xrandr versions for DVI connections.
This is why d171d1116764260f4ae272c69b54e5dfd13c6835 which introduces many more queries to mode information to be a significant performance hit on nvidia with DVI connections. And why reverting the 1.0 fallback also fixes it (as we get the explicitly fast xrandr functions).
If you want to see if you are affected, well the first step is to see if you have a DVI device. The second step is you could run the same queries wine does and watch if your X11 session becomes unusable. For example `for x in $(seq 1 100); do xrandr --q1; done`, testing with a single DVI device shows the system crippled and testing with a single DP devices shows no significant impact.
Matt's rebase of the revert looks fine to me. When I tested the actual revert it also worked to avoid the excessive mode queries, as did removing the xrandr 1.0 fallback.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #37 from matt gardotd426@gmail.com --- (In reply to Kurt Kartaltepe from comment #36)
I feel like this post is the blind leading the deaf, the author of the offending code has even responded on this thread, but not deigned to explain the issue.
When nvidia drivers are detected wine falls back to xrandr 1.0/1.1 for querying modes. As the author notes in their commit this is because they didn't like the modes reported by newer xrandr versions for DVI connections.
This is why d171d1116764260f4ae272c69b54e5dfd13c6835 which introduces many more queries to mode information to be a significant performance hit on nvidia with DVI connections. And why reverting the 1.0 fallback also fixes it (as we get the explicitly fast xrandr functions).
If you want to see if you are affected, well the first step is to see if you have a DVI device. The second step is you could run the same queries wine does and watch if your X11 session becomes unusable. For example `for x in $(seq 1 100); do xrandr --q1; done`, testing with a single DVI device shows the system crippled and testing with a single DP devices shows no significant impact.
Matt's rebase of the revert looks fine to me. When I tested the actual revert it also worked to avoid the excessive mode queries, as did removing the xrandr 1.0 fallback.
Yeah I don't know enough to dig through the code and find the original problem or anything like that, but I did figure I could at least create a patch that safely reverts the problematic code (since just reverting the original offending commit isn't possible). Hopefully a better solution can be constructed but until then yeah, my patch should work for anyone affected.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #38 from Sveinar Søpler cybermax@dexter.no --- (In reply to Kurt Kartaltepe from comment #36)
If you want to see if you are affected, well the first step is to see if you have a DVI device. The second step is you could run the same queries wine does and watch if your X11 session becomes unusable. For example `for x in $(seq 1 100); do xrandr --q1; done`, testing with a single DVI device shows the system crippled and testing with a single DP devices shows no significant impact.
So, is this supposed to happen on "any" device using DVI when doing this xrandr query? Would xorg crawl to a halt on AMD or Intel if you use `for x in
$(seq 1 100); do xrandr --q1; done`?
If such a spammy function would never ever happen on any linux program other than wine, i can see it not being fixed by upstream driver tho, and finding a better solution in wine is needed (as you point out)... however, if only nVidia GPU's would exhibit this kind of behaviour if this particular for sequence is used, perhaps it is a driver issue someone should consider bugreporting?
It does seem as the proposed fix forces 32bpp, and bypass some sort of detection (that seemingly does not work to well on nVidia with DVI + multiple displays).
I don't have a DVI port on my RTX card, so i cant really do any testing i guess.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #39 from mitchell4136@gmail.com --- `for x in $(seq 1 100); do xrandr --q1; done` reproduces the behavior as this wine bug, though I only get : bash -c `for x in $(seq 1 100); do xrandr --q1; done` Pixels: line 1: SZ:: command not found before it fails in my terminal.
Also im not sure if im running this command properly but i tried winedebug also: WINEDEBUG=-all,+xrandr winetricks SSL_INIT Executing mkdir -p /home/mitch ------------------------------------------------------ warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug. ------------------------------------------------------ Using winetricks 20210206-next - sha256sum: 0769bbcdbd92c407f4eacaa85acc1339f607dbeafe2febd1be0912034c7af3a1 with wine-6.22 and WINEARCH=win64
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #40 from mitchell4136@gmail.com --- Ill be available in roughly 14 hours if any other testing is required. If theres logs that need to be shown, please lead me to the default directory of those logs (im unfamiliar with where wine keeps its logs at).
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #41 from mitchell4136@gmail.com --- This is my current xrandr output messages, since xrandr seems to be a big part of this:
❯ xrandr Screen 0: minimum 8 x 8, current 3640 x 1920, maximum 32767 x 32767 DVI-D-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 59.95*+ HDMI-0 connected 1080x1920+2560+0 left (normal left inverted right x axis y axis) 575mm x 323mm 1920x1080 60.00*+ 60.00 59.94 50.00 1680x1050 59.95 1366x768 59.96 1280x1024 60.02 1280x960 60.00 1280x800 59.81 1280x720 60.00 59.94 50.00 1024x768 75.03 70.07 60.00 800x600 75.00 72.19 60.32 56.25 720x576 50.00 720x480 59.94 640x480 75.00 72.81 59.94 59.93 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) ❯ xrandr --q1 SZ: Pixels Physical Refresh *0 3640 x 1920 ( 856mm x 455mm ) *50 1 2560 x 1440 ( 602mm x 341mm ) 51 2 1920 x 1200 ( 451mm x 284mm ) 52 3 1920 x 1080 ( 451mm x 256mm ) 53 4 1680 x 1050 ( 395mm x 249mm ) 54 5 1600 x 1200 ( 376mm x 284mm ) 55 6 1440 x 900 ( 338mm x 213mm ) 56 7 1366 x 768 ( 321mm x 182mm ) 57 8 1280 x 1024 ( 301mm x 243mm ) 58 9 1280 x 800 ( 301mm x 189mm ) 59 10 1280 x 720 ( 301mm x 170mm ) 60 11 1024 x 768 ( 240mm x 182mm ) 61 12 800 x 600 ( 188mm x 142mm ) 62 13 640 x 480 ( 150mm x 113mm ) 63 Current rotation - normal Current reflection - none Rotations possible - normal left inverted right Reflections possible - X Axis Y Axis
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #42 from Kurt Kartaltepe kkartaltepe@gmail.com ---
however, if only nVidia GPU's would exhibit this kind of behaviour if this particular for sequence is used, perhaps it is a driver issue someone should consider bugreporting?
You are probably 15 years and 5 versions of randr too late to argue that nvidia's implementation is incorrect.
The issue is probably that RandR 1.0 doesn't have RRGetScreenResourcesCurrent(), so querying the current screen configuration ends up actually polling the hardware.
As you can see from a previous comment, newer versions of randr (the version used on every other driver by wine) have a new function, presumably for precisely this reason. This is also why you can issue the same xrandr function in a loop without forcing version 1.0 (no `--q1` flag) and observe there is no significant performance issues on nvidia.
Intel drivers freak out a bit with an eDP device on randr 1.0 but dont cause any significant performance impact, i dont have any other devices with to test on though, nor do I kid myself that nvidia would change their implementation of randr 1.0.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #43 from Sveinar Søpler cybermax@dexter.no --- (In reply to Kurt Kartaltepe from comment #42)
Intel drivers freak out a bit with an eDP device on randr 1.0 but dont cause any significant performance impact, i dont have any other devices with to test on though, nor do I kid myself that nvidia would change their implementation of randr 1.0.
So, the patch i linked above that "forces" nVidia drivers to use randr 1.0, and was removed by proton (possibly for this reason alone) is what is causing this weirdness?
Does nVidia + DVI multimonitor + "forced fallback to randr 1.0" cause this issue?
Why do my logs with the "proton disable nvidia workaround" patch seem to indicate randr 1.6 if it does not really work?
The text in the patch: /* Some (304.64, possibly earlier) versions of the NVIDIA driver only * report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes * are only listed through RandR 1.0 / 1.1. This is completely useless, * but NVIDIA considers this a feature, so it's unlikely to change. The * best we can do is to fall back to RandR 1.0 and encourage users to * consider more cooperative driver vendors when we detect such a * configuration. */
Does the values from https://bugs.winehq.org/show_bug.cgi?id=51420#c41 show why this fallback is necessary for nVidia?
I am aware this cannot be tested on custom wine-staging with proton fshack patches, since that does not change the resolution for the display, and just scales everything to "native".
Any testcase i could do on wine-devel to verify that nVidia randr "does not work"? I guess i will experiment a bit with this.. The text above and some reports i found about this particular weirdness was from 2012, so even tho it is currently the default, i do not know for sure it IS the actual case anymore (although it probably is).
If i revert the "randr fallback for nvidia patch", what would happen? Would i only be able to choose native resolution for a 3D app for instance? Guess ill have to experiment a bit when i come home :)
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #44 from Henri Verbeet hverbeet@gmail.com --- (In reply to Sveinar Søpler from comment #43)
(In reply to Kurt Kartaltepe from comment #42) So, the patch i linked above that "forces" nVidia drivers to use randr 1.0, and was removed by proton (possibly for this reason alone) is what is causing this weirdness?
Proton has the "fullscreen hack", which is worse in some ways, but does avoid this particular issue, simply by never changing the display mode.
The text in the patch: /* Some (304.64, possibly earlier) versions of the NVIDIA driver only
- report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes
- are only listed through RandR 1.0 / 1.1. This is completely useless,
- but NVIDIA considers this a feature, so it's unlikely to change. The
- best we can do is to fall back to RandR 1.0 and encourage users to
- consider more cooperative driver vendors when we detect such a
- configuration. */
Does the values from https://bugs.winehq.org/show_bug.cgi?id=51420#c41 show why this fallback is necessary for nVidia?
It does, in fact. Note that in the first xrandr output in that comment, it shows the "DVI-D-0" output as supporting only a single display mode. It is the primary output as well. This means that if an application would try to switch to e.g. 1024x768@60Hz, it would simply fail. It's not uncommon for older applications in particular to assume these standard display modes like 1024x768, 800x600, 640x480, etc. are always available.
It's perhaps worth pointing out that the RandR 1.0 output in comment 41 isn't quite right either; it shows made up refresh rates. This is typically caused by having the "DynamicTwinView" xorg.conf option enabled. It can cause similar issues for applications that insist on particular display modes (like 1024x768@60) always being available.
If i revert the "randr fallback for nvidia patch", what would happen? Would i only be able to choose native resolution for a 3D app for instance? Guess ill have to experiment a bit when i come home :)
In a well behaved application, yes, you will only be able to use the single listed display mode. Less well behaved applications may simply crash, or otherwise misbehave in hard to diagnose ways, because they e.g. end up using a never tested fallback path.
The "proper" way to resolve this specific bug is probably to cache the current display mode and listen to RRScreenChangeNotify events when using the RandR 1.0 path. (I.e., in xrandr10_get_current_mode().) That approach may not be a bad idea for the RandR 1.4+ path either, but it should be much less necessary there.
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #45 from Sveinar Søpler cybermax@dexter.no --- (In reply to Henri Verbeet from comment #44)
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
Is this a particular DVI-D problem, and does not rear its ugly head with HDMI or DP configurations, or should i see the same issue there?
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #46 from matt gardotd426@gmail.com --- (In reply to Sveinar Søpler from comment #45)
(In reply to Henri Verbeet from comment #44)
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
Is this a particular DVI-D problem, and does not rear its ugly head with HDMI or DP configurations, or should i see the same issue there?
Yeah there hasn't been anyone with only HDMI and/or DP that's been able to reproduce. DVI seems to be required to encounter the issue.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #47 from Sveinar Søpler cybermax@dexter.no --- (In reply to matt (gardotd426) from comment #46)
(In reply to Sveinar Søpler from comment #45)
(In reply to Henri Verbeet from comment #44)
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
Is this a particular DVI-D problem, and does not rear its ugly head with HDMI or DP configurations, or should i see the same issue there?
Yeah there hasn't been anyone with only HDMI and/or DP that's been able to reproduce. DVI seems to be required to encounter the issue.
Think i have to conclude the same. I am using a HDMI -> DVI cable to my 2nd monitor, but have a normal range of resolutions on that port, so it has to hinge on the gfx adapter actually having a DVI port in use i guess.
@mitchell4136 It might be that the driver is not able to read the correct EDID from your monitor or something? Are you able to select more than 1 resolution for your (DVI) monitor in the nvidia-settings app?
If you are, you could try to dump the EDID for the monitor, and use it in your xorg.conf file perhaps..
Some troubleshooting tips here: https://forums.developer.nvidia.com/t/340-96-xrandr-1-5-0-and-native-only-re... https://www.nvidia.com/en-us/geforce/forums/geforce-graphics-cards/5/228447/...
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #48 from Henri Verbeet hverbeet@gmail.com --- (In reply to Sveinar Søpler from comment #45)
(In reply to Henri Verbeet from comment #44)
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
Is this a particular DVI-D problem, and does not rear its ugly head with HDMI or DP configurations, or should i see the same issue there?
My understanding is that it largely depends on whether the display in question has its own (hardware) scaler, or depends on the GPU for that. In the past, that largely correlated with whether the display was internal or external. Internal (typically LVDS) displays in e.g. laptops typically didn't have scaler hardware, while external monitors connected by VGA or DVI typically did. It's a little less straightforward with modern external displays that may not support VGA/DVI-I.
(Note incidentally that DVI-I is essentially the same as VGA, and DVI-D is essentially the same as HDMI; converters between these are typically passive.)
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #49 from Sveinar Søpler cybermax@dexter.no --- (In reply to Henri Verbeet from comment #48)
(In reply to Sveinar Søpler from comment #45)
(In reply to Henri Verbeet from comment #44)
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
Is this a particular DVI-D problem, and does not rear its ugly head with HDMI or DP configurations, or should i see the same issue there?
My understanding is that it largely depends on whether the display in question has its own (hardware) scaler, or depends on the GPU for that. In the past, that largely correlated with whether the display was internal or external. Internal (typically LVDS) displays in e.g. laptops typically didn't have scaler hardware, while external monitors connected by VGA or DVI typically did. It's a little less straightforward with modern external displays that may not support VGA/DVI-I.
(Note incidentally that DVI-I is essentially the same as VGA, and DVI-D is essentially the same as HDMI; converters between these are typically passive.)
@mitchell4136 I have been looking a bit into this with the nVidia driver + xorg, and it is quite a few caveats the nvidia driver checks for during the init. I added this to my xorg.conf under the "Device" section:
Option "ModeDebug" "True"
This will print all modes the driver tries to check during init (bootup or possibly restart of x11), and can be viewed in the log /var/log/Xorg.0.log . For my monitor it actually said it was some checksum error with the monitors EDID "extended information" (or something like that), and it COULD explain why i do not have as many resolution options on my 1440p monitor as my old 1080p 2nd monitor.
Anyway, if you do that, you should be able to see if or why the driver will not "approve" of certain resolutions. It could be a number of things - one of them being somewhat of a broken EDID, or it could be that the monitor actually does not HAVE any internal upscaling/support for that resolution and rightfully reports (to the driver) that it only supports one mode. Need to check logs for that tho.
One thing to try could be (still under the "Device" section of xorg.conf):
Option "ModeValidation" "NoEdidModes"
and then add modes manually via the options:
Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Option "MetaModes" "1280x1024,1024x768; 1280x2024,800x600"
and so on. This would build modes manually, and is not directly self explanatory i guess. There is also the option to specify connected ports and whatnot for these options.
This is documented quite a bit here: https://download.nvidia.com/XFree86/Linux-x86_64/100.14.23/README/appendix-b... https://download.nvidia.com/XFree86/Linux-x86_64/100.14.23/README/chapter-13...
@Henri What i suspect the nouvau driver does is just use a much more leanient check of these "EDID readings" or whatever safetychecks the driver does natively, and just automaticall "add modes" similar to what i describe above, and THAT is why it works "better" with that driver. It does not mean it is the right thing to do, nor that it is the safe thing to do, even tho it may work most of the time. I think the nVidia driver tries it best to detect - within margins of capabilities reported - the correct settings, and sometimes gets it wrong for various reasons (bugged EDID as an example). I had quite a few modes on my 1440p monitor that was "not valid" due to it not existing in the EDID. If that is because the EDID has some errors in it, it is not nVidia's fault. I also checked my monitors EDID on http://www.edidreader.com/ and it showed the same errors there.
The wine workaround in the case of "only one resolution detected" is mostly working fine, but it might not be the REAL cause of the problems. As far as i can tell ASUS claims my 1440p monitor can support 1920x1080@120Hz, but from the debug log and xrandr it does not. Is it one of these "extended modes" with the wrong checksum, or is it a driver bug? I will do some more testing.
PS. It is not the first (or last) time that Asus is a bit slacking with their BIOS or EDID things.. Eg. there are loads of UEFI errors detected by the Linux kernel on many Asus UEFI bios', that Windows happily ignores, but require kernel patches or boot option overrides for linux - and Asus just brush it off with "Linux is not supported - wontfix". I guess other manufacturers are not THAT much better, and we all know what the Linux community thinks of "quirks and workarounds" in the case of manufacturer errors that they usually get away with in windows.....
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #50 from Henri Verbeet hverbeet@gmail.com --- (In reply to Sveinar Søpler from comment #49)
@Henri What i suspect the nouvau driver does is just use a much more leanient check of these "EDID readings" or whatever safetychecks the driver does natively, and just automaticall "add modes" similar to what i describe above, and THAT is why it works "better" with that driver. It does not mean it is the right thing to do, nor that it is the safe thing to do, even tho it may work most of the time. I think the nVidia driver tries it best to detect - within margins of capabilities reported - the correct settings, and sometimes gets it wrong for various reasons (bugged EDID as an example). I had quite a few modes on my 1440p monitor that was "not valid" due to it not existing in the EDID. If that is because the EDID has some errors in it, it is not nVidia's fault. I also checked my monitors EDID on http://www.edidreader.com/ and it showed the same errors there.
Perhaps differences in EDID validation play a role in some cases, but that's not the general case for why that fallback was introduced. The general case is about displays that really only report a single mode, and depend on the GPU to do scaling.
In case you're interested in the details about how this works in the Nouveau KMS driver, some key functions there are nouveau_connector_scaler_modes_add() and nouveau_conn_atomic_set_property() in the generic code, and then for e.g. GF110 nv50_head_atomic_check() and head907d_view().
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #51 from Sveinar Søpler cybermax@dexter.no --- (In reply to Henri Verbeet from comment #50)
In case you're interested in the details about how this works in the Nouveau KMS driver, some key functions there are nouveau_connector_scaler_modes_add() and nouveau_conn_atomic_set_property() in the generic code, and then for e.g. GF110 nv50_head_atomic_check() and head907d_view().
As i found out about my Asus monitor, it actually do NOT support 1920x1080 without GPU scaling.. This is why it is not listed by default with xrandr.
I do not know what xrandr would list for my monitor when using nouveau, but i did find out how to make the nVidia driver fill in non-edid modes.
Option "ModeValidation" "AllowNonEdidModes"
This makes the xorg init "validate modes" that are not listed in EDID, and i ended up with a lot more modes including 1920x1080. If these modes actually work as intended or not, i am a bit unsure of, cos i had some mouse-coordinate issues when i tested a D3D11 app with my newfound resolution of 1920x1080. It was scaling cos my monitor showed it used 2560x1440.
It kinda seem as nouveau does somewhat of the same as this, by creating scaling modes not found in EDID. The nVidia driver does not do this by default, and when using the setting above it may not be doing a good job at it either. It will require some more testing to figure out if all fullscreen scaling resolutions in various D3D games/apps works better for nouveau tho.
"It's a feature! Not a bug!" :)
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #52 from mitchell4136@gmail.com --- It appears my monitor too only supports lower resolution modes if GPU scaled. So what are we left with going forwards? Building the resolutions in xorg.conf using the nonedid option provided by Sveinar?
https://bugs.winehq.org/show_bug.cgi?id=51420
haphazardsasquatch@einrot.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haphazardsasquatch@einrot.c | |om
--- Comment #53 from haphazardsasquatch@einrot.com --- So I thought I'd test this, too. debian 11, nvidia 418.211.00 from non-free, winehq-devel 7.0~rc5~bullseye-1 and winehq-devel 6.11
The current version starts causing 99.5+ cpu usage in htop as soon as anything wine starts running (winecfg for example), 6.11 is clean.
I couldn't find a difference in connecting an external dvi display, even without one - just using the laptop's internal one - this bug occurs.
Given that we know the offending commit, matt has written a first patch and we have multiple independent reproductions, is there anything else a user can supply to help, so that this regression doesn't make it into the upcoming stable release?
thanks
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #54 from mitchell4136@gmail.com --- (In reply to haphazardsasquatch from comment #53)
So I thought I'd test this, too. debian 11, nvidia 418.211.00 from non-free, winehq-devel 7.0~rc5~bullseye-1 and winehq-devel 6.11
The current version starts causing 99.5+ cpu usage in htop as soon as anything wine starts running (winecfg for example), 6.11 is clean.
I couldn't find a difference in connecting an external dvi display, even without one - just using the laptop's internal one - this bug occurs.
Given that we know the offending commit, matt has written a first patch and we have multiple independent reproductions, is there anything else a user can supply to help, so that this regression doesn't make it into the upcoming stable release?
thanks
I think it was figured out that it's not exclusive to DIV-D displays, but rather displays that at the hardware level only support a single resolution (still potentially in multi-monitor configs), and require GPU scaling for lower resolutions. These kinds of monitors tend to like DVI-D as input but i saw another bug report that was marked a duplicate of this one that was on a laptop hooked up to an HDMI display.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #55 from alecov@mail.com --- I tried Wine 7.2 (which AFAIK includes matt's patch) with nvidia 510.54 and a secondary HDMI monitor.
The bug mentioned in #51891, which I believe is related to this bug, still happens in this case. Nvidia driver shows several device probes as described in #51891.
Does *NOT* happen without externally connected monitors.
Wine 7.2 Kernel 5.16.10 Nvidia 510.54 (any version *after* 495.46 also triggers this)
Happy to provide any further info on this.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #56 from mitchell4136@gmail.com --- I experienced the bug still in 7.2 also on the latest 510 Nvidia driver on arch repo. Matts patch is no longer functional due to multiple changes in the relevant files. I've uploaded an update of his patch at frogging-family community repo where matt uploaded his original patch.
It's still the same patch in practice but the git diff doesn't work because of the relevant lines being moved around.
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #57 from alecov@mail.com --- Any workarounds for this? Perhaps a registry setting or command-line flag to disable whatever kind of probing Wine is currently doing?
https://bugs.winehq.org/show_bug.cgi?id=51420
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #58 from alecov@mail.com --- I can confirm matt's patch still work in Wine 7.7.
Commit d171d1116764260f4ae272c69b54e5dfd13c6835 makes GetDeviceCaps reprobe devices/xrandr and for some reason GetDeviceCaps is called repeatedly in many cases I've tested (eg. every mouse move in a menu bar triggers it).
It seems making such a reprobe frequently is not good in general since it might cause drivers to disconnect/reconnect devices (cf. https://forums.developer.nvidia.com/t/x-server-with-loaded-nvidia-driver-spa...), so it should be done sparingly, perhaps during Wine boot, or perhaps with a configurable behavior through a reg key.
In this case the external HDMI/DVI connect/disconnect event also introduces a major performance hit. Even without a secondary monitor, my Xorg.0.log grows a couple GBs long due to endless "connected / disconnected" messages from the Nvidia driver.
The real bug (if not a straight Nvidia driver's one) seems to be why GetDeviceCaps is being called so much repeatedly.
https://bugs.winehq.org/show_bug.cgi?id=51420
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d171d1116764260f4ae272c69b5 | |4e5dfd13c6835
https://bugs.winehq.org/show_bug.cgi?id=51420
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
https://bugs.winehq.org/show_bug.cgi?id=51420
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com Assignee|wine-bugs@winehq.org |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #59 from Zhiyi Zhang zzhang@codeweavers.com --- Created attachment 73820 --> https://bugs.winehq.org/attachment.cgi?id=73820 patch
Please try this patch.
https://bugs.winehq.org/show_bug.cgi?id=51420
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|zzhang@codeweavers.com |wine-bugs@winehq.org Fixed by SHA1| |d81cf4ed555e87e469146829b86 | |bd3bca801efd9 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #60 from Zhiyi Zhang zzhang@codeweavers.com --- Fixed by d81cf4ed555e87e469146829b86bd3bca801efd9
https://bugs.winehq.org/show_bug.cgi?id=51420
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #61 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.0-rc4.
-
WineHQ Bugzilla