System freezes on boot (tty1)

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @felixonmars, @toolybird, and @gromit

changed the description

added scopebug statusconfirmed labels and removed statusunconfirmed label

assigned to @svenstaro, @daurnimator, and @dbermond and unassigned @freswa, @toolybird, and @gromit

Do you have early kms enabled in mkinitcpio? What is your /etc/mkinitcpio.conf?

Only change is my hooks array: HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)

If you enable these options via /etc/modprobe.d/nvidia.conf with the following content

options nvidia_drm modeset=1 fbdev=1

Will the system boot normally? Also after running sudo mkinitcpio -P

This did not fix it. Even after removing my getty service changes the screen freezes at the login prompt then.

I noticed a different thing tho.

After testing your suggestion, I chrooted, downgraded the nvidia packages again, started to boot and again got the freeze, WITH the downgraded packages. I tested it twice. I then chrooted again and deleted the nvidia.conf and from there it booted normally again. So having set options nvidia_drm modeset=1 fbdev=1 with the old packages has the same freezing effect that I get with the new packages.

So, this does even happen, when you enable on your own modeset/fbdev.

Generally I would suggest you to do here a bugreport to NVIDIA. Ive get in contact with a friend with a 960 and they can not reproduce this issue, while using it with i3 and KDE.

If you use the new package, and create in /etc/modprobe.d/nvidia.conf your previous values? Not sure what youve used before, but you can disable them with: options nvidia_drm modeset=0 fbdev=0

Thanks for testing.
I don't have/had a /etc/modprobe.d/nvidia.conf before, so not sure what the default is. Is your friend using one? Since that seems to have an effect. As I said, if I enable modeset and fbdev it doesn't even work with the old packages. So maybe the new driver somehow enables it? What exactly did your friend test? Are you suggesting to try to disable it and it might work with the new package as well?

Yes, correct the new driver does enable modset and fbdev as default. These are more or less requirements, when you want to use a wayland session, otherwise it wont work.

Before the 6.11 Kernel, there was a workaround in the kerne, which would skip simplefb, if drm.modset=1 is set via the kernel cmdline, but this one got removed and we want to follow there the Fedora attempt, which were committed in the recent change.

If you install the extra-testing/nvidia-utils and add following into /etc/modprobe.d/nvidia.conf: options nvidia_drm modeset=0 fbdev=0

Does it work then?

I think this is an issue related to Early KMS. You can try using these options again, but add MODULES=(nvidia nvidia_drm nvidia_modeset nvidia_uvm) in /etc/mkinitcpio.conf. I'm sure the issue will go away after that, but the question is how to package this.

Fedora's dracut setup makes this automatically, yep

ok, I did some more testing. With options nvidia_drm modeset=0 fbdev=0 it works.

@ventureo Funny you mention that I was already trying exactly that after reading this
Unfortunately it doesn't work for me. I tried adding the kernel parameters directly like nvidia_drm.modeset=1 nvidia_drm.fbdev=1 and also adding them to /etc/modprobe.d/nvidia.conf. In both cases my system freezes immediately after I select the entry in the uefi boot menu just showing running early hook [udev]. So it freezes a lot sooner as before. And yes I did sudo mkinitcpio -P, the image got three times as big as a result. Not sure why that's not working for me.

Unfortunately it doesn't work for me. I tried adding the kernel parameters directly like nvidia_drm.modeset=1 nvidia_drm.fbdev=1 and also adding them to /etc/modprobe.d/nvidia.conf. In both cases my system freezes immediately after I select the entry in the uefi boot menu just showing running early hook [udev]. So it freezes a lot sooner as before. And yes I did sudo mkinitcpio -P, the image got three times as big as a result. Not sure why that's not working for me.

It's a little frustrating Could you please try what I recommended you earlier, but without the fbdev=1?

Yeah tell me about it. I have to chroot every time to make changes.
What exactly do you want me to try MODULES=(nvidia nvidia_drm nvidia_modeset nvidia_uvm) in /etc/mkinitcpio.conf and options nvidia_drm modeset=1 in /etc/modprobe.d/nvidia.conf? fbdev=0 or completely removed?

fbdev=0 or completely removed?

Yes, and you can try not specifying modules in /etc/mkinitcpio.conf

All with the new drivers. (560.35.03-5)

mkinitcpio.conf	nvidia.conf	status
()	modeset=1 fbdev=0	works
()	modeset=1	doesn't work
(nvidia nvidia_drm nvidia_modeset nvidia_uvm)	modeset=1 fbdev=0	works
(nvidia nvidia_drm nvidia_modeset nvidia_uvm)	modeset=1	doesn't work
(nvidia nvidia_drm nvidia_modeset nvidia_uvm)	modeset=1 fbdev=1	doesn't work

