As of any kernel in the 6.x series, the framebuffer no longer works with nvidia drivers. kernels in the 5.x series works. i.e. there is no output on boot as you'd expect. Reproducible: Always Steps to Reproduce: 1. Install nvidia-drivers. 2. Build 6.x kernel. 3. Reboot. Actual Results: See nothing until X. Expected Results: Boot messages. I have been tracking this here https://github.com/NVIDIA/open-gpu-kernel-modules/issues/458, there is a patch from redhat to fix it which apparently works but not for me. ```
Created attachment 863855 [details, diff] Redhat patch to fix nvidia drivers / efifb Here's their patch.
the only work around I have had work is to comment out the line in aperture.c.
The ebuild already gives a warning to disable SIMPLEDRM, then such patch is not needed.
(In reply to Ionen Wolkens from comment #3) > The ebuild already gives a warning to disable SIMPLEDRM, then such patch is > not needed. (among a few others tips that tend to work, FB_SIMPLE and SYSFB_SIMPLEFB tend to conflict since recent kernels) I'm using FB_EFI just fine myself.
(In reply to Ionen Wolkens from comment #3) > The ebuild already gives a warning to disable SIMPLEDRM, then such patch is > not needed. Also that patch is fedora/redhat specific, it tries to detect nvidia drivers through kernel boot params and then prevents SIMPLEDRM from being used. Meaning it will typically do nothing if not used that way. So (to resume) ensure you have the following disabled in your kernel (or being built as module is fine too): - CONFIG_DRM_SIMPLEDRM - CONFIG_FB_SIMPLE - CONFIG_SYSFB_SIMPLEFB And then check that this one is enabled - CONFIG_FB_EFI (may want FB_VESA too in case we're overlooking something here) Then may want to re-emerge nvidia-drivers and check if it outputs anything warnings. If this does not work, then I don't know. nvidia-drivers itself doesn't provide anything, framebuffer is all from the kernel, so this is a kernel issue. The last resort would be to try to pass nomodeset to the kernel command line.
(In reply to Ionen Wolkens from comment #3) > The ebuild already gives a warning to disable SIMPLEDRM, then such patch is > not needed. You obviously didn't read my entire link, as I stated today on that, that I enabled it to see if that made a difference, it didn't.
(In reply to Luke A. Guest from comment #6) > (In reply to Ionen Wolkens from comment #3) > > The ebuild already gives a warning to disable SIMPLEDRM, then such patch is > > not needed. > > You obviously didn't read my entire link, as I stated today on that, that I > enabled it to see if that made a difference, it didn't. Sorry, I've read that issue before already, so I didn't check the link again for potential new posts (nor do I know if replies are from you from a quick look).
(In reply to Ionen Wolkens from comment #7) > (nor do I know if replies are from you from a quick look). To clarify, I assumed "tracking at" just meant that you were following the bug, not necessarily created it. Either way, I said everything I know may or may not help in comment #5 As noted, nvidia-drivers does /not/ handle framebuffer on any kernel version -- at worst nvidia-drivers may conflict when loaded but it wouldn't stop early boot messages (that's all handled by the kernel).
Created attachment 863867 [details] 6.3.8 kernel config Nope, still nothing shown. $ cat /proc/cmdline BOOT_IMAGE=/@/boot/vmlinuz-6.3.8-gentoo-x86_64 root=/dev/mapper/vg0_ssd-ws_rootfs ro rootflags=subvol=@ dolvm dobtrfs quiet amd_iommu=on iommu=pt hugepages=4608 pci=noats vfio-pci.ids=1002:67df,1002:aaf0,1b73:1100 crashkernel=@128M kgdboc=/dev/ttyS0,11520 module_blacklist=evbug rootfstype=btrfs
Don't know then, as a better than nothing fallback may want to try "nomodeset" boot option. Could be some different kernel regressions affecting your specific hardware, or something else I haven't heard about yet. Nothing that open-gpu-kernel-modules upstream or nvidia-drivers here can do about given they don't handle early boot display.
(In reply to Ionen Wolkens from comment #10) > Nothing that open-gpu-kernel-modules upstream or nvidia-drivers here can do > about given they don't handle early boot display. As I said, this isn't from nvidia-drivers. At best it could be a kernel bug, but well.
