With x11-drivers/nvidia-drivers-358.09 it is still possible to switch from the graphical console (Xorg on tty7) to the text console (tty1) with Ctrl+Alt+F1. When switching back to the graphical console with Alt+F7 the system hangs totally. Even htop which I once started before switching back does nothing anymore, at least the screen doesn't show any changes anymore. The same happens when I switch from tty7 to tty1, stop xdm (`/etc/init.d/xdm stop`), and start X by `startx`. The only way is to pressing the computer's reset button. Downgrading to x11-drivers/nvidia-drivers-355.11-r2 fixes the problem. It's unrelated to the newly introduced USE flag "kms". I tried it with "kms" set and unset. Reproducible: Always
I confirm this issue. Had to downgrade to 355.11-r2 as well. USE flag "kms" changing did not help.
Created attachment 417328 [details] emerge --info output
exactly the same behavior here.
Same issue here with or without additional new nvidia_modeset kernel driver loaded on desktop and laptop (x11-base/xorg-server-1.17.4, sys-kernel/gentoo-sources-4.1.12). Even tried booting without video=uvesafb (thought it might be related). As previous reporters mentioned, downgrading driver to 0/355 series works as expected.
Did not mention before, that I've also tried with latest 358.13 driver. Same issue. There is at least one improvement over 358.09 here, where I can now logout from KDE-4 to KDM and system doesn't crash, where previously system crashed on logout the same way as switching tty.
Still crashing with 358.16.
Same issue even on 361.18. Connecting through ssh works for me, and it shows the X process using one core at 100%. Running strace/ltrace against it doesn't show any activity. However perf top -p <hung-pid> shows the process hung on an obscured call to a function in the nvidia_modeset kernel module (I think). Trying to forcefully remove the module hangs the command as well (cannot ctrl+c out of it).
As #7 already mentioned, issue persists with nvidia-driver 361.18. One core/thread is stuck at 100% if I switch to console and there's no way of restarting/killing X or even removing nvidia/nvidia_modeset module.
Please tell Nvidia about this, and tell me when they release a version that resolves the issue.
Created topic on nvidia boards at https://devtalk.nvidia.com/default/topic/912455.
Looks like uvesafb and v86d combined with nvidia_modeset kernel module seems to trigger this issue. Since there's no other solution, I've just removed initramfs with v86d (/usr/share/v86d/initramfs) and uvesafb module, replaced it with "VESA VGA graphics support" (FB_VESA) and changed boot param video=uvesafb:1920x1200-32@60 with vga=845 (based on Mode 0x034d: 1920x1200 (+7680), 24 bits for my board). VT is a bit slow now, but everything works as expected.
(In reply to Uros from comment #11) > Since there's no other solution, I've just removed initramfs with v86d > (/usr/share/v86d/initramfs) and uvesafb module, replaced it with "VESA VGA > graphics support" (FB_VESA) and changed boot param > video=uvesafb:1920x1200-32@60 with vga=845 (based on Mode 0x034d: 1920x1200 > (+7680), 24 bits for my board). > > VT is a bit slow now, but everything works as expected. there's still simple fb which works fairly well http://lists.infradead.org/pipermail/linux-rpi-kernel/2013-April/000512.html https://forums.gentoo.org/viewtopic-p-7482038.html https://forums.gentoo.org/viewtopic-t-1013132.html
Not sure if it helps, but I've a similar configuration here for one of my gentoo systems, nvidia-drivers-358.16-r1 driving a "GeForce GT 630", sys-kernel/gentoo-sources-4.1.15-r1/amd64, and each time I attempt to switch from graphics (2560x1440x32) mode to text mode (video=uvesafb:2560x1440-32) I get this message recorded in my syslogs: nvidia-modeset: ERROR: GPU:0: Idling EVO timed out: 0x0000857d:0:0:0x00000040 and X hangs, as already reported, the only way out left being a system reboot. Downgrading to nvidia-drivers-355.11-r2, with the same kernel, without changing any other configuration, solve the problem.
This has never worked for me on UEFI, and even on BIOS, it often didn't work. I think this can't be fixed given the proprietary nature of the drivers.
