Comment 1 Alexey Dokuchaev 2015-07-17 10:09:02 UTC

Thanks for the patch; unfortunately it cannot be committed unmodified, as it would break legacy driver ports.  I'll fill in those missing pieces and update the port shortly.

Created attachment 162627 [details]
nvidia-driver.diff

This is an update to the nvidia-driver that will not break the slaves. To help with future upgrades, many obsolete conditionals have been removed, as well as several extra files.

Started by gutting everything from the original patch. Verified every line I removed, then upgraded to 352.55 (long lived branch) just in case it turns into a legacy release. After verifying poudriere build satisfaction continued to 355.11 (most current short lived branch) and verified once again. After testing default build options, unset all options, then set all options, I proceed to testing on my machine (10-STABLE r289428) and so far seems to run fine. Will provide xorg.log/poudriere.logs if requested.

* Update to 355.11
* Removed comment about unsupported 173 legacy driver
* Removed obsolete if statement for MASTER_SITES legacy drivers
* Removed legacy patch extra-patch-mk-nvidia.lib.mk
* Changed if statement to apply to anything before 355.11
* Added else statement 355.11 and later for new patch files
* New variable NVSRC for new hierarchy
* Removed obsolete security patches
* Added WBINVD to options define
* Moved WBINVD_DESC
* Removed obsolete if statement for WBINVD
* Removed if statement for obsolete LIB_DEPENDS
* Removed obsolete updated d_mmap() since FreeBSD src SVN r201223
* Removed obsolete vm page queuing/locking for r207410, r207617, r207644, and r163622
* Removed obsolete if statement for r225617
* Added NVSRC variables to various commands
* Removed obsolete vm_map_find if statement for r255426
* Added NVSRC variable to more commands
* Removed obsolete patch for stack buffer overflow
* Removed obsolete legacy if statement
* Added NVSRC to several more various commands
* Removed obsolete if statement, kept command
* Removed obsolete if statement for xconfig/settings
* Added NVSRC to command
* Removed obsolete command to remove obsolete file libnvidia-cfg from tmpplist
* Removed obsolete command to remove obsolete file wfb from tmpplist
* Removed obsolete command to remove obsolete file vdpau from tmpplist
* Changed if else statement to if statement for libvdpau
* Removed obsolete command to remove obsolete file libcuda from tmpplist
* Removed obsolete command to change files libGLcore from tmpplist
* Added if statement for removal of new files from 352.55
* Added if statement for removal of new files from 355.11
* Added if statement for removal of files after 355.11
* Added 355.11 to distinfo
* Removed 346.96 from distinfo
* Removed unsupported legacy from distinfo 173.14
* Deleted extra-patch-mk-nvidia.lib.mk
* Added new patch file extra-patch-src_nvidia_Makefile
* Added new patch file extra-patch-src_nvidia_nv-freebsd.h
* Added new patch file extra-patch-src_nvidia_nv-misc.h
* Deleted old patch file extra-patch-x11-driver-Makefile
* Deleted old legacy patch file legacy-patch-mk-nvidia.lib.mk
* Deleted old legacy patch file legacy-patch-x11-driver-Makefile
* Added new patch file patch-mk_nvidia.lib.mk
* Added new patch file patch-x11_driver_Makefile
* Deleted obsolete security patch security-patch-CVE-2012-0946
* Deleted obsolete security patch security-patch-CVE-2012-4225
* Added bin/nvidia-debugdump, bin/nvidia-smi to plist
* removed lib/libGLcore.so, lib/libGLcore.so.1 from plist
* Added lib/libnvidia-glcore.so, lib/libnvidia-glcore.so.1 to plist
* Added lib/libnvidia-ml.so, lib/libnvidia-ml.so.1, man/man1/nvidia-smi.1.gz to plist
* Removed libnvidia-wfb.so.1 from plist
* Added libEGL_nvidia.so, libEGL_nvidia.so.0 to plist
* Removed libGLcore.so.%%SHLIB_VERSION%%, libGLcore.so.1 from plist
* Added libGLdispatch.so, libGLdispatch.so.0, libOpenGL.so, libOpenGL.so.0, libnvidia-glcore.so.%%SHLIB_VERSION%% to plist
* Removed libnvidia-tls.so.1 from plist
* Added directories for /compat/usr/lib/vdpau

*** Bug 203320 has been marked as a duplicate of this bug. ***

 Few other thing for the maintainer to possibly look at is removal of option PAE and WBINVD. I believe these are obsolete options that that have no effect on the portd. Could be mistaken however so left them alone.

 The ${REINPLACE_CMD} -e '24,26d' ${WRKSRC}/src/${NVSRC}/nv-freebsd.h on line 137/107 is also mostlikely obsolete, however I cant test on -CURRENT so left it.

 Last, is the ${REINPLACE_CMD} -e 's/d_thread_t/struct thread/' to support FreeBSD 4? just left it because its better to be safe but I'm pretty sure that could also safely be removed.

Created attachment 162675 [details]
nvidia-driver.diff

Created attachment 163450 [details]
Chenges type d_thread_t to 'struct thread' as recommended

