|Summary:||switching back to sc(4) or vt(4) console fails with nvidia.ko|
|Product:||Base System||Reporter:||Tony Narlock <tony>|
|Component:||kern||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Many People||CC:||0mp, abunai, alx, andreas.bock, aritger, crest, emaste, fbsdbugs4, fmatthew5876, mutin.sa, osidorkin, rigoletto, thomas, trasz|
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 10.1-RELEASE-p14 10.1-RELEASE-p14 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 NVIDIA-FreeBSD-x86_64-346.82 $ 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 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. 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?
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 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 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 firstname.lastname@example.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 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: 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.
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 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.
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 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 email@example.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 firstname.lastname@example.org.
Comment 15 Bret Miller 2016-02-05 18:40:46 UTC
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
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 hw.vga.textmode=1 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