I have the same issue on a Lenovo-Y510P. I’m attaching the nvidia-bug-report.sh logs.
EDIT: Re-uploading logs as the old ones had “Can’t connect to :0” errors from some tools. nvidia-bug-report.log.gz (309 KB)
What was the previous driver version worked for you? Make sure to blacklist nouveau .
You can add Nouveau Driver in /etc/modprobe.d/blacklist.conf file. OR create file like /etc/modprobe.d/disable-nouveau.conf with below entries
blacklist nouveau
options nouveau modeset=0
And add kernel parameter : vga=0 rdblacklist=nouveau nouveau.modeset=0
Also Get rid of nouveau in the initramfs image by:
cd /boot
dracut -f
and reboot.
This should stop it from reporting in lsmod and lspci.
Two of the reporters boot via EFI and are therefore using an efifb console. Last I heard is that the nvidia driver cannot restore a console in this case when the display is connected via display port, which is exactly what Apple for example does. Has this changed recently?
axtroz@Slack64-Y510P [~]$ ls /etc/modprobe.d/
BLACKLIST-nouveau.conf README
axtroz@Slack64-Y510P [~]$ cat /etc/modprobe.d/BLACKLIST-nouveau.conf
# We use the NVIDIA proprietary driver, so disable this
blacklist nouveau
However, lspci -k | grep nouveau still shows the Nouveau driver along nvidiafb, can this cause the problem?
Before updating to 340.32, I was using 337.12 (beta) on the very same setup and TTYs were working correctly.
Exactly the same issue here, on an Alienware 17 with 3D display. The nvidia GPU is then directly connected to the display, DFP-3 is “DisplayPort” here.
Nouveau is not even installed.
Kernel 3.16 takes over the EFI-fb from the EFI perfectly fine using the new SimpleFB. I get a Full-HD terminal without any resolution-switching-flickering between first display initialization (EFI), boot-loader (refind) and linux shell.
Everything is perfect until I do a modprobe nvidia - then my terminals are lost.
Non-EFI non-secure boot is not an option to me. Do I have any way (apart from switching to nouveau) to get back my TTYs?
I know you can not make any statements about future support, but is this bug at least tracked internally in the nvidia bug-tracker?
Note you can also see in there that after detection of nvidia 3D vision, it’s deactivated, although OpenGL Quadbuffered 3D with 3D Vision is working perfectly fine in windows with the same card (as nvidia announced a while ago, OpenGL with 3D vision is now supported on GeForce hardware - but sadly, seems this holds for windows only).
I’d like to add that I also have this issue on my ROG Swift gsync display. DisplayPort only, no other inputs available. Also, it has an Nvidia logo on the box and base and an Nvidia FPGA inside so I hope it’s well supported. I can get to terminals on initial boot but once I enter X I cannot go back to standard vtty’s.
this is pretty bad and please needs to be fixed ASAP. the reason i was upgrading my system was that i could now use hibernation mode in an effective way (more RAM, faster HDD, etc-.) but now i can’t even standby!!!
i tried various ideas with nomodeset and all that stuff but the problem remains.
I confirm the problem with 346.47
Last nvidia-driver version used, which kept the VTs in working state was 331.113. However it cannot be used anymore with kernels >=19.
I have tried already a variety of workarounds found on different forums and blogs, but all is in vain.
Please take urgent steps to solve the bug as current state of things makes the system half-usable.
PS GTX 750, 3.19.1-gentoo #6 SMP PREEMPT Thu Mar 12 19:34:52 MSK 2015 x86_64 AMD Athlon™ X4 750K, standard bios boot, uvesafb as FB driver, 1920x1080 DVI output.
PPS Should there be more information from my part - do not hesitate to request.
Ok, then. I recompiled kernel without any fb console driver and started it with “video=vesa:off vga=normal”. It gave me that awful 640x480 vga console while boot. Nevertheless after X started - no TTYs are available (the monitor goes into power-saving mode).
Here is the dmesg output
Here comes the kernel config