Did these test just now.
One thing I noticed. You HAVE TO sudo mkinitcpio -P after every change in /etc/modprobe.d/nvidia.conf. I thought these values were read during boot but apparently not.

So, its an issue as soon fbdev gets enabled.

I dont know, how we want to proceed here then. Currently with 6.11 and fbdev disabled breaks for all users the login, since simplefb takes over and breaks the nvidia driver.

@svenstaro What do you think?

Let's hear what nvidia have to say about this.

@sxe Sorry to bother you again, but could you put back fbdev=1 and add initcall_blacklist=sysfb_init to your bootloader parameters temporarily?

Sure, happy to help getting to the root of this!

mkinitcpio.conf	nvidia.conf	kernel	status
()	modeset=1 fbdev=1	initcall_blacklist=sysfb_init	doesn't work

Unfortunately it still freezes. Here is my full kernel rw loglevel=3 nvme_core.default_ps_max_latency_us=0 nowatchdog modprobe.blacklist=iTCO_wdt initcall_blacklist=sysfb_init in case something might interfere.

Which GPU you got?

I have a NVIDIA GeForce GTX 980 I will test with @ventureo suggestions now. Hope it works since it's a major pita to revert my system since I have to chroot every time.

changed the description

Ok, so far the executive summary appears to be:

with kernel linux-6.11 Arch dropped the "skip simpledrm if nvidia-drm.modeset=1 is set" patch because upstream Fedora already did the same.
this had the knock-on effect of breaking Wayland setups which now need fbdev=1 to get them working again.
Arch has forged ahead and changed the defaults (like Fedora) to make it generally more compatible with kernel linux-6.11 i.e. modeset=1 and fbdev=1
for as yet unexplained reasons, fbdev=1 seems to cause some folks to lose access to the Linux console (TTY devices) (forum link)

If it only affects a minority of folks, then maybe those folks will just have to adapt and boot with fbdev=0? Either via Kernel parameters or Using files in /etc/modprobe.d/.

Update the docs. Job done? Probably not yet..

It will be interesting to see what reports we get when the latest changes are promoted out of [testing].

Similar to the OP, I can no longer boot my system (GTX 1050 Ti) into even multi-user.target or rescue.target after the 560.35.03-5 fbdev=1 change.

I was able to boot with this combo:

mkinitcpio.conf	nvidia.conf	status
(nvidia nvidia_drm nvidia_modeset nvidia_uvm)	modeset=0 fbdev=0	works

Downgraded back to 560.35.03-2, as I'm still affected by #13 (closed) also.

Maybe lets add to the wiki an info related to 10xx series.

Oops, typo. The working combo allowing me to boot into multi-user.target to fix/downgrade was:

nvidia_drm.modeset=0 nvidia_drm.fbdev=0

Edited my comment above.

Enabling the early-loading kms hook in /etc/mkinitcpio.conf was a panacea for me it seems.

Now able to boot successfully appending nvidia_drm.modeset=1 nvidia_drm.fbdev=0 to kernel params.

Verified 560.35.03-5 functional with kernels 6.11.2, 6.10.13 (custom), and 6.6.54 LTS.

Interesting. Perhaps it would be prudent then to close this and document this eventuality in the wiki instead? Could you do that?

Hmm, with only having my own system to go by I'm not confident to say whether early KMS must be enabled, or nvidia_drm.fbdev=0 kernel param required, for various other nVidia setups.

For our similar generation of hardware @sxe and I are using different combos of settings. Not sure if he's got the early KMS hook. And, I use kernel parameters rather than nvidia.conf, hence I don't need to use initcall_blacklist=sysfb_init to block the simple-drm device, as the nvidia_drm.modeset=1 kernel parameter prevents it in combo with the Arch kernel patch.

So, even with just two users here in this thread, with similar hardware, we don't have true commonality on what works for both.

Why don't we have true commonality? As far as I can see the same combo works for both of us? I am currently using The first version in this table: #16 (comment 213813) which is the version you are also using?

Why don't we have true commonality?

Well, for the differences I just stated

Do you use the early kms hook?

Have you tried doing away with nvidia.conf entirely and relying solely on the kernel parameters?

You would not need initcall_blacklist=sysfb_init in that case.

Well, I don't see a difference that's why I am confused. As stated here #16 (comment 213769) yes I use the early kms hook. Yes as stated before I tried with just kernel parameters, exact same behavior as the results from the table. I also normally don't use the initcall_blacklist=sysfb_init kernel parameter, it was just a test I did today since @ventureo asked me to. So from what I can see the same combo modeset=1 fbdev=0 works for both of us.

