[Nvidia-tkg-dkms Compatibility] `5.17.2-255-pds-llvm` Fails to Build Against `Nvidia-all`

[ThisNekoGuy]

This occurs regardless of whether lto-thin was used or no lto was used:

==> dkms install --no-depmod nvidia/510.60.02 -k 5.17.2-255-tkg-pds-llvm
Error! Bad return status for module build on kernel: 5.17.2-255-tkg-pds-llvm (x86_64)
Consult /var/lib/dkms/nvidia/510.60.02/build/make.log for more information.
==> WARNING: `dkms install --no-depmod nvidia/510.60.02 -k 5.17.2-255-tkg-pds-llvm' exited 10

make.log linux-tkg.cfg.zip

[Tk-Glitch]

This is because you don't have the resolve_btfids from your previous issue. Your current kernel configuration is incorrect for Nvidia.

[ThisNekoGuy]

Uhhhh, I'm a bit confused... :thinking: How do I explicitly know when I do or don't have it?

[Tk-Glitch]

The better question would be what did you change in your defconfig vs default to get this result? :frog:

[ThisNekoGuy]

I'm trying to figure that out, I can't seem to tell what in there would cause that, I've compared them three times :woozy_face:

[Tk-Glitch]

Make sure you have those in:

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y

They are enabled by default in Arch's defconfig btw.

[ThisNekoGuy]

I'll try that; though, that last one (CONFIG_DEBUG_INFO_BTF_MODULES) isn't appearing in the Kconfig menu

[Tk-Glitch]

depends on: CONFIG_DEBUG_INFO_BTF && CONFIG_MODULES && CONFIG_PAHOLE_HAS_SPLIT_BTF

[ThisNekoGuy]

CONFIG_PAHOLE_HAS_SPLIT_BTF isn't in here for some reason, which might explain that a little bit Edit: It does show up in the config file as enabled now though; just need it to build because it's throwing zliberrors during compilation now

[ThisNekoGuy]

Is it just me or is there something else I'm just not noticing about why I'm suddenly getting an lld zlib error? As a result, two more errors follow it and the build fails :/

kernelconfig.new.zip linux-tkg.cfg.zip

[ThisNekoGuy]

Compiles fine with GCC though; but the same issue occurs with the Nvidia module, though less severely than the the llvm log, from what I can tell: make.log

And this is with the suggested changes, and it also fails with the xone-git-dkms AUR module too :/

Quite stumped

[Tk-Glitch]

I simply cannot reproduce any of this. I'm also using an untouched defconfig and GCC so there's that, but Nvidia modules are building just fine. You seem to have other issues here.

[ThisNekoGuy]

Hmm... Okay, I'll just start from scratch then, I guess Hopefully it just doesn't happen again :/

[ThisNekoGuy]

Nope, even starting from scratch with the default config and building my way back fixes it... I've got no clue why my configuration causes linking to Nvidia with dkms to fail this way; my head hurts just thinking about it :woozy_face:

Even with GCC, though, now it errors out for a different reason despite still leaving those debug values enabled make.log

[ThisNekoGuy]

Oh my god, undoing that debug stuff this time fixed it :skull_and_crossbones: Well, at least it built now... not with llvm though; although, I'm not sure I want to mess with that again right now Lol

[OneOfOne]

I haven't changed anything since 5.17.1 and I have ran into this as well, I'm not using a custom kernel config.

./tools/bpf/resolve_btfids/resolve_btfids: No such file or directory

this is for all DKMS modules, not just nvidia.

my linux-tkg.cfg:

# Kernel Version - Options are "5.4", "5.7", "5.8", "5.9", "5.10", "5.11", "5.12", "5.13", "5.14"
_version="5.17"

#### MISC OPTIONS ####

# External config file to use - If the given file exists in path, it will override default config (customization.cfg) - Default is ~/.config/frogminer/linux-tkg.cfg
_EXT_CONFIG_PATH=~/.config/frogminer/linux-tkg.cfg

# [Arch specific] Set to anything else than "true" to limit cleanup operations and keep source and files generated during compilation.
# Default is "true".
_NUKR="true"

# Set to the number corresponding to a predefined profile to use it. The options selected by the profile will override customization.cfg and external config files.
# Current list of available profiles :
# 1 - Custom (meaning nothing will be enforced and you get to configure everything)
# 2 - Ryzen desktop (performance)
# 3 - Generic Desktop (Performance)
_OPTIPROFILE="2"

# Set to true to bypass makepkg.conf and use all available threads for compilation. False will respect your makepkg.conf options.
_force_all_threads="true"

# Set to true to prevent ccache from being used and set CONFIG_GCC_PLUGINS=y (which needs to be disabled for ccache to work properly)
_noccache="true"

# Set to true to use modprobed db to clean config from unneeded modules. Speeds up compilation considerably. Requires root - https://wiki.archlinux.org/index.php/Modprobed-db
# Using this option can trigger user prompts if the config doesn't go smoothly.
# !!!! Make sure to have a well populated db !!!! - Leave empty to be asked about it at build time
_modprobeddb="false"

# modprobed-db database file location
_modprobeddb_db_path=~/.config/modprobed.db

# Set to "1" to call make menuconfig, "2" to call make nconfig, "3" to call make xconfig, before building the kernel. Set to false to disable and skip the prompt.
_menunconfig="false"

# Set to true to generate a kernel config fragment from your changes in menuconfig/nconfig. Set to false to disable and skip the prompt.
_diffconfig=""

# Set to the file name where the generated config fragment should be written to. Only used if _diffconfig is active.
_diffconfig_name=""

# [install.sh specific] Use tmpfs as a work directory, recommended when RAM >= 32GB to reduce HDD/SSD usage. For more information, see https://wiki.archlinux.org/title/Tmpfs
_use_tmpfs="true"

# [install.sh specific] tmpfs folder path, only used when _use_tmpfs="true".
#                       Creates a linux-tkg work folder within that pathmake sure to have nothing important in "$_tmpfs_path/linux-tkg"
_tmpfs_path="/tmp"

# [install.sh: Generic and Gentoo specific] Dracut options when generating initramfs
_dracut_options="--lz4"

#### KERNEL OPTIONS ####

# Name of the default config file to use for the kernel
# Default (empty)  : "config.x86_64" from the linux-tkg-config/5.y folder.
# "running-kernel" : Picks the .config file from the currently running kernel.
#                    It is recommended to be running an official kernel before running this script, to pick off a correct .config file
# "config_hardened.x86_64" : config file for a hardened kernel, available for kernel version "5.13", "5.10" and "5.4" .
#                            To get a complete hardened setup, you have to use "cfs" as _cpusched.
# User provided value : custom user provided file, the given path should be relative to the PKGBUILD file. This enables for example to use a user stripped down .config file.
#         If the .config file isn't up to date with the chosen kernel version, any extra CONFIG_XXXX is set to its default value.
# Note: the script copies the resulting .config file as "kernelconfig.new" next to the PKGBUILD as a convenience for an eventual re-use. It gets overwritten at each run.
#       One can use "kernelconfig.new" here to always use the latest edited .config file. modprobed-db needs to be used only once for its changes to be picked up.
_configfile=""

# Determine whether to call "olddefconfig" (default) or "oldconfig" for manual config updating interaction.
_config_updating="olddefconfig"

# Disable some non-module debugging - See PKGBUILD for the list
_debugdisable="false"

# Strip the vmlinux file after build is done. Set to anything other than "true" if you require debug headers. Default is "true"
_STRIP="true"

# LEAVE AN EMPTY VALUE TO BE PROMPTED ABOUT FOLLOWING OPTIONS AT BUILD TIME

# CPU scheduler - Options are "upds" (TkG's Undead PDS), "pds", "bmq", "muqss", "cacule" or "cfs" (kernel's default)
_cpusched="cacule"

# Compiler to use - Options are "gcc" or "llvm".
# For advanced users.
_compiler="llvm"

# Force the use of the LLVM Integrated Assembler whether using LLVM, LTO or not.
# Set to "1" to enable.
_llvm_ias="1"

# Clang LTO mode, only available with the "llvm" compiler - options are "no", "full" or "thin".
# ! This is currently experimental and might result in an unbootable kernel - Not recommended !
# "no: do not enable LTO"
# "full: uses 1 thread for Linking, slow and uses more memory, theoretically with the highest performance gains."
# "thin: uses multiple threads, faster and uses less memory, may have a lower runtime performance than Full."
_lto_mode="thin"

# Apply PREEMPT_RT patchset to the kernel.
# ! Only CFS CPU scheduler is compatible with this patchset !
# Set to "1" to enable.
_preempt_rt="0"

# Forcibly apply the PREEMPT_RT patchset to the kernel, even when upstream does not officially support the kernel subversion.
# ! This will still not apply when the patch itself or linux-tkg (see _version) do not support the kernel major version - Not recommended !
# Set to "1" to enable.
_preempt_rt_force="0"

# CPU sched_yield_type - Choose what sort of yield sched_yield will perform
# For PDS and MuQSS: 0: No yield. (Recommended option for gaming on PDS and MuQSS)
#                    1: Yield only to better priority/deadline tasks. (Default - can be unstable with PDS on some platforms)
#                    2: Expire timeslice and recalculate deadline. (Usually the slowest option for PDS and MuQSS, not recommended)
# For BMQ:           0: No yield.
#                    1: Deboost and requeue task. (Default)
#                    2: Set rq skip task.
_sched_yield_type="0"

# Round Robin interval is the longest duration two tasks with the same nice level will be delayed for. When CPU time is requested by a task, it receives a time slice equal
# to the rr_interval in addition to a virtual deadline. When using yield_type 2, a low value can help offset the disadvantages of rescheduling a process that has yielded.
# MuQSS default: 6ms"
# PDS default: 4ms"
# BMQ default: 2ms"
# Set to "1" for 2ms, "2" for 4ms, "3" for 6ms, "4" for 8ms, or "default" to keep the chosen scheduler defaults.
_rr_interval="2"

# Set to "true" to disable FUNCTION_TRACER/GRAPH_TRACER, lowering overhead but limiting debugging and analyzing of kernel functions - Kernel default is "false"
_ftracedisable="false"

# Set to "true" to disable NUMA, lowering overhead, but breaking CUDA/NvEnc on Nvidia equipped systems - Kernel default is "false"
_numadisable="false"

# Set to "true" to enable misc additions - May contain temporary fixes pending upstream or changes that can break on non-Arch - Kernel default is "true"
_misc_adds="true"

# Set to "0" for periodic ticks, "1" to use CattaRappa mode (enabling full tickless) and "2" for tickless idle only.
# Full tickless can give higher performances in various cases but, depending on hardware, lower consistency. Just tickless idle can perform better on some platforms (mostly AMD based).
_tickless="1"

# Set to "true" to use ACS override patch - https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Bypassing_the_IOMMU_groups_.28ACS_override_patch.29 - Kernel default is "false"
_acs_override="false"

# Set to "true" to add Bcache filesystem support. You'll have to install bcachefs-tools-git from AUR for utilities - https://bcachefs.org/ - If in doubt, set to "false"
_bcachefs="false"

# Set to "true" to enable support for fsync, an experimental replacement for esync found in Valve Proton 4.11+ - https://steamcommunity.com/games/221410/announcements/detail/2957094910196249305
# Can be enabled alongside _futex_waitv on 5.14+ to use it as a fallback for older Proton builds
_fsync="true"

# Set to "true" to enable support for futex2, an experimental interface that can be used by proton-tkg and proton 5.13 experimental through Fsync - Can be enabled alongside fsync to use it as a fallback
# https://gitlab.collabora.com/tonyk/linux/-/tree/futex2-dev
_futex2="true"

# Set to "true" to enable backported patches to add support for the futex_waitv() syscall, a new interface for fsync. It will appear in mainline at Linux 5.16 release and requires a wine/proton with builtin support for it. It's expected to be available in Valve Proton 6.3 stable soon - https://github.com/ValveSoftware/wine/pull/128
# !! Disables futex2 interfaces support !!
# https://github.com/andrealmeid/futex_waitv_patches
_futex_waitv="true"

# Set to "true" to enable support for winesync, an experimental replacement for esync - requires patched wine - https://repo.or.cz/linux/zf.git/shortlog/refs/heads/winesync
# ! Can't be used on multiple kernels installed side-by-side, which will require https://aur.archlinux.org/packages/winesync-dkms/ instead of this option !
_winesync="false"

# Set to "true" to enable Binder and Ashmem, the kernel modules required to use the android emulator Anbox. ! This doesn't apply to 5.4.y !
_anbox="false"

# A selection of patches from Zen/Liquorix kernel and additional tweaks for a better gaming experience (ZENIFY) - Default is "true"
_zenify="true"

# compiler optimization level - 1. Optimize for performance (-O2); 2. Optimize harder (-O3); 3. Optimize for size (-Os) - Kernel default is "1"
_compileroptlevel="1"

# CPU compiler optimizations - Defaults to prompt at kernel config if left empty
# AMD CPUs : "k8" "k8sse3" "k10" "barcelona" "bobcat" "jaguar" "bulldozer" "piledriver" "steamroller" "excavator" "zen" "zen2" "zen3" (zen3 opt support depends on GCC11)
# Intel CPUs : "mpsc"(P4 & older Netburst based Xeon) "atom" "core2" "nehalem" "westmere" "silvermont" "sandybridge" "ivybridge" "haswell" "broadwell" "skylake" "skylakex" "cannonlake" "icelake" "goldmont" "goldmontplus" "cascadelake" "cooperlake" "tigerlake"
# Other options :
# - "native_amd" (use compiler autodetection - Selecting your arch manually in the list above is recommended instead of this option)
# - "native_intel" (use compiler autodetection and will prompt for P6_NOPS - Selecting your arch manually in the list above is recommended instead of this option)
# - "generic" (kernel's default - to share the package between machines with different CPU µarch as long as they are x86-64)
#
# https://en.wikipedia.org/wiki/X86-64#Microarchitecture_Levels)
# - "generic_v2" (depends on GCC11 - to share the package between machines with different CPU µarch supporting at least x86-64-v2
# - "generic_v3" (depends on GCC11 - to share the package between machines with different CPU µarch supporting at least x86-64-v3
# - "generic_v4" (depends on GCC11 - to share the package between machines with different CPU µarch supporting at least x86-64-v4
_processor_opt="native_amd"

# MuQSS only - Make IRQ threading compulsory (FORCE_IRQ_THREADING) - Default is "false"
_irq_threading="true"

# CacULE only - Enable Response Driven Balancer, an experimental load balancer for CacULE
_cacule_rdb="false"

# CacULE only - Load balance time period - Default is 19
# https://github.com/hamadmarri/cacule-cpu-scheduler/blob/master/patches/CacULE/RDB/rdb.patch#L56
_cacule_rdb_interval="19"

# MuQSS and PDS only - SMT (Hyperthreading) aware nice priority and policy support (SMT_NICE) - Kernel default is "true" - You can disable this on non-SMT/HT CPUs for lower overhead
_smt_nice="false"

# Trust the CPU manufacturer to initialize Linux's CRNG (RANDOM_TRUST_CPU) - Kernel default is "false"
_random_trust_cpu="false"

# MuQSS only - CPU scheduler runqueue sharing - No sharing (RQ_NONE), SMT (hyperthread) siblings (RQ_SMT), Multicore siblings (RQ_MC), Symmetric Multi-Processing (RQ_SMP), NUMA (RQ_ALL)
# Valid values are "none", "smt", "mc", "mc-llc"(for zen), "smp", "all" - Kernel default is "smt"
_runqueue_sharing="mc-llc"

# Timer frequency - "100" "500", "750" or "1000" ("2000" can be set for cacule cpu sched, and will fallback to default if set while on another schedulers) - More options available in kernel config prompt when left empty depending on selected cpusched with the default option pointed with a ">"
_timer_freq="2000"

# Default CPU governor - "performance", "ondemand", "schedutil" or leave empty for default (schedutil)
_default_cpu_gov="schedutil"

# Use an aggressive ondemand governor instead of default ondemand to improve performance on low loads/high core count CPUs while keeping some power efficiency from frequency scaling.
# It still requires you to either set ondemand as default governor or to select it in some way at runtime.
_aggressive_ondemand="true"

# [Advanced] Default TCP IPv4 algorithm to use. Options are: "yeah", "bbr", "cubic", "reno", "vegas" and "westwood". Leave empty if unsure.
# This config option will not be prompted
# Can be changed at runtime with the command line `# echo "$name" > /proc/sys/net/ipv4/tcp_congestion_control` where $name is one of the options above.
# Default (empty) and fallback : cubic
_tcp_cong_alg="yeah"

