Legacy framebuffer broken since 5.18.13

[muellerjoel]

NVIDIA Open GPU Kernel Modules Version

nvidia-dkms 515.57.10

Does this happen with the proprietary driver (of the same version) as well?

Yes

Operating System and Version

Arch Linux

Kernel Release

Linux 5erver 5.18.15-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 29 Jul 2022 22:52:39 +0000 x86_64 GNU/Linux

Hardware: GPU

GPU 0: NVIDIA GeForce GT 1030 (UUID: GPU-c59b6402-5cbe-7921-cefb-54226fe287f9)

Describe the bug

I can't boot the kernel full in console and login in as user

git clone https://github.com/archlinux/linux.git

git checkout 848b2b6b5a582418eccf9c757594a51dab2b30d0 #5.18.15 kernel

git revert 07186778cf645cc79e6913a28dadf445cd3e2439

resolve the issue

https://bbs.archlinux.org/viewtopic.php?id=278519

To Reproduce

Install ArchLinux with kernel => 5.18.13
Install nvidia drivers
boot in to kernel after cryptsetup password prompt will freeze
Freeze -> you can login over ssh

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

No response

[aritger]

GP108 (pascal) is not supported by the open kernel modules in this git repo. But, if this happens with the proprietary driver, that is definitely a bug.

I can't find much related to the problem in the attached logs. Was the attached nvidia-bug-report.log.gz generated right after the symptom was reproduced? In journalctl, I see:

Jul 31 13:51:53 archlinux kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 234
Jul 31 13:51:53 archlinux kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  515.57  Wed Jun 22 22:44:07 UTC 2022
Jul 31 13:51:53 archlinux kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  515.57  Wed Jun 22 22:31:08 UTC 2022
Jul 31 13:51:53 archlinux kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
Jul 31 13:51:53 archlinux kernel: [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 0
Jul 31 13:51:53 archlinux kernel: nvidia-uvm: Loaded the UVM driver, major device number 510.
[...]
Aug 01 17:18:32 5erver sudo[1113208]:    morta : TTY=pts/0 ; PWD=/tmp/linux ; USER=root ; COMMAND=/usr/bin/nvidia-bug-report.sh

Would it be possible to reboot, reproduce the problem with the proprietary driver, ssh into the system and then run nvidia-bug-report.sh? It would be nice to get a fresh dmesg rig
ht after the repro.

[muellerjoel]

I have upgraded to a custom kernel who runs with this GeForce card but you have a fresh journalctl from me in this thread

https://bbs.archlinux.org/viewtopic.php?id=278519

[loqs]

More information is available in https://bugzilla.kernel.org/show_bug.cgi?id=216303#c2
Since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee7a69aa38d87a3bbced7b8245c732c05ed0c6ec backported to 5.18.13 as https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=07186778cf645cc79e6913a28dadf445cd3e2439 generic framebuffer registration is disabled when any driver asks for a platform device to be unregistered.
The kernel developers suggested the issue could be resolved by the nvidia driver providing an emulated framebuffer which it would register with the drm subsystem.

[aritger]

Thanks, @logs. I've renamed the Issue subject from

Kernel freeze since 5.18.13 with NVIDIA Corporation GP108 [GeForce GT 1030]

to

Legacy framebuffer broken since 5.18.13

[aritger]

Thanks for the report. We're tracking this internally as NVIDIA bug 3740048.

[Elias011980]

I see a different issue (no freeze, but VESA (legacy) frame buffer unusable after X has started), due to a commit that went into kernel v5.18.13, so it is likely not NVIDIA driver-version specific, but most likely impacting any version...
Here is the kernel issue (that kernel folks are unwilling to "fix" by reverting the "culprit" commit):
https://bugzilla.kernel.org/show_bug.cgi?id=216303

[aaronp24]

Hi @joel-muller, thanks for reporting this. The NVIDIA driver has traditionally not installed itself as a framebuffer console driver because doing so breaks an important use case: closing all graphical applications, unloading and uninstalling the existing NVIDIA driver, installing a new one, and starting graphics back up without having to reboot. It has not traditionally been a requirement that drm drivers also act as fbdev drivers, so this works out on earlier kernels.

If newer kernels introduce the requirement that drm drivers must install a framebuffer console, then we will look into implementing that.

[YusufKhan-gamedev]

@aaronp24 wouldnt that mean that tty resolution is something absurd like 640x480? Thats a huge dealbreaker!

[aaronp24]

@joel-muller , can you check whether this commit breaks the console even if no NVIDIA driver is installed at all? While trying to reproduce this problem we noticed that the call to sysfb_disable is disabling the framebuffer console on the NVIDIA device when a drm driver for a completely different device (ASPEED in your case, Intel in our internal testing) is loaded, regardless of whether or not a drm driver exists for the NVIDIA device. That seems like a bug: the kernel shouldn't consider the efifb or similar console on an NVIDIA GPU to be conflicting with the PCI resources of a different GPU.

[muellerjoel]

@aaronp24

Ok so I do

sudo pacman -R nvidia-dkms
Remove nvidia nvidia_drm from kernelparmeter

How I remove a self compiled dirty kernel which I installed with make?!

sudo pacman -U linux-5.18.15 linux-headers-
5.18.5 from /var/cache/pacman/pkg/

It‘s ok so?

[muellerjoel]

Its freeze also! Without nvidia modules and removed nvidia-dkms driver

[aaronp24]

Thanks for confirming. We'll continue investigating, but that behavior of the upstream kernel doesn't seem right and sounds like it wasn't intentional.