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
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2017-01-14 04:40 UTC by Ivan Rozhuk
Modified: 2023-12-13 23:11 UTC (History)
12 users (show)

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


Attachments
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 freebsd_triage 2017-01-14 17:51:10 UTC
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".
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 freebsd_triage 2017-01-15 10:28:10 UTC
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 @@".
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 freebsd_triage 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]
patch2

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 freebsd_triage 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
ping
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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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")?
Comment 21 Joerg Wunsch freebsd_committer freebsd_triage 2022-01-19 20:49:07 UTC
(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.
Comment 22 Joerg Wunsch freebsd_committer freebsd_triage 2023-10-24 20:31:48 UTC
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;
Comment 23 Mark Linimon freebsd_committer freebsd_triage 2023-12-13 23:07:05 UTC
^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.
Comment 24 Mark Linimon freebsd_committer freebsd_triage 2023-12-13 23:09:52 UTC
^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.
Comment 25 Mark Linimon freebsd_committer freebsd_triage 2023-12-13 23:11:50 UTC
^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.