# You can pass a default set of kernel command line options here - example: "intel_pstate=passive nowatchdog amdgpu.ppfeaturemask=0xfffd7fff mitigations=off"
_custom_commandline="nowatchdog audit=0 enable_mtrr_cleanup cgroup_enable=memory swapaccount=1"

# Selection of Clearlinux patches
_clear_patches="true"

#### SPESHUL OPTION ####

# If you want to bypass the stock naming scheme and enforce something else (example : "linux") - Useful for some bootloaders requiring manual entry editing on each release.
# !!! It will also change pkgname - If you don't explicitely need this, don't use it !!!
_custom_pkgbase="linux-tkg-ooo"

# [non-Arch specific] Kernel localversion. Putting it to "Mario" will make for example the kernel version be 5.7.0-tkg-Mario (given by uname -r)
# If left empty, it will use "-tkg-${_cpusched}${_compiler}" where "${_cpusched}" will be replaced by the user chosen scheduler, ${_compiler} will be replaced by "-llvm" if clang is used (nothing for GCC).
_kernel_localversion=""

# Set to "true" to add back missing symbol for AES-NI/AVX support on ZFS - This is a legacy option that can be ignored on 5.10+ kernels - https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions.patch
_zfsfix="true"

#### USER PATCHES ####

# community patches - add patches (separated by a space) of your choice by name from the community-patches dir
# example: _community_patches="clear_nack_in_tend_isr.myrevert ffb_regression_fix.mypatch 0008-drm-amd-powerplay-force-the-trim-of-the-mclk-dpm-levels-if-OD-is-enabled.mypatch"
_community_patches=""

