Comment 1 Ed Maste 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?

(In reply to Ed Maste from comment #1)
Thank you, and I apologize for the late reply, Ed.


Correct.

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 2015-09-08 14:31:06 UTC

Does it happen only with vt(4), or also when running with sc(4) driver instead?

(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 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

(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
11.0-CURRENT
11.0-CURRENT
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

(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.

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 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?

(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.

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:

    http://www.nvidia.com/Download/driverResults.aspx/90397/en-us

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?

Thanks.

(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
11.0-CURRENT
11.0-CURRENT
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.

Created attachment 161578 [details]
sudo nvidia-debugdump -D

(In reply to Andy Ritger from comment #11)

Created attachment 161579 [details]
sudo nvidia-bug-report.sh

(In reply to Andy Ritger from comment #11)

$ sudo nvidia-bug-report.sh
Password:

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
freebsd-gfx-bugs@nvidia.com.

I'm having the very same issue on an HP Z600 workstation.

My dmesg is:
https://bpaste.net/show/9ac322d9c4e5

My nvidia-bug-report is here:
https://outlookuga-my.sharepoint.com/personal/abunai_uga_edu/_layouts/15/guestaccess.aspx?guestaccesstoken=8vRxRkuBIdv7NzHxURCgtBhxEtvDs6e062uX7qLhSm8%3d&docid=0e91536928b1045819d31f8776e2d0479

Created attachment 179220 [details]
nvidia-bug-report.sh log

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.

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.

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

hw.vga.textmode=1

This will cause vt to use the text mode instead of the graphics mode.
Source: https://wiki.freebsd.org/Newcons

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...

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.

(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.

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.

nvidia driver version nvidia-driver-340-340.107_3

Comment 25 Thierry Thomas 2023-03-23 21:32:09 UTC

Setting "Version:" to CURRENT, because I'm still facing this bug with FreeBSD-14-CURRENT #0 main-n261544-cee09bda03c8: Thu Mar 16 08:11:20 UTC 2023.

Actually, I got the problem reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201461#c19 : a garbled instead of a blank screen when switching to console (vt), and as reported by Andreas Bock, setting "hw.vga.textmode=1" in /boot/loader.conf fixed it.

Notes:

- the card is GP104BM [GeForce GTX 1080 Mobile]

- using nvidia-driver-515.86.01_1

- no external screen but the one of the laptop

- amd64 legacy installation

- `nvidia-debugdump -D' reports:
ERROR: GetCaptureBufferSize failed, Unknown Error, bufSize: 0x0
ERROR: internal_getDumpBuffer failed, return code: 0x3e7
ERROR: internal_dumpSystemComponent() failed, return code: 0x3e7
ERROR: internal_dumpNvLogComponent() failed, return code: 0x3e7
ERROR: GetCaptureBuffer failed, Unknown Error, bufSize: 0x22
ERROR: internal_getDumpBuffer failed, return code: 0x3e7
ERROR: internal_dumpGpuComponent() failed, return code: 0x3e7
ERROR: GetCaptureBuffer failed, Unknown Error, bufSize: 0x46cdf
ERROR: internal_getDumpBuffer failed, return code: 0x3e7
ERROR: internal_dumpGpuComponent() failed, return code: 0x3e7
ERROR: internal_dumpNvLogComponent() failed, return code: 0x3e7