Bug 201461 - switching back to sc(4) or vt(4) console fails with nvidia.ko
Summary: switching back to sc(4) or vt(4) console fails with nvidia.ko
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
Keywords: vt
Depends on:
Reported: 2015-07-10 20:15 UTC by Tony Narlock
Modified: 2019-08-13 23:20 UTC (History)
14 users (show)

See Also:

sudo nvidia-debugdump -D (14.78 KB, application/zip)
2015-09-30 18:08 UTC, Tony Narlock
no flags Details
sudo nvidia-bug-report.sh (38.74 KB, application/gzip)
2015-09-30 18:09 UTC, Tony Narlock
no flags Details
nvidia-bug-report.sh log (29.09 KB, application/gzip)
2017-01-22 17:40 UTC, Matthew Fioravante
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Narlock 2015-07-10 20:15:24 UTC
https://wiki.freebsd.org/Graphics/WITH_NEW_XORG says that this should work with nvidia. However it gives a blank black screen. I've been able to type in it.

Please let me know what I can provide for better debug info.

$ freebsd-version -ku; uname -apKU
FreeBSD z600 10.1-RELEASE-p14 FreeBSD 10.1-RELEASE-p14 #7: Sat Jul  4 07:18:36 CDT 2015     root@z600:/usr/obj/usr/src/sys/MYKERNEL  amd64 amd64 1001000 1001000

Card: Nvidia 980GTX


$ kldstat
Id Refs Address            Size     Name
 1  145 0xffffffff80200000 1756638  kernel
 2    1 0xffffffff81957000 2681d8   zfs.ko
 3    2 0xffffffff81bc0000 6778     opensolaris.ko
 4    1 0xffffffff81bc7000 211e8    geom_eli.ko
 5    3 0xffffffff81be9000 352b8    crypto.ko
 6    1 0xffffffff81c1f000 240b0    geom_mirror.ko