# You can use your own patches by putting them in a subfolder called linux<version>-tkg-userpatches (e.g. linux510-tkg-userpatches) next to the PKGBUILD and giving them the .mypatch extension.
# You can also revert patches by putting them in that same folder and giving them the .myrevert extension.

# Also, userpatches variable below must be set to true for the above to work.
_user_patches="true"

# Apply all user patches without confirmation - !!! NOT RECOMMENDED !!!
_user_patches_no_confirm="true"

#### CONFIG FRAGMENTS ####

# You can use your own kernel config fragments by putting them in the same folder as the PKGBUILD and giving them the .myfrag extension.

# Also, the config fragments variable below must be set to true for the above to work.
_config_fragments="true"

# Apply all config fragments without confirmation - !!! NOT RECOMMENDED !!!
_config_fragments_no_confirm="true"

[skeevy420]

Yeah, none of my modules have been building today either. After numerous builds I noticed something and I think it's line 934 of the PKGBUILD. It's doing a file check on a directory.

It should be using a -d instead of a -e. There are also some quotation marks that could be added and/or moved around. I just started a build with the following changes and I'll have the results in a little bit.

if [ "$_basever" -ge "516" ] && [ -d "$builddir/tools/bpf/resolve_btfids" ]; then
    install -Dt "$builddir/tools/bpf/resolve_btfids" tools/bpf/resolve_btfids/resolve_btfids