The refresh of the port does not work with CURRENT (FreeBSD 11.0-CURRENT #16 r291164: Sun Nov 22 22:19:16 CET 2015 amd64) and the most recent nVidia driver 358.16 and bails out on several files, for instance nvidia-modeset-freebsd.c, see below.

The errornous type has been removed, I found this comment on that here

https://lists.freebsd.org/pipermail/freebsd-arch/2009-May/009276.html

and here

http://dpdk.org/dev/patchwork/patch/2331/

It seems that supoort for d_thread_t has been deprecated in CURRENT (aka 11.0).


[...]
--- nvidia-modeset-freebsd.o ---
cc -O2 -pipe -O3 -march=native -fno-strict-aliasing -O3 -march=native  -DNV_VERSION_STRING=\"358.16\" -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -Imachine -I/usr/src/sys/sys -I../common/inc -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body  -Wno-error-parentheses-equality -Wno-error-unused-function  -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999 -c nvidia-modeset-freebsd.c -o nvidia-modeset-freebsd.o
nvidia-modeset-freebsd.c:681:5: error: unknown type name 'd_thread_t'
    d_thread_t *td
    ^
nvidia-modeset-freebsd.c:723:5: error: unknown type name 'd_thread_t'
    d_thread_t *td
    ^
nvidia-modeset-freebsd.c:771:5: error: unknown type name 'd_thread_t'
    d_thread_t *td
    ^
3 errors generated.
*** [nvidia-modeset-freebsd.o] Error code 1

make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-358.16/src/nvidia-modeset

Checked this out on 358.16. The driver doesn't work with a nVidia GTX560Ti. The box boots, then the screen went dark, only a cursor and the mouse pointer showed up. Consoles are all active and accessible as expected (using vt on CURRENT).

Today, I checked on nVidia's newest BETA driver, 361.16.

It has the same issues as the 358.16 is reported to. With the herein provided patchset and the patch regarding to comment 6, the driver 361.16 is blank - /var/log/Xorg.log doesn't report any port for display connections as this is reported by the last known working driver 355.11.

Does anyone has an idea?

Created attachment 165236 [details]
nvidia-driver-test,not-ready.diff

Can you please test this patch ohartman, I omitted the patch and instead added it in the Makefile. I ran out of time and its not quite ready for commit due to older version of gcc on 93. This will be fixed. It should build on head.

The latest patch doesn't work with 355.11, it fails with the error:

[...]
===>  Applying FreeBSD patches for nvidia-driver-355.11                         
sed: /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-355.11/src/nvidia/nvidia-modeset/nvidia-modeset-freebsd.c: No such file or directory               

*** Error code 1                                                                               Stop.                                                                           

make[1]: stopped in /usr/ports/x11/nvidia-driver                                
                                                                               *** Error code 1

I haven't looked into it, but I think it is a missing dependency on the version we deal with.

More important: As with my added patch the patchset works with 361.16 and the sources compile - but the driver doen't work. The screen remains black, no graphical output occurs and Xorg.log show no usable ports to use for any display.

(In reply to ohartman from comment #10)

There is a new kernel module named nvidia-modeset, nvidia moved much of there rendering code into it. If it is not loaded you will experience this behavior. Can you please retest with this new module loaded? Just tested on 10-STABLE r292114 amd64, and it works perfectly.

Correct, after loading the new module I get a graphical screen back again.

The only thing that isn't working is when someone wants to go back to 355.11 by the framework provided. 

Kind regards,
oh

Created attachment 165419 [details]
nvidia-driver-361.16.diff

Update to the previous patch to the most current version of nvidia-driver.

Poudriere bulk -C -t -j (102amd64 102i386 93amd64 93i386) x11/nvidia-driver x11/nvidia-driver-340 x11/nvidia-driver-304

All build successfully with defaults.

Patch tested on amd64 10-STABLE-r292114

Driver 361.16 corrupts console. On  FreeBSD 11.0-CURRENT #39 r294022: Thu Jan 14 18:08:40 CET 2016 amd64, non-UEFI, vt() console, switching to console via Ctrl-Alt-FX, X= 1...9, results in unusable, blocky coloured 640x480-stylisch corrupted output.

CPU:

Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #38 r293849: Wed Jan 13 21:19:10 CET 2016
    root@thor.walstatt.dynvpn.de:/usr/obj/usr/src/sys/THOR amd64
FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3300.10-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x3d9ae3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,XSAVE,OSXSAVE,AVX,F16C>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8231161856 (7849 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
random: unblocking device.
Security policy loaded: TrustedBSD MAC/BSD Extended (mac_bsdextended)
Security policy loaded: TrustedBSD MAC/portacl (mac_portacl)
WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.
ioapic0 <Version 2.0> irqs 0-23 on motherboard
random: entropy device external interface
kbd0 at kbdmux0
netmap: loaded module
vtvga0: <VT VGA driver> on motherboard
[...]


and the graphics board (nVidia GTX560Ti:

[...]
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xe000-0xe07f mem 0xf4000000-0xf5ffffff,0xe0000000-0xe7ffffff,0xe8000000-0xebffffff irq 16 at device 0.0 on pci1
vgapci0: Boot video device
hdac0: <NVIDIA GF110 HDA Controller> mem 0xf6080000-0xf6083fff irq 17 at device 0.1 on pci1
xhci0: <Intel Panther Point USB 3.0 controller> mem 0xf6200000-0xf620ffff irq 16 at device 20.0 on pci0
[...]


kldstat reports:

Id Refs Address            Size     Name
 1   23 0xffffffff80200000 12c2bd8  kernel
 2    3 0xffffffff814c4000 6f648    vboxdrv.ko
 3    1 0xffffffff81621000 1564     fdescfs.ko
 4    2 0xffffffff81623000 8cc8aa   nvidia.ko
 5    1 0xffffffff81ef0000 9e317    nvidia-modeset.ko
 6    1 0xffffffff81f8f000 31739    linux.ko
 7    1 0xffffffff81fc1000 2d11     linux_common.ko
 8    2 0xffffffff81fc4000 2d2e     vboxnetflt.ko
 9    1 0xffffffff81fc7000 3fdc     vboxnetadp.ko

On FreeBSD 11.0-CURRENT #1 r294070: Fri Jan 15 06:21:20 CET 2016 amd64, loading this kernel module of revision 361.16 results in:

kldload: an error occurred while loading the module. Please check dmesg(8) for more details.

dmesg:
[...]
KLD nvidia-modeset.ko: depends on kernel - not available or version mismatch
linker_load_file: Unsupported file type

No Linuxulator enabled/loaded nor configured in x11/nvidia-driver

My last comment was due to FreeBSD CURRENT problems. Building kernel via "make kernel" without flag -DNO_CLEAN solves the problem, work for a solution in HEAD is underway.

@Ultima:
I have a further proposal based upon the cleaned up Makefile/files.

In distinfo, the hash for 355.11 isn't present although initially mentioned in this thread. 

The first new split driver modules came with 358.16 (first official release of that kind, all successors are BETA, up to most recent 361.18 as of today) and the port should reference this version instead of 361.16.

So distinfo needs to adjusted also for 355.11 and 358.16 and 361.16 should be go into a potentiall x11/nvidia-driver-devel port.

On CURRENT, I face a nasty bug of the new drivers (haven't tested with 355.11 yet): Switching to console isn't possible anymore, the console is a funny, blocky coloured entity reminding me of the 1980s video game consoles ...

Kind regards,

Oliver

The port also includes, although explicitely disabled(!), the Linuxulator in its 32bit incarnation - on CURRENT amd64 I would at least expect linux64.ko and in the case, it is disabled, I wouldn't expect any Linux module loaded at all.

I tried to figure out where the problem lies, but unable to comply.

Created attachment 165694 [details]
nvidia-driver-361.18.diff

 Updated, also small fixed to some versioning in the makefile as well as the pkg-message for the nvidia-modest kernel. Not sure about this -devel slave port. Using 10-STABLE, I still have no issues with 361.*.

Will look into the linuxulator issue.

According to nvidia's homepage and driver download suggestions, both driver packages 361.16 and 361.18 are marked "BETA", while 358.11 seems to be an official release - as well as 355.11. So my suggestion was: make your Makefile/port based on 358.16 if is is about to be a official port. If we would like to have a devel port, 361.18 could go there. But this is only a suggestion. I'm fine with the "latest" BETA as far as it works.

As I wrote before, I have on several types of nVidia boards around here problems running CURRENT. I'm glad to hear that 10-STABLE is working, but ports are also supposed to be working on CURRENT. aren't they?

The problem I face needs more investigation. I can see the non-working console on systems booting the old way, I will check on a box booting via UEFI on Monday or Tuesday with 361.18 and report back.

Kind regards,

Oliver

(In reply to ohartman from comment #19)
 Do you think this issue your experiencing is with the port, or CURRENT? I thought it was working fine prior to r294070, that lead me to believe it was a CURRENT issue.

 Yeah, your right about the beta release. I would agree to the -devel port if this port were a little more active. Going to hold off on updating till official releases from now on.

 Planning on testing with CURRENT soon so I have a better picture on these issues.

Created attachment 167220 [details]
nvidia-driver-355.11.diff

 Reverting back to 355.11 patch. This patch will build every release to 361.28. However there are are issues that still need resolved with the newer versions. 355.11 is working perfectly, so this is the ideal version to rebase the port to at this time.

 The linux emulator x86_64 support for archs running x86_64 at first glance, looks like a couple changes to headers will suffice. It builds fine, however I did not test it yet. Also, I'v decided to leave this part of the patch out for sanity. Going to keep the focus on this bug report for patchfile cleanup and version upgrade.

portlint -AC:
WARN: Makefile: FREEBSD_AGP appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE. (slave port option)
WARN: Makefile: PAE appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE. (slave port option)
WARN: Makefile: possible use of absolute pathname "/usr/bin/join". (false positive)
WARN: Makefile: unless this is a master port, PORTVERSION has to be set by "=", not by "?=". (required for slave ports)
WARN: Makefile: new ports should not set PORTREVISION. (required for slave ports)
WARN: Makefile: using hyphen in PORTNAME. consider using PKGNAMEPREFIX and/or PKGNAMESUFFIX.
WARN: Makefile: "MASTER_SITE_SUBDIR" has to appear earlier.
0 fatal errors and 7 warnings found.



poudriere bulk -C -t x11/nvidia-driver x11/nvidia-driver-340 x11/nvidia-driver-304:
head-r295736-amd64-ok 102amd64-ok 102i386-ok 93amd64-ok 93i386-ok

I'v tested this patch on 10-STABLE and head-r295736, everything appears to be working as it should.

Thanks for the refurbishing of the port's Makefile so far.

On all recent CURRENT (as of speaking, it is with me FreeBSD 11.0-CURRENT #6 r295834: Sat Feb 20 08:55:14 CET 2016 amd64), all drivers > 355.11 end up with an unusable console - it is either black, covered with funny old-day's blocky coloured blocks (like a cursor in VGA 640x480 days) or coloured stripes like a misfit in synchronisation of a old-day cathod ray tube monitor, if the resolution on the console exceeds 640x480 (in all cases using vt(), old style cons disabled). These console distortions go away when the nvidia kernel module gets unloaded, so I reckon this is due to nvidia.ko (tested with an methusalem nVidia GTX 560Ti).

On a Fujitsu Celsius M740 with a Haswell 6-core XEON w/o iGPU, equipted with a nVidia Quadro NF315 simple, low-end graphics board of a more modern style, even driver 355.11 doesn't work properly on CURRENT (revision as described above). The console is black and unsusable - I can type blindly and trigger actions as I can with the fancy art-couloured console styles described prior, but I can not see. The workstation in question has also only vt() enabled in kernel.

On recent CURRENT (revision 295998) compilation of the driver 355.11 dies (patch as in diff apllied):

[...]
cc -O2 -pipe -O3 -march=native -fno-strict-aliasing -O3 -DNV_VERSION_STRING=\"355.11\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -march=native  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I../common/inc -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body  -Wno-error-parentheses-equality -Wno-error-unused-function  -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999 -c nvidia_i2c.c -o nvidia_i2c.o
--- nvidia_ctl.o ---
In file included from nvidia_ctl.c:11:
./nv-misc.h:14:10: fatal error: 'opt_global.h' file not found
#include "opt_global.h"
         ^
--- nvidia_dev.o ---
In file included from nvidia_dev.c:11:
./nv-misc.h:14:10: fatal error: 'opt_global.h' file not found
#include "opt_global.h"
         ^
--- nvidia_acpi.o ---
In file included from nvidia_acpi.c:11:
--- nvidia_i2c.o ---
In file included from nvidia_i2c.c:1:
./nv-misc.h:14:10: fatal error: 'opt_global.h' file not found
#include "opt_global.h"
         ^
--- nvidia_acpi.o ---
./nv-misc.h:14:10: fatal error: 'opt_global.h' file not found
#include "opt_global.h"
         ^
--- nvidia_i2c.o ---
1 error generated.
*** [nvidia_i2c.o] Error code 1

make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-355.11/src/nvidia
--- nvidia_dev.o ---
1 error generated.
*** [nvidia_dev.o] Error code 1

make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-355.11/src/nvidia
--- nvidia_ctl.o ---
1 error generated.
*** [nvidia_ctl.o] Error code 1

make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-355.11/src/nvidia
--- nvidia_acpi.o ---
1 error generated.
*** [nvidia_acpi.o] Error code 1

I don't know if feedback is needed, but I have anyway tested 355.11 using the Feb 20 patch, and 361.18 using the previous patch on 10.3-BETA3.  I have a GeForce GTX 550Ti in a desktop with a Z77 MB and an Ivy bridge processor.

355.11 seems to work with both syscons and vt consoles.  No issues so far.

361.18 seems to work with syscons only - vt gives corrupt console similar to other reports.  I had more issues before I realised that nvidia-modeset.ko also had to be loaded.

Great work, thanks!  I will continue using 355.11 for now, unless more testing of the newer version is desired.

Created attachment 167734 [details]
freebsd nvidia 361.28 version ports

I change x11/nvidia-driver x11/nvidia-settings x11/nvidia-xconfig for 361.28 nvidia driver, work well on my FreeBSD 11/GTX980.

Can not confirm. The patches applied do not work with x11/nvidia-driver and 361.28. On my system (most recent CURRENT and ports) I receive a patch error.

Due to EFI/UEFI and GOP issues I can not confirm that 361.28 works with CURRENT, vt() and MSI GTX860 GPU as well as not with nVidia NVS315. The first has blocky console (CSM/legacy boot), funny distorted stripes when booted via UEFI. The same for the NVS315. NVS315 doesn't show up a console with 355.11 (also CURRENT, but Fujitsu Celsius M740).

I'd just like to chip in that Ultima's patch to update the port to 355.11 but modified to use the latest "short lived branch" version of 358.16, worked for me on FreeBSD 10.2/amd64 using a GeForce GT 730.

I did attempt to try using 361.28 from the "long lived branch" and while it built fine for me and everything seemed fine at first, once I attempted to start X.org, I got a kernel panic.

On a side note, the update-distinfo target of the port doesn't appear to work for me. Instead of adding the new distfiles to the start and keeping the old entries, it erased the new distfiles and gave me a distinfo that was identical to what it as before running update-distinfo.

(In reply to Naram Qashat from comment #28)
The issue is with vt, syscon is working perfectly with 361.28. I have been using it for some time now on 10-stable.

Created attachment 168435 [details]
nvidia-driver-361.28.diff

 About to create a bug report for nvidia+vt, decided to upgrade head first. The 361.28 version of nvidia now works on vt. Repost the patch for 361.28. Ohartman, can you please test again and make sure it checks out? I'm currently on r297060.

Can't confirm that! Tried today 361.28 on CURRENT (FreeBSD 11.0-CURRENT #27 r297066: Sun Mar 20 16:39:50 CET 2016 amd64). The system is running vt(), no remnants of syscons in the kernel (hopefully). Not UEFI, since the ASROCk crap doesn't work with UEFI and FreeBSD.

The console is still unusable as described before.

(In reply to ohartman from comment #31)
 It looks like it is working with efi and not with legacy then, I forgot that I changed to efi not to long ago. Yet another mystery before us.


 I was trying to get efi to work on my asrock board, wtf is up with there detection? I simply can't figure it out. I spent several hours a couple days ago working on that. Asrock just doesn't detect efi when needed. It is quite frustrating.

I tried and gave up. I use two boards from ASRock, both the same, one Z77 Pro4, another Z77 Pro4-M. The Firmware is as of the latest state as it can be found at ASRocks website.

I stumbled across the problem twofold. I got a Samsung SSD 850 Pro and I'd like to boot UEFI. To make the story short: My nVidia GTX 560Ti doesn't support VBIOS GOP (a requirement in the ASROCK UEFI!), so I swapped the GPU with a new GTX 960, which supports VBIOS GOP. Then I tried booting FreeBSD UEFI and I'm double sure I did everything right (last time I tried is today and I put a brandnew boot1.efifat onto to partiton 1 which is the EFI boot partition). It didn't work! The Asrock jumps immediately into firmware when CSM is disabled (see ACPI setup/options). 

To test whether FreeBSD is UEFI-broken or my brandnew SSD was crap I tried Windows 7 Pro 64bit. Even Windows 7 isn't capable of booting UEFI! It boots fine classic (MBR), but not UEFI. I'm back with MBR/gptboot on FreeBSD, with a new MSI GTX 960 with 4 GB video RAM which is slower(!) (jumpy, produces stripes and flicker in the upper fith part of the screen at 2560x1440 when watching video) and still now UEFI and with nVidia 381.28, the console (vt()) is still crap.

I blame the Asrock for the problems. I tried almost every combination of options to make it work with UEFI, except with the secure key option - I do not have one. I tried to switch that off by default, but that doesn't work as we know. 

I'm sorry, but at the moment I have only this option and I'm not happy with it. The exchange for a modern GOP capable GTX 960 made things worse with the recent FreeBSD CURRENT (it seems that FreeBSD is lately very slow and jumpy, sometimes like glue ...). I will test on my workstation at work tomorrow, but there I had the problem, that the nVidia Quadro NVS 315 (or 310, I forgot ...) is not willing to work with nVidia 361.28 (coloured stripes like syncfaults in the era of the CRT in the upper HD screen at 1920x1200), the "old" 355.11 works, but I can not switch to a console, becaus eof the console is black. This is also on CURRENT, UEFI booting (Fujitsu Celsius M-740, but this box has severe other issues, not recognizing AES-NI and TXT on a XEON Haswell E5-126X).

Graphics (an important part for us) is almost a mess on FreeBSD these days! Only working with opensource on ancient hardware, more modern only working with at most IvyBridge (iGPU from Intel), no AMD support and nVidia support seems to be wrecked with most modern drivers and UEFI and vt() (at least on CURRENT).

361.28 still causes a kernel panic for me, I'm not exactly sure when in the boot sequence but it is after it is starting to run all the boot scripts. I am using a GENERIC 10.2 kernel, which I believe is still using syscons and not vt, so I do not think anything related to vt is why I am getting a kernel panic.

358.16 works fine for me, although I did run into a kernel panic when X.org started with only one of the 2 defined monitors physically attached.

It is a shame that the long term branch is the one having the issues, though. I'd rather not be on the short term branch.

As I announced, I checked on a working UEFI booting most recent CURRENT (FreeBSD 11.0-CURRENT #14 r297134: Mon Mar 21 06:48:51 CET 2016 amd64), using a nVidia 
NVS 315 GPU as delivered with a Fujitsu Celsius M-740:

[...]
vgapci0: <VGA-compatible display> port 0xe000-0xe07f mem 0xfa000000-0xfaffffff,0xf0000000-0xf7ffffff,0xf8000000-0xf9ffffff at device 0.0 on pci5
hdac0: <NVIDIA GF119 HDA Controller> mem 0xfb080000-0xfb083fff at device 0.1 on pci5
pci1: <unknown> at device 17.0 (no driver attached)
[...]

and the information out of /var/log/Xorg.log:

[...]
[    11.381] (II) NVIDIA(0): NVIDIA GPU NVS 315 (GF119) at PCI:4:0:0 (GPU-0)
[    11.381] (--) NVIDIA(0): Memory: 1048576 kBytes
[    11.381] (--) NVIDIA(0): VideoBIOS: 75.19.88.00.05
[    11.381] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[    11.381] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[    11.381] (**) NVIDIA(0):     device HP E241e (DFP-1) (Using EDID frequencies has been
[    11.381] (**) NVIDIA(0):     enabled on all display devices.)
[    11.382] (II) NVIDIA(0): Validated MetaModes:
[    11.382] (II) NVIDIA(0):     "DFP-1:1920x1200"
[    11.382] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1200
[    11.386] (--) NVIDIA(0): DPI set to (93, 95); computed from "UseEdidDpi" X config
[    11.386] (--) NVIDIA(0):     option
[...]


As I said: 361.28 isn't working properly on my alternate, IvyBridge based system using either a MSI GTX 560Ti or MSI GTX 960 (no UEFI due to no VBIOS GOP support by the GPU card, coloured-blocky 1980s console, unreadable, screen is 2560x1440, 24bits).

While on non-UEFI only the vt() console seems to be wrecked, on UEFI booting FreeBSD with the NVS 315 nVidia GPU and 361.28, the graphics is completely wrecked on 1920x1200, 24 bits (higher resolution not possible due to limited screen at work). 

On that UEFI booting box, the console goes normal when hitting the ACPI power shutdown button, so I guess when the nvidia module gets unloaded, deactivated or whatever, everything is normal (keyboard is responding again, console is readable et cetera). On that very same machine, with UEFI an NVS315 GPU, driver 355.11 does give me graphics, but the console is blank. Shutting down the system with the power button gives back readable console as well.

Sorry being unable to provide more detailed and technical stuff, my time digging is limited and I'm happy having at least a working FreeBSD CURRENT graphical system.

Comment 36 Koop Mast 2016-04-04 12:04:56 UTC

I don't have any nvidia hardware myself, but with my x11@ hat on:

Could the patch be updated to minimum 358.16? This version adds xserver 1.18 support. Which we (the x11@ team) would like to import. (the legacy ports will have there own PR).

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

Regarding newer versions it seems 361.42 lost it's "beta" tag.

Created attachment 169005 [details]
nvidia-driver-361.42.diff

* Updated to 361.42

I have tested several versions of the driver that comes with the nvidia-modeset.ko module, including 358.16, 361.28 and 361.42. Perhaps 1 time out of 4 these lock up the entire system directly when the X server starts. If it does not lock up, it seems to work without problems.

My system has a GeForce GTX 550Ti in a desktop with a Z77 MB, currently running 10.3-PRERELEASE r296673 with syscons (vt gets corrupted when nvidia-modset is present).

I compiled a kernel with WITNESS, and got this (driver 358.16) just before locking up:

Apr  7 23:25:20 ivy kernel: acquiring duplicate lock of same type: "os.lock_sx"
Apr  7 23:25:20 ivy kernel: 1st os.lock_sx @ nvidia_os.c:593
Apr  7 23:25:20 ivy kernel: 2nd os.lock_sx @ nvidia_os.c:593
Apr  7 23:25:20 ivy kernel: KDB: stack backtrace:
Apr  7 23:25:20 ivy kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0665413410
Apr  7 23:25:20 ivy kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe06654134c0
Apr  7 23:25:20 ivy kernel: witness_checkorder() at witness_checkorder+0xe24/frame 0xfffffe0665413550
Apr  7 23:25:20 ivy kernel: _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0665413590
Apr  7 23:25:20 ivy kernel: os_acquire_mutex() at os_acquire_mutex+0x32/frame 0xfffffe06654135b0
Apr  7 23:25:20 ivy kernel: _nv012976rm() at _nv012976rm+0x18/frame 0xfffffe000a177e60
Apr  7 23:25:20 ivy kernel: dmapbase() at 0xfffff800253dec80

I finally got around to trying 361.42 and it works fine for me. No kernel panics and my X display starts up as expected.

(In reply to Naram Qashat from comment #40)

So it does work? With sc (syscons) or vt console driver?

I'm using the default 10.3 GENERIC kernel, which I assume is syscons.

A bit more information on the issue I reported in comment 39:

* With WITNESS and syscons (10.3-REL/amd64), all driver versions using the nvidia-modeset.ko module (358.16 and above - but have not tested the just released 364.19) locks up just after emitting the "acquiring duplicate lock" message.

* I have reported this to Nvidia, and it seems like it now have gone through the support-levels to an actual developer.

Has anyone else seen this issue?  It would be great if someone else could try a kernel with WITNESS enabled to see what happens!

Created attachment 169837 [details]
nvidia-driver-364.19.diff

* Updated to 364.19

The problem with vt() is still present

(In reply to Bengt Ahlgren from comment #43)

Has there been any reply from nVidia yet?

I am guessing that they based their nvidia-modeset.ko on an older version of VT and kms/drm modesetting code. Now their module does not work because the kernel behaves differently what their code assumes. I am skeptical anyone except nVidia can fix the problem with VT.

(In reply to Arto Pekkanen from comment #46)

No reply from them yet, I'm afraid!

Please note that I didn't report the VT corruption issue, only the locking issue I encountered. I would be very interested to know if someone else can reproduce it (using a WITNESS enabled kernel). The locking problem occurs with both syscons and VT.

 The corrupted console seems to only appear with legacy boot. Corrupted console appeared in 358.16 with nvidia-modeset.ko. Have had no issues on 10-STABLE, however have not tested that branch in some time (at least 3 months). Currently on r299849. Here is a small list of issues that I have found on my hardware. This only applies to head.

syscons:
* Corrupted console upon loading nvidia-modeset.ko. The console is still usable, however visually unusable. This always occurs and can be restored by unloading the kernel module and switching consoles.

vt:
* Nvidia kernel modules fail to load during stage 3.

Both:
* Panic upon starting xorg. This occurs frequently, however on a successful launch appears run fine.
* Occasional panic while xorg is running, this is extremely rare and I can't find a trigger. Possibly flaky hardware, however unable to confirm.


(In reply to Arto Pekkanen from comment #46)
 You maybe right. The src leads me to believe that Nvidia only test their releases on a stable release. Fixes may not occur until 11 has been released.

Some more testing.  With the 367.18 version, vt console and WITNESS, I got the following panic right after a very similar "acquiring duplicate lock" message as I reported earlier.  The panic is not unique to this version - I also got it on a few other versions with nvidia-modeset.

panic: lock "nvkms-events-lock" 0xfffff80012f2d108 already initialized
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe06653cc340
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe06653cc3f0
vpanic() at vpanic+0x126/frame 0xfffffe06653cc430
kassert_panic() at kassert_panic+0x139/frame 0xfffffe06653cc4a0
lock_init() at lock_init+0x44/frame 0xfffffe06653cc4e0
_mtx_init() at _mtx_init+0x7c/frame 0xfffffe06653cc520
nvkms_open() at nvkms_open+0xcd/frame 0xfffffe06653cc540
devfs_open() at devfs_open+0x129/frame 0xfffffe06653cc5c0
VOP_OPEN_APV() at VOP_OPEN_APV+0xf1/frame 0xfffffe06653cc5f0
vn_open_vnode() at vn_open_vnode+0x23f/frame 0xfffffe06653cc6c0
vn_open_cred() at vn_open_cred+0x3c2/frame 0xfffffe06653cc820
kern_openat() at kern_openat+0x26f/frame 0xfffffe06653cc9a0
amd64_syscall() at amd64_syscall+0x2c4/frame 0xfffffe06653ccab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe06653ccab0

Created attachment 170753 [details]
patch fixing memory initalisation bug in nvidia-modeset

With the kernel panic it was quite easy to find two occurrences of use of non-initialised memory.  The attached patch fixes those!

The other locking issue ("acquiring duplicate lock") still happens, but seems to be benign.

This however does not solve the VT corruption issue.

I also added this to the port Makefile to enable the use of the patch:

.if ${NVVERSION} >= 358.009
EXTRA_PATCHES+=        ${FILESDIR}/extra-patch-src_nvidia-modeset_nvidia-modeset-freebsd.c
.endif

The patch works for all driver versions I tried, albeit with some fuzz for earlier versions (358.16 & 361.42).

I'm not a port makefile expert, but this "works for me".

Ultima, perhaps you could update your port patch including this?

Created attachment 170757 [details]
nvidia-driver-364.19.diff

* Added patch as Bengt Ahlgren suggested


The port builds fine, have not tested with patch yet. Will need feedback.

*** Bug 207634 has been marked as a duplicate of this bug. ***

Adjusting request to latest version in the patches, 364.19. Ultima, can we obsolete any of the previous patches?

Also setting maintainer timeout.

Comment on attachment 170753 [details]
patch fixing memory initalisation bug in nvidia-modeset

Included in nvidia-driver-364.19.diff of May 28

All of the patches except nvidia-driver-364.19 are obsolete. The struct threads is in makefile and the other two are previous versions of this driver.

What is the status of using the nVidia BLOB with vt()? With driver 367.18 I still have no working console, it is distorted and unusable.

Can we try to summarise the current status? My experience is as follows mostly running 364.19 (Ultima's May 28 port patch) on 10.3-R amd64 using a GTX 550Ti, but I believe there is no difference with any other driver version with nvidia-modeset.ko.

syscons: No issues with freezes or panics at Xorg startup or otherwise. Console works as expected. Suspend/resume works. I.e., no issues whatsoever. This is how I normally run my system so it has quite some hours of testing.

vt(legacy boot): Console turns blocky when Xorg starts, but returns to normal when Xorg exits. No issues with freezes or panics at Xorg startup. Suspend/resume does not work. I have only tested this combination a few times, so no experience running it for longer durations.

vt(efi boot): have not tried.

A comment on vt: with the i915kms driver I use on my laptop with embedded Intel graphics, vt prints out this when the driver loads and Xorg starts:

VT: Replacing driver "vga" with new "fb".

But there is no such message with the nvidia driver. This leads me to suspect that the nvidia driver does not have any support for vt. They likely only support release versions of FreeBSD which at the moment all have syscons as the default.

In any case, I argue for that the May 28 port patch be committed now!

Comment 59 Jean-Sébastien Pédron 2016-06-14 08:54:40 UTC

Hi all!

We would like to reach out to our contact at NVIDIA about those issues.

A new version, 367.27, was released yesterday. So before we annoy him, could you all please test this version and report if problems still exist?

Thank you!

(In reply to Jean-Sébastien Pédron from comment #59)
I ran 367.27 with syscons briefly yesterday without issues.  It still needs the memory init patch for nvidia-modeset-freebsd.c.  I have already provided that patch to nvidia, but have received no feedback.

Running 367.27 with the port's diff provided here, I see following problems on CURRENT (r301959):

w/o UEFI and vt():
- blocky and unusable console
- most recent CURRENT > r300830 seems to run fan speed of GTX 960 GPUs at highest level (noise is barely to stand). The boards in questions are MSI GTX 960 4G "Gaming" (do not be bothered by Gaming, it's just a suiatble and affordable GPU which suits our/my needs).

w UEFI and vt():
- with Quadro NVS 315 GPU, the console remains dark. This behaviour is also with 364.19. 364.18 doesn't work, earlier versions with nvidia-modeset.ko crash or have distorted display
- with UEFI boot and nvidia-modeset.ko loaded, some workstations are incapable of shutting down and power off via "shutdown -p now", it seems ACPI isn't working (black screen, box is running and waiting to be powered down via PWR button). Reboot is also not possible, box remains in black screen awaiting manual interaction. This doesn't happen when no nvidia-modeset.ko module is present.

Comment 62 Kevin Bowling 2016-06-18 05:43:46 UTC

The latest is blocking the good right now, can we bump to the minimal 35x.xx version that will allow xorg-server 1.18 in the tree, and figure out 36x.xx after?

(In reply to Kevin Bowling from comment #62)
It is not so simple - xorg-server 1.18 needs 358.16 or later. All come with nvidia-modeset and thus have the vt corruption issue.

I think it should be updated to the current version ASAP (currently 367.27). Nvidia might not get around to fix the vt corruption issue before 11.0 is out, since that will be the first release where vt is the default.

Created attachment 171554 [details]
nvidia-driver-367.27.diff

* Updated to 367.27
* Added x11 and xext to depends

portlint -AC:
WARN: Makefile: FREEBSD_AGP appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: PAE appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: possible use of absolute pathname "/usr/bin/join".
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
WARN: Makefile: unless this is a master port, PORTVERSION has to be set by "=", not by "?=".
WARN: Makefile: new ports should not set PORTREVISION.
WARN: Makefile: using hyphen in PORTNAME. consider using PKGNAMEPREFIX and/or PKGNAMESUFFIX.
WARN: Makefile: "MASTER_SITE_SUBDIR" has to appear earlier.
0 fatal errors and 8 warnings found.

poudriere bulk -tC:
           304       340     367.27
11amd64: success   success   success
11i386:  success   success   success
103amd64:success   success   success
103i386: success   success   success
93amd64: spdylay requires OpenSSL 1.0.1+
93i386:  spdylay requires OpenSSL 1.0.1+

(In reply to Kevin Bowling from comment #62)
Danfe has mentioned in another thread about 2 weeks ago:

I have to do some infrastructure changes first before updating the port, and I'm still interested in maintaining it.  Please stand by. (PR 209951)


So it is being worked on it, clueless on how long it may take though.

Tested current patch on Skylake, Asus Z170-Deluxe, Nvidia 970 card, 10.3-RELEASE-p4, UEFI boot. Seems to work fine, 

VT(efifb): resolution 1920x1200
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  367.27  Thu Jun  9 18:20:24 PDT 2016

Will even run World of Warcraft under Wine on a 4k Display.

Comment 67 Kevin Bowling 2016-06-19 00:25:15 UTC

Tried Ultima's 18 June driver on Lenovo P50, works well for gfx with Optimus disabled.  If I try to switch back to a vt console, it is black, but from that I can switch back to X.

Comment 68 Kevin Bowling 2016-06-19 00:26:25 UTC

The test above was done with xserver 1.18.3 and mesa 12.0.0 rc2.

According to the blocked ports by this one, Guido Falsi found this email on the list (see PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210691):

https://lists.freebsd.org/pipermail/freebsd-x11/2016-June/017687.html

It seems, there is a serious problem with the recent BLOB's library.

Created attachment 172039 [details]
nvidia-driver-367.27.diff

* Adjusted for recent update to meta ports

(In reply to ohartman from comment #69)
Almost just a +1, but 364.19 is OK for me, although you said >=364.19 are NG in another PR you mentioned.

Grepping "nv_vasprintf" after make configure (specifying DISTVERSION),
364.19 shows up only one
 work/NVIDIA-FreeBSD-x86_64-364.19/src/nvidia-modeset/nv-modeset-kernel.o

while367.27 shows up more.
 work/NVIDIA-FreeBSD-x86_64-367.27/obj/linux/libnvidia-glcore.so.367.27
 work/NVIDIA-FreeBSD-x86_64-367.27/obj/linux/libnvidia-eglcore.so.367.27
 work/NVIDIA-FreeBSD-x86_64-367.27/obj/libnvidia-eglcore.so.1
 work/NVIDIA-FreeBSD-x86_64-367.27/obj/libnvidia-glcore.so.1
 work/NVIDIA-FreeBSD-x86_64-367.27/src/nvidia-modeset/nv-modeset-kernel.o

Maybe some helper library is missing, or the symbols are not exported.
(Declared as static and ld cannot find it, although already linked internally?)

Anyway, 367.27 worked fine for me (at least as 364.19 does) using xorg-server built with 364.19. The problem I encountered is that some ports including xorg-server doesn't build (link) anymore after updating nvidia-driver to 367.27.

Created attachment 172587 [details]
nvidia-driver-367.35.diff

* Updated to 367.35

portlint -AC:
WARN: Makefile: FREEBSD_AGP appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: PAE appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
WARN: Makefile: unless this is a master port, PORTVERSION has to be set by "=", not by "?=".
WARN: Makefile: new ports should not set PORTREVISION.
WARN: Makefile: using hyphen in PORTNAME. consider using PKGNAMEPREFIX and/or PKGNAMESUFFIX.
WARN: Makefile: "MASTER_SITE_SUBDIR" has to appear earlier.
0 fatal errors and 7 warnings found.

poudriere bulk -tC:
                      304        340      367.27
12amd64:  success   success   success
12i386:      success   success   success
101amd64:success   success   success
101i386:    success   success   success
93amd64:  spdylay requires OpenSSL 1.0.1+
93i386:      spdylay requires OpenSSL 1.0.1+

I don't have 11 jails setup right now but I'm sure it will build fine, this is appears to just be a patch release from 367.27.

I've tested version 367.35 with the provided updated patch. It builds correctly and works well with FreeBSD 11 beta 1. The unfortunate linker issue with nv_vasprintf has also been fixed and the affected ports build as well.

However, the issue with vt remains. The driver is fine when starting x server from the command line, but once xserver is terminated via ctrl alt f1 the screen becomes garbled. This issue does not occur with syscons.

Out of curiosity, are there any plans to make it so the port installs 64-bit Linux libraries? Right now it only installs 32-bit ones.

I'm not sure where this is at the moment from the comments. Are we waiting on testing or a fix? I'm happy to assist with any testing if required, I'm using the latest patch (I think, hard to keep up) on a 970 and all appears fine.

(In reply to Mark Dixon from comment #75)
Danfe has some infrastructure changes before updating the port bug #209951

Comment 77 Conrad Meyer 2016-08-18 18:43:08 UTC

https://reviews.freebsd.org/D7569

I'm ready to commit this, pending ports committer sign-off.

Is the vt(4) problem to be solved?

Comment 79 Conrad Meyer 2016-08-18 19:08:51 UTC

(In reply to ohartman from comment #78)
> Is the vt(4) problem to be solved?

Please ask Nvidia about that.

(In reply to ohartman from comment #78)
It's funny you asked that. I've been trying to figure that out myself. I did a fresh install of FreeBSD 11 (UEFI and zfs). Of course with UEFI you have to use vt. I'm running xserver version 1.18.4 and Nvidia driver 367.35. The handoff from xserver to vt has been ok. No console corruption at all. Switching between ctrl alt f1 to ctrl alt f9 reveals no corruption. I've been loading nvidia_modeset from loader.conf.

Before I was using FreeBSD 10 stable updated to FreeBSD 11 and xserver 1.18.4 and Nvidia driver 367.35. The install was a manual zfs install with MBR. The handoff from xserver to vt would reveal console corruption.

(In reply to jeremy.m.cox from comment #80)

Thank you for responding to my funny question ;-)

Either on UEFI or non-UEFI, I use vt(4) and nVidia 367.35. Running 12-CURRENT (most recent build, daily basis update as a most recent ports tree and updates on daily basis), I still have a non working console when nvidia_modeset module is loaded (also loaded from rc.conf/rc.conf.local). The X server is the official 1.17.4 in the ports.

So, I guess I've missed something. Xorg server 1.18.X isn't officially in the ports, is it? Or it there a knob I miss, like xorg_ng=yes?

Comment 82 Kubilay Kocak 2016-08-19 14:56:47 UTC

@danfe - It's been a month since attachment 172587 [details] was created for review, which leaves this issue maintainer-timeout territory. 

Add link to phabricator review by cem@

Comment 83 Kubilay Kocak 2016-08-19 14:58:39 UTC

Update summary to match latest review code

@Danfe, sorry if the patch doesn't meet you're expectations. I'v been waiting for a response for 8+ months when I started the cleanup/update. If you had mentioned you're dissatisfaction sometime in that period I would have worked it out.

(In reply to ohartman from comment #81)
I use the xserver-next branch in the graphics development git repo...

https://github.com/freebsd/freebsd-ports-graphics/tree/xserver-next

But since they are pushing the nvidia-driver update and most likely the xserver 1.18.4 update soon you may want to just wait for that instead of cloning repo. However, I can't imagine the version of xserver has anything to do with the vt console corruption issue. I think it's an issue with vt_efifb used in UEFI vs vt_vga used for syscons. However, that is a completely uneducated guess based on nothing but conjecture.

(In reply to jeremy.m.cox from comment #85)
Sorry not vt_vga for syscons, but vt_vga for a non EFI boot process.

Created attachment 173883 [details]
Updated patch for ports r420499 or later

Original patch here doesn't apply anymore after ports r420482-r420499 update.
Updated patchset is in Phabricator, but doesn't build as of missing fix.

This is a quick hack to be built. Builds and runs fine for me.
I would be better reporting on Phabricator, but I don't have account for it.

Comment 88 Conrad Meyer 2016-08-20 05:47:09 UTC

(In reply to Tomoaki AOKI from comment #87)

I think these were the fixes needed?  Thanks!
https://reviews.freebsd.org/D7569?vs=19509&id=19511&whitespace=ignore-most#toc

Comment 89 Kubilay Kocak 2016-08-20 08:37:46 UTC

@Tomoaki, the review is currently the authoritative changeset, adding patches here will confuse. If any updates are required to the change in phabricator, please add comments there so Conrad can update them if required.

Comment 90 Kubilay Kocak 2016-08-20 08:38:41 UTC

Comment on attachment 172587 [details]
nvidia-driver-367.35.diff

Obsoleted by https://reviews.freebsd.org/D7569

Comment 91 Kubilay Kocak 2016-08-20 08:39:08 UTC

Comment on attachment 173883 [details]
Updated patch for ports r420499 or later

Obsoleted by https://reviews.freebsd.org/D7569

Comment 92 Kubilay Kocak 2016-08-20 08:40:05 UTC

The changeset in D7569 will be committed soon (see review comments and followup by danfe/cem

(In reply to Kubilay Kocak from comment #89)

Thanks for your advice.
I registered myself to Phabricator and left inline comment for another required change.

  *I still wonder if I'm a proper person to be registered there...

(In reply to Conrad E. Meyer from comment #88)

Thanks for your work, Conrad!
I left a inline comment on Phabricator (duplicated patch issue).
Please see my inline comment on Phabricator for detail.

 *Not understood Phabricator enough, so I couldn't update the diff itself.

Comment 95 Kubilay Kocak 2016-08-20 14:41:12 UTC

(In reply to Tomoaki AOKI from comment #93)

Everyone is welcome to create accounts :)

Comment 96 commit-hook 2016-08-28 16:57:23 UTC

A commit references this bug:

Author: cem
Date: Sun Aug 28 16:57:05 UTC 2016
New revision: 421027
URL: https://svnweb.freebsd.org/changeset/ports/421027

Log:
  x11/nvidia-driver: Update to 367.35

  * Add needed x11 and xext dependencies

  Thanks to everyone who submitted patches, tested, and reviewed this update.

  PR:		201340
  Submitted by:	Bengt Ahlgren <bengta at sics.se>, Kevin Bowling <kbowling@>,
  		Oleg <zoleg at vusovich.ru>,
  		Tomoaki AOKI <junchoon at dec.sakura.ne.jp>,
  		Ultima <Ultima1252 at gmail.com>
  Tested by:	Jeremy Cox <jeremy.m.cox at gmail.com>,
  		O. Hartmann <ohartman at zedat.fu-berlin.de>,
  		Tomoaki AOKI
  Approved by:	danfe
  Differential Revision:	https://reviews.freebsd.org/D7569

Changes:
  head/x11/nvidia-driver/Makefile
  head/x11/nvidia-driver/distinfo
  head/x11/nvidia-driver/files/extra-patch-mk-nvidia.lib.mk
  head/x11/nvidia-driver/files/extra-patch-src_nvidia-modeset_nvidia-modeset-freebsd.c
  head/x11/nvidia-driver/files/extra-patch-src_nvidia_Makefile
  head/x11/nvidia-driver/files/extra-patch-src_nvidia_nv-freebsd.h
  head/x11/nvidia-driver/files/extra-patch-src_nvidia_nv-misc.h
  head/x11/nvidia-driver/files/patch-mk_nvidia.lib.mk
  head/x11/nvidia-driver/pkg-plist