Created attachment 456856 [details] log output The problem did only happen when I used app-emulation/wine to play a game (namely MassEffect 2, I haven't tried others). It happens unexpectedly or at least I didn't find a pattern. I can not use ALT-tab to switch to another program. I can move the mouse pointer but I can not click any buttons, I can not leave the game (fullscreen mode) like calling the ingame console or using ALT-F4. The mouse pointer is trapped on that monitor where the game runs (I have two). The sound keeps playing and sound effects are played now and then too. I tried to get to the terminals via CTRL-ALT-F[1-6] but nothing happens. Switching (KDE) desktops via CTRL-ALT-[arrow-left,arrow-right] is just the same. What does work is the "magic keys" right-ALT-print-[s,u,b] (sync, unmount and boot). I downgraded to xf86-video-nouveau -1.0.12 and had no problems so far. $> sudo lspci | grep -i nvidia 03:00.0 VGA compatible controller: NVIDIA Corporation GK110B [GeForce GTX TITAN Z] (rev a1) 03:00.1 Audio device: NVIDIA Corporation GK110 HDMI Audio (rev a1) 04:00.0 3D controller: NVIDIA Corporation GK110B [GeForce GTX TITAN Z] (rev a1) $> uname -a Linux magic 4.8.2-gentoo_M16 #7 SMP x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux $> emerge --info | head -n3 Portage 2.3.3 (python 2.7.12-final-0, default/linux/amd64/13.0/desktop/plasma, gcc-4.9.3, glibc-2.23-r3, 4.8.2-gentoo_M16 x86_64) ================================================================= System uname: Linux-4.8.2-gentoo_M16-x86_64-Intel-R-_Core-TM-_i7_CPU_870_@_2.93GHz-with-gentoo-2.3 $> USE="opengl"; for PKG in $(equery -q hasuse $USE); do echo $PKG: $(equery -q uses $PKG |grep $USE); done | head -n 2 app-emulation/qemu-2.7.0-r7: +opengl app-emulation/wine-1.9.20: +opengl $> USE="opencl"; for PKG in $(equery -q hasuse $USE); do echo $PKG: $(equery -q uses $PKG |grep $USE); done | head -n 2 app-emulation/wine-1.9.20: +opencl media-libs/mesa-13.0.2: +opencl $> eix app-emulation/wine$ | grep -i install Installierte Versionen: Version: 1.9.20^t
Created attachment 457170 [details] happens when using FFox as well
Have you reported this upstream? We're not nouveau driver developers, so we're very unlikely to be able to solve this problem.
I'll do, ASAP.
https://bugs.freedesktop.org/show_bug.cgi?id=99202
Please put x11-drivers/xf86-video-nouveau-1.0.12 back in the portage tree. That's the only version that does not result in recurring system crashes. If the recent xorg-server (e.g. 1.18.4) needs to be reemerged emerge fails because the needed x11-drivers/xf86-video-nouveau-1.0.12 ebuild is not available. As well, please keep xorg-server-1.18.4 because xorg-server-1.19.x refuses to build when >=x11-drivers/xf86-video-nouveau-1.0.13 is not emerged - thanks!
What happens if you use the modesetting driver instead of nouveau? You may be able to copy the old xf86-video-nouveau ebuild to a local overlay and then apply the xorg-server-1.19 compatibility patches. https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=6473b68762b0dca2dfccfdfc74100398b7459296 https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=a964931e8dc4e06c27749edb4993a656dc261d75
[08:45] < imirkin_> | mattst88: i highly doubt the issue is related to a xf86-video-nouveau upgrade. if you look at his log, the MassEffect2.exe game does something bad (via the GL driver), which causes nouveau to fail at recovery. You also say it happens "less often" with 1.0.12 in the upstream bug report, not that it doesn't happen. There's also no substantial changes from 1.0.12 to 1.0.13. I don't see how it could be the culprit. Unfortunately, I think this bug boils down to "nouveau is unstable" to which everyone says "yeah..." unsurprised :(
(In reply to Matt Turner from comment #7) > i highly doubt the issue is related to a xf86-video-nouveau upgrade. > if you look at his log, the MassEffect2.exe game > does something bad (via the GL driver), which causes nouveau to fail at > recovery. Shouldn't the video driver refuse to do "bad things" when something bad was requested by a program? If downgrading helped to a huge amount, why would the upgrade not be at least part of the problem? > You also say it happens "less often" with 1.0.12 in the upstream > bug report, not that it doesn't happen. Correct, anyhow when I downgraded to 1.0.12 the problem ocured only 3 times in two month instead of every two hours (when I was using wine to play MassEffect2). Hm … the system froze in very similar intervals of about two hours - is "fifo" in the logs refering to a something like a queue? The portage log file that is closest to the date of my bug report on freedesktop.org and that has something to do with lower level graphics is media-libs:mesa-13.0.2:20161130-010350.log.gz Is it possible that mesa has an influence here? > There's also no substantial changes from 1.0.12 to 1.0.13. > I don't see how it could be the culprit. How big is the difference between .13 and .14 then? Both .13 and .12 cause the freeze, maybe 1.0.14 fixes the problem? I'm testing some kernel settings. My system was not able to reach a suspend state since a few month. The log showed [kernel] [755405.277685] nouveau 0000:04:00.0: DRM: failed to idle channel 0 [DRM] [kernel] [755405.277695] pci_pm_suspend(): nouveau_pmops_suspend+0x0/0x80 returns -16 [kernel] [755405.277699] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -16 [kernel] [755405.277704] PM: Device 0000:04:00.0 failed to suspend async: error -16 From the changes I made only CONFIG_VGA_ARB_MAX_GPUS seems to play a role. I changed it's value from 16 to 256 with the result that standby and hibernate work perfectly now. The next step could be to update the nouveau driver, hoping that the freeze issue is fixed just like the suspend issue. I know that the error looks completely different but you never know. However, until I didn't manage to make emerging xf86-video-nouveau-1.0.12 possible on my system I will not risk breaking it by doing an update with knowing that there is no way back. Is there any other information I can supply? USE flags maybe?
Yes, the nouveau developers suspect Mesa is the problem. There are very few changes in .13 and .14: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/log/ Again, since we are not nouveau driver developers, we cannot really help. I suggest joining #nouveau on irc.freenode.net and asking imirkin for help.
correction: The kernel config changes did *not* fix the suspend issue - it just took some more time until it deceided to stop working…
Upstream driver bugs like this are really outside the capabilities of a distro to fix.
