TTYs are black on 340 and 343

When I switch to terminals via Ctrl+Alt+F1-F6, all I get are black screens. I tried setting kernel parameters per other threads here, like this one:

https://devtalk.nvidia.com/default/topic/531871/?comment=3745068

and I tried everything I enumerated in this thread on askubuntu:

Here’s my nvidia-bug-report log: http://paste.ubuntu.com/8079979/

Any ideas?

Hello,

I’m having the same issue too.
Tried both nvidia-340 and nvidia-343 from xorg-edgers (Ubuntu 14.04 with linux 3.16.1 from Mainline PPA).

When I switch to a TTY, the kernel crashes completely (and syslog shows lots of weird ^@^@^@ characters at the end of the file, when it crashed).

I can live without TTYs for now, but I hope it will be fixed soon.

Thanks.

You are using Apple hardware.

Sorry, here’s my report log: http://paste.ubuntu.com/8129936/

I’m using a GTX 750 on a non-Apple desktop.
So… I’m afraid it’s not Apple’s fault :D

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?

http://forums.debian.net/viewtopic.php?f=7&t=111288

Hi,
Apologies for the late answer.
Here’s cat /proc/cmdline:

BOOT_IMAGE=dev000:\EFI\Slackware\vmlinuz-iskren-3.16.1  root=UUID=de45e53c-318e-4e79-9460-e446a85f5b7f ro vga=0 rdblacklist=nouveau nouveau.modeset=0 ro

I have the nouveau driver blacklisted as follows:

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.

Is this issue also reproduce if you install OS in non-uefi, non-efi, legacy bios mode with eDP panel?

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?

Sorry for double-posting, I forgot my nvidia-bugreport:
http://pastebin.com/TjJ4vVaZ

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.

Any relation to https://devtalk.nvidia.com/default/topic/726285/linux/missing-vt-output-with-all-current-drivers-on-qhd-k2100m/ ?

still the same problem with v. 346.47!!!

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 have no words how frustrated i am currently.

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.

The docs clearly state that fb consoles of any kind are unsupported. Use a plain old vga console instead.

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

Well. Now it is 349.12 and the problem remains.

But finally I found the solution:

echo “blacklist nvidia” > /etc/modprobe.d/nvidia-wokarounf.conf

This prevents nvidia module from starting by udev. It is now started only by X system and does not break uvesafb TTYs.

jam666, Please share nvidia bug report of your system?

Here You are.