29    1 0xffffffff81d3c000 15050    aio.ko
30    1 0xffffffff81d52000 4a08     coretemp.ko
31    1 0xffffffff81d57000 11de0    tmpfs.ko
32    1 0xffffffff81d6b000 5a28     aesni.ko
33    1 0xffffffff81d72000 18590    if_urtwn.ko
34    1 0xffffffff81d8b000 b87480   nvidia.ko
35    3 0xffffffff82913000 b98c0    linux.ko
36    3 0xffffffff829cd000 6cfc0    vboxdrv.ko
37    1 0xffffffff82c11000 2b58     uhid.ko
38    1 0xffffffff82c14000 357b     ums.ko
39    2 0xffffffff82c18000 29b2     vboxnetflt.ko
40    2 0xffffffff82c1b000 b998     netgraph.ko
41    1 0xffffffff82c27000 40a7     ng_ether.ko
42    1 0xffffffff82c2c000 3f64     vboxnetadp.ko
43    1 0xffffffff82c30000 9d33     linprocfs.ko
Comment 1 Ed Maste freebsd_committer 2015-07-19 18:30:24 UTC
To clarify, do you mean that X works fine, but after you exit X you are left with a persistent black screen?
Comment 2 Tony Narlock 2015-07-26 03:31:38 UTC
(In reply to Ed Maste from comment #1)
Thank you, and I apologize for the late reply, Ed.


X works great. I play Dota 2 on it through Wine and its great. As well as Unity3D. I'm delighted by how great things are.

After I exit X, the screen is black. Also, this happens if I ctrl-alt-Fn out of X :(

What can I do to give debug info / more information?

(I have a firewire card card installed and and hooked up dcons, is there anything I could provide from that)
Comment 3 Edward Tomasz Napierala freebsd_committer 2015-09-08 14:31:06 UTC
Does it happen only with vt(4), or also when running with sc(4) driver instead?
Comment 4 Tony Narlock 2015-09-08 15:43:24 UTC
(In reply to Edward Tomasz Napierala from comment #3)

How do I switch to sc(4)?

What do I run to detect if I'm running vt(4) or sc(4)
Comment 5 Ed Maste freebsd_committer 2015-09-08 15:46:56 UTC
(In reply to Tony Narlock from comment #4)
> How do I switch to sc(4)?

You can add kern.vty=sc to /boot/loader.conf, or set it from the loader prompt.

> What do I run to detect if I'm running vt(4) or sc(4)

sysctl kern.vty will show you:
% sysctl kern.vty
kern.vty: vt
Comment 6 Tony Narlock 2015-09-08 16:23:50 UTC
(In reply to Ed Maste from comment #5)

Hi again Ed,

Ok, I updated /boot/loader.conf and sc(4) is loading.

# sysctl kern.vty
kern.vy: sc

So, I get a black screen again with sc(4). Just like with vt(4)

I do notice I can go back to X fine with I switch between (F1, F2... back to the console X is on). I haven't tried doing this with vt, but I'll go back and report my progress.

Another note: earlier I was using 10.1 RELEASE. I am producing the same behavior on 11-CURRENT.

$ freebsd-version -ku; uname -apKU
FreeBSD z600 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r286893: Tue Aug 18 18:44:28 UTC 2015     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64 amd64 1100079 1100079
Comment 7 Tony Narlock 2015-09-08 16:31:05 UTC
(In reply to Tony Narlock from comment #6)

To follow up - I rebooted back into vt(4) and confirm I get the same behavior on sc(4).

I get a black screen. I can (blindly) enter keyboard commands. For instance, if I were to exit out of X, I could restart X by typing into the keyboard (startxfce4, startx, service slim start).

If I keep X open and go to Ctrl-Alt-F1....F8, It will black screen. Alt-F9 brings me back into X.
Comment 8 Tony Narlock 2015-09-09 17:30:15 UTC
I have a firewire card and can do dcons.

Is there any information I could provide from debug info that'd be useful?
Comment 9 John Baldwin freebsd_committer freebsd_triage 2015-09-25 17:57:54 UTC
Note that this isn't really about vt(4) since you report the same behavior with syscons(4).  I have this device:

vgapci0@pci0:1:0:0:     class=0x030000 card=0x15263842 chip=0x104010de rev=0xa1 hdr=0x00
    vendor     = 'NVIDIA Corporation'
    device     = 'GF119 [GeForce GT 520]'
    class      = display
    subclass   = VGA

on a system running 10.2.  I am currently using syscons(4) (since it is the default in 10), but I also tested it with vt(4) back when vt(4) was merged to 10.  I can exit out of X fine and have the screen restored, and I can switch back to ttyv0 while in X (it does take about 5 seconds for my screen to be restored when I switch back via Ctrl-Alt-F1).

Perhaps this is an issue in the nvidia driver that only affects certain models?
Comment 10 Tony Narlock 2015-09-29 01:07:20 UTC
(In reply to John Baldwin from comment #9)
To clarify, you can switch outside of X, you can see a terminal and text entry will work?

For me, I will get no signal from my monitor.

Alt-F8 will get me back to X.

Please let me know if there are any commands / build flags / logs I can provide to give a better report.
Comment 11 Andy Ritger 2015-09-30 00:02:18 UTC
Hi Tony.

Restoring the text console can be fragile.  This is often sensitive to:

* The NVIDIA driver version.
* The particular graphics board you are using.
* How the monitor is connected to the graphics board (DVI, 15-pin VGA, DisplayPort, etc).

Please be sure you have the latest version of the NVIDIA FreeBSD driver.
I think the latest right now is 355.11:


If you can experiment with either different graphics boards or different
connectors between the monitor and the graphics board to attempt to
isolate which parameters repro or don't repro this bug, that would help.

A few other things:

* Does the monitor still have sync?  Most monitors have an LED (e.g., green when active, amber when sync is lost, blank when powered off)  Distinguishing between those will help to understand if restoring the text console is driving modetimings that the monitor can't handle (monitor lost sync), or if something about redrawing the console got broken (image on monitor is black, but monitor is active and did not lose sync)
* The NVIDIA FreeBSD driver provides a script, nvidia-bug-report.sh, that will gather various information about your GPU and system.  It would be helpful to attach that to this bug.
* The NVIDIA FreeBSD driver includes a utility, nvidia-debugdump, which can capture various GPU hw state.  Could you run `nvidia-debugdump -D` and attach the file it produces?

Comment 12 Tony Narlock 2015-09-30 18:07:03 UTC
(In reply to Andy Ritger from comment #11)

VP2770-LED monitor, via Displayport

NVIDIA-FreeBSD-x86_64-355.11 is what I'm using. Note I did have to go in manually and edit nv-freebsd.h to support this:

./nv-freebsd.h:25:2: error: This driver does not support FreeBSD 11.x/-CURRENT!

$ freebsd-version -ku; uname -apKU
FreeBSD z600 11.0-CURRENT FreeBSD 11.0-CURRENT #24: Mon Sep 28 15:30:02 CDT 2015     root@z600:/usr/obj/usr/src/sys/MYKERNEL  amd64 amd64 1100079 1100079

> * Does the monitor still have sync?  Most monitors have an LED (e.g., green when active, amber when sync is lost, blank when powered off)  Distinguishing between those will help to understand if restoring the text console is driving modetimings that the monitor can't handle (monitor lost sync), or if something about redrawing the console got broken (image on monitor is black, but monitor is active and did not lose sync)

No signal sign.  Amber light on power button.

Then blue when I switch back to X.

Attaching dumps after this post.

Probably unrelated, bug #203456: packaging requesting to overwrite manually installed nvidia-driver with packaged version (nvidia-driver-340).  I'm confident 350.11 is installed, but actively trying to rule out and off chance libraries left over from an uninstalled nvidia-driver could be interfering.
Comment 13 Tony Narlock 2015-09-30 18:08:32 UTC
Created attachment 161578 [details]
sudo nvidia-debugdump -D

(In reply to Andy Ritger from comment #11)
Comment 14 Tony Narlock 2015-09-30 18:09:22 UTC
Created attachment 161579 [details]
sudo nvidia-bug-report.sh

(In reply to Andy Ritger from comment #11)

$ sudo nvidia-bug-report.sh

nvidia-bug-report.sh will now collect information about your
system and create the file 'nvidia-bug-report.log.gz' in the current
directory.  It may take several seconds to run.  In some
cases, it may hang trying to capture data generated dynamically
by the FreeBSD kernel and/or the NVIDIA kernel module.  While
the bug report log file will be incomplete if this happens, it
may still contain enough data to diagnose your problem.

Please include the 'nvidia-bug-report.log.gz' log file when reporting
your bug to freebsd-gfx-bugs@nvidia.com.

Running nvidia-bug-report.sh... complete.

The file nvidia-bug-report.log.gz has been created; please send this
report, along with a description of your bug, to
Comment 16 Matthew Fioravante 2017-01-22 17:40:45 UTC
Created attachment 179220 [details]
nvidia-bug-report.sh log
Comment 17 Matthew Fioravante 2017-01-22 17:49:52 UTC
I'm getting this issue as well, but perhaps I can shine some light on the cause.

I've got a GeForce GT 710B. I'm on 11.0-RELEASE-p2 using nvidia-driver version 367.44_3.

I had my system running in BIOS legacy mode before, and everything worked fine. I was using the nvidia-modeset.ko module and I was able to switch between console and X, stop X, restart X, etc..

I rebuild the system to boot using uefi and I've switched the BIOS to run in EFI mode for everything. I did this in order to try to solve a different problem.

Now I have this same issue as the bug reporter. As soon as I start X, I am no longer able to switch to the text consoles. Nor am I able to switch back to X. The screen turns black.

This is likely some issue with efi framebuffer the nvidia driver. Maybe incompatibilities in the framebuffer. Maybe its some issue with enumerating /selecting pci devices, as that information would certainly be different coming from BIOS vs EFI.

I've attached my nvidia-bug-report.sh output.
Comment 18 Alex P 2017-02-13 12:28:44 UTC
I can reproduce this on 11.0-RELEASE-p2 with GeForce GT-710 (nvidia 375.26 driver) and an older GeForce-210 (nvidia 340 driver).

All attached monitors go into power save mode when switching away from X to a vt, or exiting an X session. This happens with vt as well as sc in text and pixel modes. The console still accepts input as I can run commands blindly and switch back to, or restart X.

Everything works properly on the same system with an old Quadro FX 1500 that uses the 304 driver.
Comment 19 Andreas Bock 2017-04-01 17:42:03 UTC
Hello everyone,

I had a similar problem but with a garbled instead of a blank screen while using vt.

It was solved for my system (GeForce GT 440 with FreeBSD 10.3-RELEASE and nvidia-driver-375.26_1) with the following line added to /boot/loader.conf


This will cause vt to use the text mode instead of the graphics mode.
Source: https://wiki.freebsd.org/Newcons
Comment 20 Thomas Müller 2018-11-18 01:27:27 UTC
Will this bug ever be resolved? It is now over three years old and there seems to be little to no progress. :/

I am experiencing the same issue on my ThinkPad P71 (with only discrete graphics enabled) and it practically makes FreeBSD unusable for me. Switching to sc(4) is not an option as I need EFI to be able to boot from my NVMe module. Tried 11.2 and 12.0-BETA3 to no avail. If I could I would offer my support on this but as the problem seems to come from the NVIDIA driver blob I do not think that there is much I can do...
Comment 21 Alex P 2019-01-23 10:41:32 UTC
Seems to be fixed in 12.0-RELEASE. Tested with Quadro 4000/GF100GL and nvidia-driver-390.87. Exiting X or switching to a vt no longer puts all attached monitors into stand-by, alas I cannot verify it on EFI.
Comment 22 Oleg Sidorkin 2019-01-29 08:20:52 UTC
(In reply to Alex P from comment #21)

Works for me with UEFI on recent stable/12. I can see console messages during boot, start Xorg (sddm actually) and then switch between consoles and Xorg.
Comment 23 Trev 2019-02-20 13:23:41 UTC
Unfortunately not fixed for me with:
FreeBSD citadel.sentry.org 12.0-RELEASE FreeBSD 12.0-RELEASE #3 r344269M

* Mac mini 3,1
* VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400] (rev b1)
* amd64 EFI installation.

I have an identical machine installed with FreeBSD ages ago and upgraded from source which works fine - the only difference is that it is not installed in EFI mode which didn't exist/work when it was originally installed so it's running in Apple legacy BIOS mode.
Comment 24 Trev 2019-02-20 13:25:26 UTC
nvidia driver version nvidia-driver-340-340.107_3