You are not logged in.
System locks up on GNOME login, dmesg full of stack trace prints related with Nouveau, login eventually fails
[Since when]
This started happening since a system update a week ago.
[The problem comes up when]
When I attempt a Gnome login, but not always.
After a reboot (non-cold boot) it seems to have a better chance at login. Without a reboot, I'm not sure if it always fails after a failed login attempt, but it seems so.
It might be just a matter of pure luck.
`nomodeset` on kernel cmdline doesn't seem to help
(I just found out the system also could lock up on tty switch )
[When it happens]
It usually locks up for a few minutes (where a minute means 60s) [EDIT1: and then fail], and sometimes it succeeds [EDIT1: without locking up].
Sometimes, in the middle of the lockup, the screen goes blank with unblinking cursor on top left side.
Oftentimes, after a failed login attempt, reboot also locks up.
What I mean by "lock up" here is that only MagicSysRq seems to work. It doesn't seem to respond to anything else. No mouse movement, No fast repeated Ctrl+Alt+Del, No Ctrl+Alt+F(n), No Caps Lock LED toggle.
[Probing]
Dmesg is filled up with seemingly repeated stack traces related to Nouveau, and then Gnome (iirc) gets killed due to taking too long to start.
Here is the dmesg, starting from the start of GDM, cut short to fit into Pastebin: https://pastebin.com/MLdNDw33
[Additional info]
System: Asus Zenbook q407iq, Ryzen 5 4500u, Nvidia MX350
P.S. By the way, does Caps Lock LED blinking mean anything? My laptop in the locked up state started doing that while I'm writing this on my phone. SysRq didn't work this time.
EDIT1: clarify about login fail/succeed in [When it happens]
Last edited by freaxtux (2024-02-09 01:17:01)
Offline
P.S. By the way, does Caps Lock LED blinking mean anything? My laptop in the locked up state started doing that while I'm writing this on my phone. SysRq didn't work this time.
Er, yes....
https://wiki.archlinux.org/title/kernel#Kernel_panics
It's a bad thing.
Edit: Check you journal at the point when that happened.
Last edited by ewaller (2024-01-20 01:51:37)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I seem to be experiencing something similar. Nvidia GTX 750 Ti passed through to a KVM/QEMU VM. This setup has worked flawlessly on Nouveau for ages. Currently seems more stable on the proprietary drivers! I suspect latest 6.7 kernel is playing a role here, but not sure yet...
Offline
freaxtux wrote:P.S. By the way, does Caps Lock LED blinking mean anything? My laptop in the locked up state started doing that while I'm writing this on my phone. SysRq didn't work this time.
Er, yes....
https://wiki.archlinux.org/title/kernel#Kernel_panicsIt's a bad thing.
Edit: Check you journal at the point when that happened.
Oh, I guess I've seen that before, though it was long time ago...
I looked into that journal as well, but it just looks like the same Nouveau thing over and over till the end. I guess the panic itself didn't end up getting written.
I seem to be experiencing something similar. Nvidia GTX 750 Ti passed through to a KVM/QEMU VM. This setup has worked flawlessly on Nouveau for ages. Currently seems more stable on the proprietary drivers! I suspect latest 6.7 kernel is playing a role here, but not sure yet...
I'll take a look with nvidia too, thanks for the suggestion. Though, in my case, the Nvidia is the secondary card as in Optimus way, so I'm not sure how it's going to work out.
Offline
I haven't tried the proprietary driver yet, but it seems like you can log in every time (technically, half of the time) if you boot normally first, and then reboot with nomodeset option. Cold boot into nomodeset doesn't seem to work, but either proper reboot or MagicSysRq reboot works. IIRC, reboot without nomodeset doesn't work.
Last edited by freaxtux (2024-01-23 00:31:14)
Offline
The kernel update to 6.7.1 didn't fix it, installing the proprietary driver (`nvidia`) worked.
Do we count this as "solved"? I kinda want to use nouveau if possible...
Last edited by freaxtux (2024-01-24 22:05:49)
Offline
I have the same issue with NVIDIA 2070 super
only in kernel 6.7 and 6.7.1 and it related to Nouveau
blocking the driver fix it for me
install nouveau /bin/true
I,m on kde and don't think DE have any thing with this bug
Its annoying hope it get fixed in next releases
rip nouveau lol
Offline
Just updated from kernel 6.6.10 -> 6.7.1 on my laptop (a Dell Precision 5560 w/ Intel+NVIDIA hybrid graphics) and started running into issues where my system would seem to lock up before I was able to get logged in. I saw a couple different behaviors here:
GDM would not appear to start; I'd see a single underscore in the top-left corner of my screen (not blinking, just frozen).
GDM would freeze on a gray screen, with the mouse cursor frozen, as well.
A login attempt could be made, but the DE would freeze after the login succeeds.
In any of the above scenarios, attempting to switch to a different VT would do nothing.
I'm no stranger to total system lockups, so I started to hold the power button on my laptop down to forcefully power it off (have to hold for ~10s), but to my surprise, I saw systemd's shutdown sequence happen.
Fortunately, I keep linux-lts around (currently at version 6.6.13), and after booting into that kernel, I am not seeing any issues whatsoever.
After booting, I was able to take a look at logs and grab the stack trace that was happening with linux-6.7.1: https://pastebin.com/yLY6PeZN
Doing a bit of digging, I came across this open issue on the nouveau repo: Issue #314: kernel 6.7.1 freezes the system by moving the mouse in graphical desktop (found problem) (via: gitlab.freedesktop.org).
The reporter of the linked bug went the extra mile and built the 6.7.1 kernel without the problematic commit (via: git.kernel.org), and it seems to have solved his problem.
I won't go as far as they did, since I'm lazy and linux-lts is working just fine for my purposes, but I'm reasonably sure that this may be (at least part of) the issue, since some of the verbiage in the panic I recovered from my own logs kinda matches up.
Hope this helps anyone else coming across the issue.
Last edited by hyperbit (2024-01-26 20:10:42)
Offline
That "problematic commit" was partially reverted [1] by the Arch PM in 6.7.2 (currently in [core-testing]). I'm getting mixed results while testing. On the one hand, I was firstly seeing boot fails with screen-fulls of kernel crash logs. On the other hand, when it does boot successfully, it seems better and I can get to a GNOME desktop.. which I couldn't do reliably under 6.7.0 or 6.7.1. It seems upstream devs still have a bit to go yet before we get back to a stable nouveau driver.
Offline
6.7.2 fixed the issue for me, hope does it for you guys too
tested on vm gpu passed
Offline
6.7.3 finally fixed most of the stability / reliability issues I was facing with my passthrough setup (finger crossed).
Offline
I could confirm nouveau works on 6.7.4. Marking it as SOLVED.
Offline