375.10 drivers are the first with this regression.
It’s impossible to know if it affects other OSes, because I don’t use Solaris/FreeBSD, and Windows cannot have this issue, because it works completely differently.
I don’t have UEFI mode enabled - I run in plain old BIOS mode.
Hi all, Sorry I mean to say Is other flavors of Linux are also affected? Please report here and attach nvidia bug report too.
This bug comes about from the interaction with the Linux kernel - yes, all Linux distros are affected. This is not a userspace bug - i.e. it doesn’t matter what your distro or X.org versions are.
The bug report was attached earlier. In fact there are several in this thread.
@sandipt & birdie
It looks like to me that this bug might be related with the interaction between the new console restoration code in v375+ and the video BIOS of the graphics card: when running the same distro with the same kernel version and configuration (modulo the specific hardware/devices of each motherboard), especially the same graphics configuration (vesafb) and boot up VESA mode, on two different systems with different NVIDIA graphics card, I get the problem on one (my main PC, fitted with a KFA2 GTX 970) and not on the other (my formerly main PC, fitted with with a Gygabyte GTX 660)…
The new v378.13 driver is still affected by this bug.
Bump !
! bumP
We spent some time trying to reproduce these posters’ problems. We even built dinosaur_'s custom kernel config and booted it using LILO on the same GPU and couldn’t reproduce it. we’ll try birdie config now.
Not sure why people are not using the UEFI functions of newer boards. The efifb driver works just fine with the latest driver and I have no issues restoring my native resolution text console after the X server exits even at 2560x1440.
jon@enigma /data0/Source/mainline $ dmesg| grep efifb
[ 1.179672] efifb: probing for efifb
[ 1.179679] efifb: framebuffer at 0xc0000000, using 23040k, total 23040k
[ 1.179679] efifb: mode is 2560x1440x32, linelength=16384, pages=1
[ 1.179679] efifb: scrolling: redraw
[ 1.179680] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Perhaps because people don’t use a “newer board” ?.. Or because people keep booting from BIOS on some UEFI-capable boards ?
Your remark is totally irrelevant. What people use is not the problem. The fact all NVIDIA drivers versions prior to v375 used to cohabit well with vesafb (and simplefb) Linux drivers while newer versions lamentably fail and lock the system in a blank screen is simply a sign that there is a BUG in the new console restoration code.
Like I mentioned in my 02/13/2017 post, it could well be an issue with the video BIOS of the card: the affected system got a KFA2-GTX970-EXOC and its video BIOS version is 84.04.36.00.22.
Also, why don’t you simply revert to the old console restoration code, which worked fine, or add a switch (e.g. an environment variable) giving the user the choice to use the old or the new code (i.e. include both in the driver, execute new code by default, or the old code when a given environment variable is set) ?
Perhaps the old code depended on something that was later removed.
What was removed can be re-added… You’ll not teach a professional programmer like me what can be done or not with code… :-D
There are costs involved with maintaining something deprecated and unused, and you should know that as a programmer.
NVIDIA is not a charity and maybe re-adding this code is just too much work for them, which means too much money for a feature which is broken for a couple of people in the world (maybe more, but other people don’t even know about the existence of this forum and don’t understand how to describe the issue they’re having).
I’m most interested in a FB implementation which will instantly solve this issue and makes switching to console almost instant, vs. right now, when it takes up to 2 seconds to switch video modes.
I do hope Aaron Plattner (or someone of a higher rank in NVIDIA - I’ve no idea what his liabilities are) will reconsider his decision about FB support because I’m ready to sacrifice the ability to change drivers on the fly vs. the ability to have a fast text VT.
The newer console restore goes through the exact same mode setting code as other software, such as the X driver. It’s also the same path a hypothetical new framebuffer implementation would use, which is why I want to get to the bottom of why it’s not working for you. Whatever problem is preventing the console from working on your system would likely affect an FB console implementation as well.
When you guys generated your bug reports, was that from a working X session, or via SSH after reproducing the console restore problem?
Can you please try running nvidia-bug-report.sh via SSH after reproducing the problem with 378.13?
Yes, it was from a running X.org session because last time I checked, nvidia-bug-report runs a lot of X.org commands to fetch information, so, a report from an SSH session won’t be as useful and informative.
Here’s a bug report from an SSH session when my monitor is “dead” (runlevel 5 → runlevel 3). Funnily the monitor says “HDMI input” but the screen is completely black, so there’s something coming from the GPU but it’s not actual pixels.
Aaron, if you’re interested, I can provide you with full SSH access to my PC. It will require some time because I don’t want to give you access to my actual HDD. ;-)
nvidia-bug-report.log.gz (91.4 KB)
For mine, it was done from a working X11 session…
No problem, attaching one such report to this message.
I could do that too: I’d setup a fresh system reproducing the problem on a spare hard drive, and could give you root ssh access to it. We however would need to set a rendez-vous, since I’m in UTC+1 (CET/Paris) timezone…
nvidia-bug-report.log.gz (201 KB)
Just wanted to join this discussion as I just have encountered this bug in Arch Linux with 378.13 driver and my GTX 1070. After I stop lightdm then I land in blank screen.
Also I experience some terrible tearing with XFCE, ForceCompositionPipeline=On does not really help.
I would love to attach the file, but I have absolutely no idea how I can put my nvidia-bug-report output in my reply. No attachment button or whatsoever.
Thanks to dinosaur_ I have manager to add the report. (This forum software is super-confusing)
nvidia-bug-report.log.gz (98.1 KB)
I too got confused when they changed the forum software… The attach button is in fact a green paperclip icon which appears whenever you hover the mouse cursor on a message you posted previously (i.e. you must post the message first, then click on that paperclip icon to attach the file to it)…
Looks like a lot more people are affected by the new console restore code path than NVIDIA anticipated. Most people just don’t care that their screens turn black on reboot and probably attribute it to some other bug/problem.
(The attach icon appears only after making a post which is twice counterintuitive).