As stated here #16 (comment 213769)

Ah, I missed that.

Yes as stated before I tried with just kernel parameters

Gotcha. You're last "config" chart from a few hours ago still showed nvidia.conf rather than kernel params so it wasn't clear to me.

Okay, so now that we're on the same page, what would the proposed Wiki entry/modification consist of?

Early KMS hook requirement?
nvidia_drm.fbdev=0?

For either, would it/they be globally advised for nVidia or for our specific generation of hardware?

Anecdotally, I stay current on Arch Forums, and haven't seen much in the way of complaint about this specific packaging change other than that KDE/plasma users needed to specify the opposite (nvidia_drm.fbdev=1 kernel param) to achieve functionality.

FWIW, we got our first customer (that I've noticed) on the forum with similar hardware facing this issue.

Same workaround (early KMS hook + nvidia_drm.fbdev=0) worked for that user as well:

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

As for a wiki note, it would be great if we could determine the range of GPUs requiring this workaround. So far we have Maxwell and Pascal.

Coincidentally, Pascal is the last generation to not be supported by the new open modules.

EDIT: and another (https://bbs.archlinux.org/viewtopic.php?id=300223)

I also was unable to boot unless nvidia_drm.fbdev=0 and I have a GP104 [GeForce GTX 1080] (rev a1)

Lets wait for the upcoming driver. Maybe NVIDIa has fixed the issue.

assigned to @ptr1337

I can confirm that I was affected, but it resolved after creating the config (it did not exist before):

$ cat /etc/modprobe.d/nvidia.conf 
options nvidia_drm modeset=0 fbdev=0

My GPU is a GeForce GTX 1070:

$ sudo lshw -C display
  *-display                 
       description: VGA compatible controller
       product: GP104 [GeForce GTX 1070]
       vendor: NVIDIA Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       logical name: /dev/fb0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=nvidia latency=0 resolution=1024,768
       resources: irq:56 memory:fd000000-fdffffff memory:c0000000-cfffffff memory:d0000000-d1ffffff ioport:e000(size=128) memory:c0000-dffff

I think the problem appears to be something with simplefb and fbdev.

On CachyOS we have simplefb as default disabled, and we got none of these reports. If you remove these again, and add nvidia-drm.modeset=1 to the kernel cmdline, does that fix this?

This should skip SimpleFB on its own and then fbdev should work fine. Give it a try please.

Reading all of this, I'm not sure we can actually consider this a packaging problem. After all fbdev seems to be pretty much required now with the new drivers so we have to default to it for users. I suggest this:

Document this potential problem on the wiki
Make sure nvidia is aware (and ideally post your report on their forums here in this issue)
Close this issue

What do you think?

I don't think this an Arch packaging issue, but rather an nVidia driver support issue affecting older generation cards.

I agree with all of these steps. I missed your comment here previously.

Ok. Could you document this on the wiki please and report back? We can then close those issue.

Make sure nvidia is aware (and ideally post your report on their forums here in this issue)

Regarding this item, I had mentioned in linux#94 (comment 227881) that, for each recent nVidia driver version, I've been updating the most relevant thread in the nVidia forum I could find:

Nvidia driver isn’t compatible with simpledrm so boot output and TTYs are blank

@rrameshbabu What do you make of this? I think there's some strong info in this issue to work with.

I am going to see if I can create repro (or see if someone from our bug triaging group has a repro already). Based on comments here, it seems related to our DRM fbdev support at first glance.

@sxe Could you please retest with the 565 driver in extra-testing?

Unfortunately it's not working. I removed /etc/modprobe.d/nvidia.conf and tty1 still freezes.
Is there any benefit to test the other variations as well? (Don't have much time today for reboots).

Its fine. I just wanted to know, if it is fixed in 565.

mentioned in issue nvidia#10 (closed)

mentioned in issue linux#94 (closed)

mentioned in issue linux-zen#8 (closed)

To those experiencing this: Could you check 570 series from testing?

Exactly zero change in behaviors with 570.86.16-1.

For older generation GPUs (<= Pascal), nvidia_drm.fbdev=0 kernel parameter is still required to have a functional TTY, see the full boot text, and avoid the 'freeze'.

And, nvidia_drm.modeset=1is required as a kernel parameter to avoid the simpledrm device creation (with the patched Arch kernel).

System freezes on boot (tty1)

Description:

Additional info:

Steps to reproduce:

Child items 0

Activity

Admin message

System freezes on boot (tty1)

Description:

Additional info:

Steps to reproduce:

Activity