Bug 216050 - x11/nvidia-driver: kernel module fails on vt() to load: link_elf_obj: symbol sc_get_softc undefined
Summary: x11/nvidia-driver: kernel module fails on vt() to load: link_elf_obj: symbol ...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Alexey Dokuchaev
Keywords: needs-qa
Depends on:
Reported: 2017-01-14 04:40 UTC by Ivan Rozhuk
Modified: 2020-04-12 00:40 UTC (History)
10 users (show)

See Also:
bugzilla: maintainer-feedback? (danfe)
koobs: merge-quarterly?

patch (2.22 KB, patch)
2017-01-14 17:51 UTC, Tijl Coosemans
no flags Details | Diff
patch2 (2.22 KB, patch)
2017-01-15 10:28 UTC, Tijl Coosemans
koobs: maintainer-approval+
Details | Diff
respect kernel options (3.93 KB, patch)
2017-06-04 18:54 UTC, Ivan Rozhuk
no flags Details | Diff
update patch to latest driver src (3.98 KB, patch)
2017-08-20 21:11 UTC, Ivan Rozhuk
no flags Details | Diff
Remove os_get_screen_info() (3.15 KB, patch)
2020-04-11 19:41 UTC, Mikhail Teterin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Rozhuk 2017-01-14 04:40:28 UTC
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
Comment 1 Tijl Coosemans freebsd_committer 2017-01-14 17:51:10 UTC
Created attachment 178889 [details]

Please try the attached patch.  You can apply it from "cd /usr/ports" using "svn patch /path/to/patchfile" or "patch < /path/to/patchfile".
Comment 2 Ivan Rozhuk 2017-01-15 00:30:23 UTC
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)
Comment 3 Tijl Coosemans freebsd_committer 2017-01-15 10:28:10 UTC
Created attachment 178905 [details]

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 @@".
Comment 4 Ivan Rozhuk 2017-01-15 14:26:51 UTC
Yes, now build ok and driver load ok.
Comment 5 Piotr Kubaj freebsd_committer 2017-02-11 17:28:58 UTC
Since it's past 2 weeks after the patch, could we not wait for the maintainer and just commit the patch?
Comment 6 Ivan Rozhuk 2017-05-09 01:49:40 UTC
Alexey Dokuchaev, what will be with this patch?
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2017-06-04 14:55:58 UTC
Comment on attachment 178905 [details]

Maintainer timeout (5+ months), implicit approval
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2017-06-04 14:57:04 UTC
Patch author is a committer, re-assign accordingly. If the patch and QA needs updating/reconfirming, please do so
Comment 9 Ivan Rozhuk 2017-06-04 18:54:45 UTC
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}.
Comment 10 Tijl Coosemans freebsd_committer 2017-06-06 18:00:42 UTC
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?
Comment 11 Ivan Rozhuk 2017-06-06 21:16:40 UTC
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.
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2017-06-07 04:34:40 UTC
Reset assignee (see comment 7). Open to take
Comment 13 Ivan Rozhuk 2017-07-12 00:28:18 UTC
Comment 14 Ivan Rozhuk 2017-08-20 21:11:30 UTC
Created attachment 185615 [details]
update patch to latest driver src
Comment 15 Tobias C. Berner freebsd_committer 2019-11-09 19:07:27 UTC
Can we assume that this can be closed due to the age alone? :)

Please reopen, if still relevant.
Comment 16 Mikhail Teterin freebsd_committer 2020-04-11 19:41:32 UTC
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.
Comment 17 Mikhail Teterin freebsd_committer 2020-04-11 19:42:44 UTC
You have to specify a comment when changing status from Closed.
Comment 18 Alex S 2020-04-11 21:36:50 UTC
(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
Comment 19 Alex S 2020-04-11 21:43:47 UTC
...try switching from x11 to vt and back ;)
Comment 20 Mikhail Teterin freebsd_committer 2020-04-12 00:40:35 UTC
(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")?