You are not logged in.
Yesterday I booted with the kernel parameters you mentioned earlier (nvidia_drm.modeset=1 nvidia_drm.fbdev=0) and I could not reach the VTs.
Keep those in place in perpetuity until/unless by some miracle nVidia gets the (now-default) fbdev working on Pascal GPUs. Don't hold your breath.
# cat /sys/module/nvidia_drm/parameters/fbdev Y
This is a problem with our 10 series (Pascal gen) cards. Likely causing the problem statement of the thread (no TTY, ui "freeze").
I removed the section of the file with "options nvidia_drm modeset=1 fbdev=1", but I did not regenerate initramfs.
What else is in your /etc/modprobe.d/nvidia.conf?
I no longer require anything that used to belong there and the file no longer exists.
At least regenerate your initramfs without that line you deleted.
Before I regenerate the initramfs can you tell me if you made any changes in the default "mkinitcpio.conf"?
Sure:
$ diff -u /etc/mkinitcpio.conf.original /etc/mkinitcpio.conf
--- /etc/mkinitcpio.conf.original 2024-05-03 09:38:17.000000000 -0400
+++ /etc/mkinitcpio.conf 2025-04-23 08:53:30.740778524 -0400
@@ -4,7 +4,7 @@
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(usbhid xhci_hcd)
-MODULES=()
+MODULES=(vfat ext4 nvidia nvidia_modeset nvidia_uvm nvidia_drm)
# BINARIES
# This setting includes any additional binaries a given user may
@@ -52,7 +52,7 @@
#
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr and fsck hooks.
-HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)
+HOOKS=(systemd autodetect microcode modconf keyboard block mdadm_udev fsck)
# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compressionNote, only the addition of the nVidia modules is relevant here.
Offline
What else is in your /etc/modprobe.d/nvidia.conf?
/etc/modprobe.d/nvidia.conf:
blacklist nouveauI see that you do not have the "kms"-hook which is present in the default "/etc/mkinitcpio.conf" and which I deleted when I modified "/etc/modprobe.d/nvidia.conf". Isn't that important?
Finally, can you tell which WM/desktop do you use and whether you use Wayland or Xorg? And do you use other kernel parameters apart from "nvidia_drm.modeset=1 nvidia_drm.fbdev=0"?
Yesterday you were still using the troublesome lightdm greeter, did you?
Tried after fixing that?
Yes and it's not working because I did not change anything: neither kernel parameters nor initramfs. Let me see after I rebuild initramfs and change kernel parameters in grub.
Last edited by tethys (2025-04-27 18:57:48)
Offline
/etc/modprobe.d/nvidia.conf: blacklist nouveauI see that you do not have the "kms"-hook which is present in the default "/etc/mkinitcpio.conf" and which I deleted when I modified "/etc/modprobe.d/nvidia.conf". Isn't that important?
The answers are right in the very first paragraph of the nVidia wiki page, which you claimed to have read and confirmed all good:
• https://wiki.archlinux.org/title/NVIDIA
Remove kms from the HOOKS array in /etc/mkinitcpio.conf and regenerate the initramfs. This will prevent the initramfs from containing the nouveau module making sure the kernel cannot load it during early boot. The nvidia-utils package contains a file which blacklists the nouveau module once you reboot.
1) Leaving the KMS hook in is unlikely to cause an issue, but it does bloat your initramfs image by ~50-ish MB. Remove it if you've no intention of using the Nouveau driver.
2) As mentioned previously, delete /etc/modprobe.d/nvidia.conf and rebuild your initramfs.
Finally, can you tell which WM/desktop do you use and whether you use Wayland or Xorg?
And do you use other kernel parameters apart from "nvidia_drm.modeset=1 nvidia_drm.fbdev=0"?
Gnome + (Pure) Wayland, specifically my own package builds as detailed here:
• https://bbs.archlinux.org/viewtopic.php … 6#p2232996
I build my kernel with CONFIG_SYSFB_SIMPLEFB=n (rendering nvidia_drm.modeset=1 (which YOU NEED) irrelevant in my case), and my kernel parameters are simply:
$ cat /proc/cmdline
initrd=\initramfs-linux-stable-mfm.img root=UUID=d475ae3e-f8c5-4e02-9c23-541d4667d78e rw nvidia_drm.fbdev=0Last edited by tekstryder (2025-04-27 20:13:02)
Offline
So, after rebuilding initramfs and rebooting with kernel parameters "nvidia_drm.modeset=1 nvidia_drm.fbdev=0" no change. That is, I cannot reach VTs from Gnome but I can from Openbox. I had no nvidia.conf and no "kms" hook. Also this time:
# cat /sys/module/nvidia_drm/parameters/fbdev
NThe answers are right in the very first paragraph of the nVidia wiki page, which you claimed to have read and confirmed all good
I read that but I just asked about the relevance of the "kms" hook to the problem of this topic, not nouveau!
One more thing, I do not want to open a new topic for this matter. Can you tell me how you get links to certain posts in a topic, like the one you provided in the previous post (https://bbs.archlinux.org/viewtopic.php … 6#p2232996)?
Offline
And with GDM?
Datetime of post is the link.
EDIT: And if TTYs are still unavailable using GDM, please post an updated full system journal of that boot after trying to access a TTY.
Last edited by tekstryder (2025-04-28 11:20:03)
Offline
Can you tell me how you get links to certain posts in a topic
The date above the post is a link.
You might want to try GDM+gnome on wayland or alternatively (for good measure) openbox+picom (you'll have to actively select the GLX backend)
rn all we know it that there's no issues w/ openbox/X11 but there are w/ gdm/X11
Edit: the last link would then probably be vulkan - though idg why X11 AND the cnosole get input events when this fails w/ gnome ![]()
Last edited by seth (2025-04-28 14:23:11)
Offline
And with GDM?
As i mentioned already, this is my homeoffice computer and I do not know when I will find time to test GDM. I also have to see first what are the "unintended consequences" of installing gdm as compared to lightdm.
You might want to try GDM+gnome on wayland or alternatively openbox+picom
Yes, I will setup when I find time openbox with picom. It's not a bad ideea to have a second functional desktop besides gnome, just in case. As for wayland I don't think I want to adopt it for now.
One thing I do not quite understand. The VTs work on my laptop with same software except gdm (but without nvidia).
1) gdm only plays a role in launching gnome and not when gnome is running (is that actually true? - if true changing to gdm would be moot)
2) from what I understand it is the compositor that is doing the switching to VTs
Then the fact that it's working on the laptop shows that this problem must be related to the combinaton (gnome compositor + nvidia + X11) and what I don't understand is why not many other people noticed it (I could not find any recent posts about this issue although I do not have a special software/hardware).
So it's either some transient software problem (and hopefully this will get solved with the next updates) and if not soon other people will also start noticing it.
I want to thank you both for your help!!! ![]()
Offline
* "without nvidia"
* GDM unlike lightdm will start a second X11 server for the session
* the kernel chances the VT
The visuals are easy to explain, the drm driver fumbles the frambuffer transition (hence tekstryders focus in fbdev which has quite a record on inconsistent performance)
The weird part is the input apparently going to two TTYs…
It's not a bad idea to have a second functional desktop
The plan wasn't to sell you a different DE but to check what impact an (OpenGL) compositor has on the framebuffer situation - you unfortunately cannot disable the gnome one.
Offline
And with GDM?
So, finally I could test GDM and now I can reach the VTs!
So it seems that the cause of the failure to reach the VTs was lightdm.
Offline
but I can from Openbox
* GDM unlike lightdm will start a second X11 server for the session
It's probably somewhere between gnome, the re-used X11 server and nvidia.
Offline
So, finally I could test GDM and now I can reach the VTs!
Hehe, yeah this thread was effectively solved in post #3, but took a little adventuring to get there.
Now... use them TTYs!!
Offline
So as not to necro, nor create a PSA post... I'm choosing the most recent && most concisely-titled thread to provide an update on the nVidia framebuffer situation with older-gen GPUs.
Keep those in place in perpetuity until/unless by some miracle nVidia gets the (now-default) fbdev working on Pascal GPUs. Don't hold your breath.
While it's perfectly viable to use nvidia_drm.modeset=1 nvidia_drm.fbdev=0 kernel parameters as a workaround, the (at least one) root cause of broken nVidia fbdev=1 has been identified.
Details here:
• https://gitlab.archlinux.org/archlinux/ … ote_277488
• nVidia internal bug #4157529
tl;dr: There's an upstream patched kernel module I tested successfully that will land in the 580 series nVidia driver which allows a fully functional nVidia framebuffer, TTYs, boot console text, etc. on older-gen nVidia GPUs.
This should also render moot the need for carrying the simpledrm device suppression patch that's been applied to Arch kernels for nearly 2 years now. The patch will likely be dropped as of the 580 release.
@tethys: I don't see it in the thread, but do you happen to be driving multiple displays off your GTX 1080? If so, do they have different native resolutions?
p.s. This thread belongs under Kernel & Hardware, but not sure if there's any point to moving it now.
Regardless, this is mostly for posterity, heads-up, and info for those folks who frequent these parts but not so much GitLab.
Offline
do you happen to be driving multiple displays off your GTX 1080?
No, just one one monitor.
Thank you for the link & info!
Last edited by tethys (2025-06-14 19:47:47)
Offline