[BUG] Driver v375.10 and newer not returning to the console on shutdown

Normally, when shutting down the computer or rebooting it, the X server gets stopped and the display returns to the console (or splash screen for people using one, which is not my case), allowing to see the shutdown scripts log messages.

Unlike all older NVIDIA driver versions, v375.10 does not return to the console when the X server is shut down. In order to try and work around this annoying issue I added:

if [[ "$newrunlevel" = "0" || "$newrunlevel" = "6" ]] && [ -f /var/lock/subsys/dm ]; then
	chvt 1
	sleep 2
fi

to the /etc/rc.d/rc script (I’m using the good old SysVInit scripts) so to force the return to the console (note that, strangely, the sleep is necessary, else the return never happens), but even so, sometimes the X server restarts (like if the driver crashed it on exit) instead of shutting down…

There’s definitely something fishy with that driver beta version and the console management…

Can you please generate and attach an nvidia-bug-report.log.gz file? 375.10 will use a newer console restore method most of the time that might still have some kinks that need to be worked out.

Here you go.
nvidia-bug-report.log.gz (225 KB)

Thanks. I installed PCLinuxOS to give this a try, but it’s using a much older kernel and it’s using vesafb instead of the ‘simplefb’ that yours is using. Where did you get the kernel you’re using? If you built it yourself, can you please send me the .config file you used?

I build all my kernels from Linux official sources: they are vanilla kernels, but tailored for the hardware I’m running them onto (i.e. all hardware-specific drivers are linked to the kernel instead of being built as modules).

I’m attaching to this message the config file I used for the kernel v4.8.4. Both vesafb and simplefb are compiled into the kernel.
config-4.8.4.gz (20.7 KB)

Oh, also:

  • I’m loading Linux with lilo, and using the “vga=791” mode in lilo.conf.
  • The kernel (and modules) are compiled with gcc v4.6.4 instead of PCLinuxOS’s buggy gcc v4.9.2. Since there is no PCLinuxOS package for gcc v4.6, I may provide you with the packages I built myself for it, if you need them.

Oh wow, that’s a blast from the past. I installed lilo and booted a kernel built with your config (but with gcc 4.9.2) and verified that it’s using simplefb and that vga=791 makes it use the same r5g6b5 1024x768x16 mode that’s in your log. However, restoring the console works fine for me. Is there anything else that’s unique about your configuration that might make a difference?

Does the problem still occur if you use GRUB or the stock PCLinuxOS kernel?

Why do you think I chose “dinosaur” as a pseudonym ?.. :-D

Hmm… I’m using gdm as the session login manager, and Mate (v1.14) as the desktop environment…
The problem occurs for me when I reboot or shutdown the computer from the Mate session or gdm.

I’m not going to change the boot-loader, sorry… Mind you, my setup is quite complex with no less than 6 different boot partitions (and not only Linux ones) on this system, software RAID, etc. I don’t want to screw it up just for a test, especially since anyway, I refuse to give up lilo for grub.

I got rid of PCLinuxOS’ kernel, initrd, bootsplash and all associated tools, that I have no use for with my “solid state” (i.e. not needing any module to boot) kernels… But I don’t see why it would make a difference. Unless you suggest that an incompatibility with simplefb could be the problem ?.. I could recompile without it, and see if v375.10 fares better with vesafb.

I did more testing…

Now, I can remember why simplefb is compiled in my kernels: with vesafb alone, I simply never get a console…

I also tried v375.10 on another Linux partition/distribution (old Mandriva 2010.2 running kernel v4.1.35 and Gnome 2): same symptoms as under PCLinuxOS/kernel 4.8.5 (just updated to the latter)/Mate v1.14.

Also, once logged into a Gnome (Mandriva 2010.2) or Mate (PCLinuxOS) session, issuing “service dm stop” from a terminal blanks the screen (the return to the console never happens), even after I press ALT CTRL F[1-6] or ssh into the computer from another and try to “chvt” from there; if, still ssh-ing, I restart the display manager (service dm start), I get back the display and can again switch normally to the consoles (chvt or ALT CTRL F[1-6]). Note however that the X server then got started onto the second X display (display :1 instead of :0, ALT CTRL F8 to get to it, instead of ALT CTRL F7) and cycling again with “service dm stop/start” doesn’t change anything.
I also verified (via the ssh session) that no defunct X (or gdm) process was left after “service dm stop”, so it’s definitely a driver issue.

I’m returning to driver v370.28, since this bug is just unacceptable for my use cases. Let me know if you need more info/testing with other beta drivers.

Bumping this thread, since the now released (it didn’t deserve such a status, IMHO) 375.20 driver suffers from the same bug !

nvidia-bug-report.log.gz (212 KB)

I can confirm this issue affects me as well.

Right after the X server exits, all text consoles are totally blank. NVIDIA programmers must have done something to the text console management code. Please, if possible find the change and revert it.

GTX 1060 here on top of Asus P8P67 Pro motherboard without UEFI with the latest available BIOS (3602).

Here’s my kernel boot options (vesafb 1920x1080 at 16bit mode with MTTR acceleration and Ywrap):

vga=0x34c video=vesafb:mtrr:3,ywrap

I run vanilla kernel 4.8.17 on CentOS 6.8 here.

Can you please attach an nvidia-bug-report.log.gz file from 378.09 after reproducing this problem?

What mode is 0x34c? I don’t see it in the common tables of VBE modes. Also, can you please try other vga= modes and also vga=0x34c but without the video= options?

0x34c is pretty standard: 1920x1080x16bit

  1. vga=0x34c and no other options - FAILURE
  2. vga=0x317 + video=vesafb:mtrr:3,ywrap - FAILURE
  3. vga=0x317 and no other options - FAILURE

0x317 - 1024x768x16bit

In short all recent NVIDIA drivers fail to restore “graphical” text mode after exiting the X server.

Here’s my nvidia bug report:
nvidia-bug-report.log.gz (106 KB)
config-4.9.gz (21.1 KB)

Aaron,

Have you had the time to look into this issue?

Bump!

On log i see :

Jan 31 19:57:24 localhost kernel: [ 2828.975595] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  378.09  Sat Jan 14 22:40:55 PST 2017
Jan 31 19:57:25 localhost kernel: [ 2829.745451] NVRM: Your system is not currently configured to drive a VGA console
Jan 31 19:57:25 localhost kernel: [ 2829.745454] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
Jan 31 19:57:25 localhost kernel: [ 2829.745455] NVRM: requires the use of a text-mode VGA console. Use of other console
Jan 31 19:57:25 localhost kernel: [ 2829.745456] NVRM: drivers including, but not limited to, vesafb, may result in
Jan 31 19:57:25 localhost kernel: [ 2829.745457] NVRM: corruption and stability problems, and is not supported.

Is this issue repro if you replace kernel parameter : vga=0 rdblacklist=nouveau nouveau.modeset=0

I have no nouveau module compiled in. With vga=0 it’s not reproducible of course, but like we’ve already said 1000 times, VesaFB used to work fine before and someone broke it recently.

I’m having the same issue, except that passing vga=0 to the kernel doesn’t fix it for me. Possibly relevant: I’m using rEFIND’s kernel stub loader, and my monitor is a LG 6300 series TV.

nvidia-bug-report.log.gz (227 KB)

Is the old driver worked for you , like 378.09? I think you are UEFI mode, however issue reported for legacy mode of OS.

We are tracking this issue under Bug 200279068 . Let us know if same repression affected on other OS’s too and for other users?