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.
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)
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.
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.
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):
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?
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.