fi

Well, crap, that didn't work. I've tried my usual CFS config, tried with BMQ and PDS, nuked my linux-tkg directory and started over, and tried the above fix.

[skeevy420]

I just checked the Arch sources and they updated their defconfig to include

CONFIG_BPF_UNPRIV_DEFAULT_OFF=y

so I'm trying that now. Fingers crossed.

[ThisNekoGuy]

I have this set for GCC, and it builds against Nvidia, but I haven't been able to get it to load the driver for the last 6 hours - trying various things

[Tk-Glitch]

I have changed it a bit so it doesn't break for people with a working env. Please pull and try with those changes.

[ThisNekoGuy]

Yeah, that seems to be the issue with the GCC builds I've been doing too; I just have no clue what specifically is making resolve_btfids absent from where it should be

[ThisNekoGuy]

Make sure you have those in:

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y

They are enabled by default in Arch's defconfig btw.

Unironically, this is what fixes it; just don't know what to get rid of so that this isn't necessary... Unless kernel debug info is always necessary?

EDIT: That issue aside, I still find myself not being able to make it to SDDM with the Nvidia driver with it for some reason Edit 2: Might be because I forgot about NUMA like a dork; going through and comparing what else I accidentally changed from the default

[skeevy420]

I have changed it a bit so it doesn't break for people with a working env. Please pull and try with those changes.

