regression: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214769 kernel: KLD nvidia-modeset.ko: depends on nvidia - not available or version mismatch kernel: linker_load_file: Unsupported file type kernel: link_elf_obj: symbol sc_get_softc undefined kernel: linker_load_file: Unsupported file type FreeBSD rimwks 11.0-STABLE FreeBSD 11.0-STABLE #1 r312105M: Sat Jan 14 05:59:46 MSK 2017 root@rimwks:/usr/obj/usr/src/sys/RIMWKSx64 amd64
Created attachment 178889 [details] patch Please try the attached patch. You can apply it from "cd /usr/ports" using "svn patch /path/to/patchfile" or "patch < /path/to/patchfile".
svn patch /root/nv.patch U x11/nvidia-driver/Makefile A x11/nvidia-driver/files/extra-patch-src_nvidia_nvidia_os.c ... ===> Applying extra patch /usr/ports/x11/nvidia-driver/files/extra-patch-src_nvidia_nvidia_os.c patch: **** malformed patch at line 15: @@ -740,6 +743,7 @@ void NV_API_CALL os_get_screen_info( (only ACPI_PM option set)
Created attachment 178905 [details] patch2 Ugh, sorry about that. In files/extra-patch-src_nvidia_nvidia_os.c on line 3 change "@@ -13,10 +13,12 @@" into "@@ -13,9 +13,11 @@".
Yes, now build ok and driver load ok.
Since it's past 2 weeks after the patch, could we not wait for the maintainer and just commit the patch?
Alexey Dokuchaev, what will be with this patch?
Comment on attachment 178905 [details] patch2 Maintainer timeout (5+ months), implicit approval
Patch author is a committer, re-assign accordingly. If the patch and QA needs updating/reconfirming, please do so
Created attachment 183217 [details] respect kernel options I try to rewrite patch to make it respect kernel options, but it is undone: 1. No code for VT 2. Make does not get DEV_SC and DEV_VT from opt_syscons.h - it is empty, and does not included from ${KERNBUILDDIR}.
The patch is a hack that I cannot test because I don't use this version of nvidia-driver. Can someone confirm everything keeps working (VT switching, suspend/resume,...) with and without syscons in kernel config?
This patch for all versions since we need to load linux modules. Build your kenrel without sc and you see that current nvidia driver will fail to load without this patch.
Reset assignee (see comment 7). Open to take
ping
Created attachment 185615 [details] update patch to latest driver src
Can we assume that this can be closed due to the age alone? :) Please reopen, if still relevant.
Created attachment 213300 [details] Remove os_get_screen_info() Yes, this is still a problem -- for the vt-users -- just as originally described. And, yes, the tijl's idea of simply removing the sc-using block of code from nvidia_os.c works. The patch can be applied unconditionally, because the patched function -- os_get_screen_info() -- is not actually used anywhere... My patch can be used for the current nvidia-driver (latest) and for the nvidia-driver-390. The earlier ones (304 and 340) don't seem to need it.
You have to specify a comment when changing status from Closed.
(In reply to Mikhail Teterin from comment #16) > The patch can be applied unconditionally, > because the patched function -- os_get_screen_info() > -- is not actually used anywhere... These functions are usually called directly from the blob: % grep os_get_screen_info -r nv-kernel.o Binary file nv-kernel.o matches
...try switching from x11 to vt and back ;)
(In reply to Alex S from comment #19) > ...try switching from x11 to vt and back ;) Oh, Ok... Does it work any better with the stripped-out version of the function? That is, when it simply zeroes-out the pointers passed to it, as tijl's patch proposes? Maybe, it can simply always do that? Also, is there a mechanism to dynamically check, whether a particular symbol is available at runtime? Some in-kernel equivalent of dlsym(NULL, "sc_get_softc")?
(In reply to Mikhail Teterin from comment #20) Well, no, completely removing the function doesn't work, it complains about the missing function itself then. The old patch(es) didn't apply for me anymore (NVidia meanwhile included code to handle the UEFI screens). I instead hacked together something that #ifdef's out all that syscons code, so in the end, the data is zeroed out as with the previous patches. That gets me a working X11, though just a plain 80x25 text with huge letters on the screen only. To add to all the problems, the required patch would be different between different driver versions (I need the 390 one for my card), but all these ports re-use the generic directory. The probably best solution would be a sysconf entry to retrieve that information, but unless it's already in place (I don't know), it would require quite some amount of time until it could propagate here.
3 years later, still the same situation. Updated my graphics card so I can use nvidia-driver-470. Still fails to load due to the assumption everything were syscons. This time, I wasn't in the mood to polish up the old patch (too many things have been changed in the parent port). I just #if 0'ed out the syscons stuff. % cat /usr/ports/x11/nvidia-driver-470/files/patch-hack --- src/nvidia/nvidia_os.c.orig 2022-10-19 02:09:21.000000000 +0200 +++ src/nvidia/nvidia_os.c 2023-10-24 21:45:59.440958000 +0200 @@ -18,7 +18,9 @@ #include <sys/linker.h> #include <sys/timex.h> #include <sys/stack.h> +#if 0 #include <dev/syscons/syscons.h> +#endif #include <machine/metadata.h> MALLOC_DEFINE(M_NVIDIA, "nvidia", "NVIDIA memory allocations"); @@ -807,6 +809,7 @@ return; } } +#if 0 { const sc_softc_t *sc = sc_get_softc(0, SC_KERNEL_CONSOLE); @@ -833,6 +836,7 @@ } } } +#endif *pPhysicalAddress = 0; *pFbWidth = *pFbHeight = *pFbDepth = *pFbPitch = 0;
^Triage: forwarding from the FreeBSD Forums: https://forums.freebsd.org/threads/nvidia-resume-unreliable.91180/page-2#post-632965 From user angry_vincent: The nvidia driver for FreeBSD that is provided by upstream [390 -- bugmeister] is still relying on sc ( the syscons ). it is still present in GENERIC, so it works for all. but the situation is an awkward one for case of UEFI/vt framebuffer.
^Triage: forwarding from the FreeBSD Forums: https://forums.freebsd.org/threads/nvidia-resume-unreliable.91180/page-2#post-633003 from user skunk: Don't bother with that PR. It regards only the utterly obsolete driver 390. There have been many, many changes in 470 and again many many changes in 535.
^Triage: forwarding from the FreeBSD Forums: https://forums.freebsd.org/threads/nvidia-resume-unreliable.91180/page-3#post-633011 from user grahamperrin: It's not obsolete. [It]'s a legacy driver.