That was enough to fix building 5.16 dkms modules for me.

In addition to CONFIG_BPF_UNPRIV_DEFAULT_OFF=y I mentioned above, upstream Arch has also enabled DAMON as well as disabled ZERO_CALL_USED_REGS to their 5.16 defconfig.

[Tk-Glitch]

I have synchronized our 5.16 defconfig with Arch's latest

[ThisNekoGuy]

I was using the 5.17 config, btw

[ThisNekoGuy]

So, I narrowed down the issue I was having with the Nvidia driver (besides the original linking issue you helped with @Tk-Glitch ) It's either one or all of these, as far as I can tell:

CONFIG_AMD_MEM_ENCRYPT=y
CONFIG_USER_NS=n
CONFIG_SYSFB_SIMPLEFB=y

None of these are set to those values in the default config, but it seems either one or all (haven't checked that) either cause me to infinitely stall on boot, boot to a green screen, or lose video signal altogether with the proprietary Nvidia driver

[skeevy420]

I think it's SIMPLEFB. That bug report describes everything you're describing.

[ThisNekoGuy]

I've identified them:

CONFIG_AMD_MEM_ENCRYPT=y
CONFIG_SYSFB_SIMPLEFB=y
CONFIG_FB_SIMPLE=y

AMD_MEM_ENCRYPT prevents proper booting for some reason SYSFB_SIMPLEFB does cause that green-screen issue FB_SIMPLE causes video to be cut out entirely; only using FB_EFI instead doesn't break it

CONFIG_USER_NS=n doesn't interfere with the driver but it does cause Plasma to act weird on launch

[Tk-Glitch]

Outside of AMD_MEM_ENCRYPT (which only enables support for the feature, and not actually turning it on as long as it's not enabled through userspace or with AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT), you have made changes to our defconfig. As expected, playing with the kernel config can break stuff if done incorrectly, and we can't really offer support for that :frog: Closing.

[ThisNekoGuy]

@Tk-Glitch I'm aware Lol Aside from fixing my own mess though, I'm communicating that so that maybe this information can be put into a note for proprietary Nvidia users somewhere so they don't make the same mistakes I did Lol

Would save others literally dozens of hours diagnosing this

[Tk-Glitch]

Of course. It was in no way critical, just very objective. Sorry :frog:

It's kind of a sensitive matter if we get deep into it, but ultimately we are offering a package that is already very configurable without touching the config yourself at any time, and testing and offering support for the combinations you can make that way is already pretty time consuming and complex.

Having that into a note of some sort would be opening a world of issues imho, as you can break your kernel and its features with hundreds of config combinations - even more so Nvidia machines - which would be a huge confusing PITA to document and maintain imho. That's also why we are offering some default config tweaks on top of the Arch base, so most users won't have to actually modify the config themselves while still getting some of the benefits of doing so like reduced debugging or skipping the modules you don't need with modprobed-db.

A warning regarding the dangers of modifying the configuration would be more valuable as is, but I believe neither solution is actually a solution. I'm open to discussion if you think it needs more care, but I'm not convinced currently.

[ThisNekoGuy]

I understand, it's alright

What you're saying makes sense though; although, I think the likelihood that the Nvidia drivers needing anything else to avoid or need as a prerequisite in the future to detract from that theoretical not is a bit slim... Similar to what you mentioned though, the default config concerning those modules works perfectly fine for Nvidia, I was just thinking something that says:

"Definitely don't touch these if you want a display for proprietary Nvidia;
don't even touch the rest of the config *manually* unless you know what you're doing"

But I can understand that could open the door for problem hunting...

Idk, it's difficult because it's not necessarily something to make people discouraged from learning/doing, but it's also an easy pitfall to get lost in, which is why I started from scratch with the tkg default config and only really stripped modules like: industria hardwarel, super niche hardware, radio, opposite CPU support (I use an AMD CPU so I stripped out Intel CPU support), Xen, VirtualBox, VMware, etc; I left a lot of everything from the default config alone (for example, I didn't even touch networking at all because there are a lot of those modules and they're pretty technical to understand), so once I got rid of everything that I could make sense of that was obvious didn't apply to both my system and most consumer desktops in general, it would be easier to just leave overly complex things alone and slowly figure out how to get Nvidia support to behave

(Sorry, felt like I ranted there, I'm kind of thinking out loud but also trying to prod at your brain to see what you think)

[AdelKS]

If you want to really go down the rabbit hole, Gentoo has extensive documentation on how to build the kernel config from the ground up, here's what you needed with Nvidia : https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers#Kernel If you want to meddle with other things in the kernel config, look up Gentoo documentation about it

[ThisNekoGuy]

If you want to really go down the rabbit hole, Gentoo has extensive documentation on how to build the kernel config from the ground up, here's what you needed with Nvidia : https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers#Kernel If you want to meddle with other things in the kernel config, look up Gentoo documentation about it

I already looked at that; it's because I followed that advice that I ended up with this problem

[AdelKS]

I see, then that documentation needs to be updated probably.

[ThisNekoGuy]

In my experience, the Gentoo wiki doesn't get updated as often as it honestly should; it's 1 of the 3 only reasons why I don't use Gentoo :/

[AdelKS]

If you pinpoint properly the reasons behind each config option you should absolutely update the page yourself. That's how the arch wiki is up to date anyway, users realizing things need to get updated

[ThisNekoGuy]

I'm aware, but it was bad enough for Gentoo that the installation guide to set up the system for a DE easily caused circular dependency problems and didn't even clearly provide an up-to-date method on how to fix it; my issue with Gentoo in general is with the wiki seemingly never being up-to-date on how to prevent or solve problems, which is shocking to me considering how dense of a collection of information it is

The other thing... I generally don't have good experiences with trying to get distro wiki's updated; it tends to turn into changes being taken down arbitrarily