[solved] stuck in boot, journalctl says xorg timeouts

washedupplayz · 2025-05-08 18:14:25

Hey guys I'm using a Gigabyte G5 KF5-H3DE554KH with RTX 4060 mobile and i7-13620H. I have KDE Plasma with sddm installed, nvidia-dkms proprietary drivers and everything up-to-date. I should also note that I run dual boot with Windows 11 and Grub. And it DID work, but with the first installation I was stuck in boot with Xorg and I think udev timeouts. This occured only every second or third boot at that time. After that I wiped the linux partitions and reinstalled arch, now this occures every time I try and I can't get into my system at all. I can go into tty though and look at the journalctl. I can also show you the journalctl logs if you tell me how to copy them here without typing them by hand. If you need more information or if I should look after certain log messages/errors let me know!

Last edited by washedupplayz (2025-05-10 08:17:47)

seth · 2025-05-08 21:20:44

I run dual boot with Windows 11

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

I can't get into my system at all.

2nd link below, boot the multi-user.target

if you tell me how to copy them here without typing them by hand

1st link below…

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Also please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

washedupplayz · 2025-05-09 12:50:16

Hey Seth, thank you for your answer!

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Done.

I also got the Xorg and journalctl logs now but can I just make them public or are there things I should censor like ip or mac adresses? I don‘t have any privat information on that system though.

seth · 2025-05-09 13:31:13

On rare occasion you might find a publically routable IPv6 in the journal (though that's not common)
LAN IPs are meaningless outside the LAN and so are your MACs outside physical radio range (the latter make the system trackable if you post them across the internet, ie. one can link the posts to the same individual but that's it)
The xorg log should™ absolutely not contain any private information (beyond the hostname which can be embarrassing but isn't sensitive unless it's also your SSN) whatsoever.
Everything you post can be used for fingerprinting, up to basic language patterns.

washedupplayz · 2025-05-09 13:50:11

Ok well, it can't be that bad.
Journalctl: https://0x0.st/s/7Db_wx_HjACBtBkHZjjAKA/8JD5.log
Xorg: https://0x0.st/s/aF0yiRn6_eQKbWnfpJGRqQ/8JDC.0.log

seth · 2025-05-09 18:46:48

OMG you totally posted your entire porn library !!!11!!1

If you want to use iwd w/ NM, see https://wiki.archlinux.org/title/Networ … Fi_backend - do not explcitly run an iwd service.

ibt=off nomodeset

ift=off isn't necessary since years and nomodeset will not work for sure - why is that there? (It's not in the journal, though)

Then there's

May 09 13:38:17 archlinux kernel: task:(udev-worker)   state:D stack:0     pid:489   tgid:489   ppid:447    task_flags:0x400140 flags:0x00004006
May 09 13:38:17 archlinux kernel: task:Xorg.wrap       state:D stack:0     pid:710   tgid:710   ppid:706    task_flags:0x400100 flags:0x00000002
May 09 13:40:20 archlinux kernel: task:(udev-worker)   state:D stack:0     pid:489   tgid:489   ppid:447    task_flags:0x400140 flags:0x00004006
May 09 13:40:20 archlinux kernel: task:Xorg.wrap       state:D stack:0     pid:710   tgid:710   ppid:706    task_flags:0x400100 flags:0x00000002
May 09 13:42:23 archlinux kernel: task:(udev-worker)   state:D stack:0     pid:489   tgid:489   ppid:447    task_flags:0x400140 flags:0x00004006
May 09 13:42:23 archlinux kernel: task:Xorg.wrap       state:D stack:0     pid:710   tgid:710   ppid:706    task_flags:0x400100 flags:0x00000002
May 09 13:44:26 archlinux kernel: task:(udev-worker)   state:D stack:0     pid:489   tgid:489   ppid:447    task_flags:0x400140 flags:0x00004006
May 09 13:44:26 archlinux kernel: task:Xorg.wrap       state:D stack:0     pid:710   tgid:710   ppid:706    task_flags:0x400100 flags:0x00000002
May 09 13:46:29 archlinux kernel: task:(udev-worker)   state:D stack:0     pid:489   tgid:489   ppid:447    task_flags:0x400140 flags:0x00004006
May 09 13:46:29 archlinux kernel: task:Xorg.wrap       state:D stack:0     pid:710   tgid:710   ppid:706    task_flags:0x400100 flags:0x00000002

May 09 13:38:17 archlinux kernel:  rm_init_adapter+0xcd/0xf0 [nvidia 23e13429acb1b6dee14224eddd4613d8f3d0f9d6]
May 09 13:40:20 archlinux kernel:  rm_init_adapter+0xcd/0xf0 [nvidia 23e13429acb1b6dee14224eddd4613d8f3d0f9d6]
May 09 13:42:23 archlinux kernel:  rm_init_adapter+0xcd/0xf0 [nvidia 23e13429acb1b6dee14224eddd4613d8f3d0f9d6]
May 09 13:44:26 archlinux kernel:  rm_init_adapter+0xcd/0xf0 [nvidia 23e13429acb1b6dee14224eddd4613d8f3d0f9d6]
May 09 13:46:29 archlinux kernel:  rm_init_adapter+0xcd/0xf0 [nvidia 23e13429acb1b6dee14224eddd4613d8f3d0f9d6]

The nvidia GPU doesn't respond and that's probably the core issue here.
Try to add "nvidia.NVreg_EnableGpuFirmware=0" (this will not work w/ nvidia-open, in case you intend to try)

But

May 09 13:34:15 archlinux systemd[1]: Reached target Graphical Interface.
…
May 09 13:34:15 archlinux sddm[706]: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_uvPlSx -noreset -displayfd 16
…
May 09 13:38:17 archlinux kernel: INFO: task (udev-worker):489 blocked for more than 122 seconds.
May 09 13:38:17 archlinux kernel:       Tainted: P           OE      6.14.5-arch1-1 #1
May 09 13:38:17 archlinux kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

this is also 4 minutes after reaching the graphical target?

Do you fail to start SDDM or fail to login from there?
Also

May 09 13:35:13 archlinux systemd-udevd[447]: 0000:01:00.0: Worker [489] processing SEQNUM=3731 is taking a long time
May 09 13:37:16 archlinux iwd[803]: udev interface=wlan0 ifindex=4
May 09 13:37:23 archlinux systemd-udevd[447]: 0000:01:00.0: Worker [489] processing SEQNUM=3731 k

did you add any custom udev rule (eg. wrt RTD3)?

washedupplayz · 2025-05-09 20:37:20

ift=off isn't necessary since years and nomodeset will not work for sure - why is that there? (It's not in the journal, though)

just tried that, didn‘t have it before

The nvidia GPU doesn't respond and that's probably the core issue here.
Try to add "nvidia.NVreg_EnableGpuFirmware=0" (this will not work w/ nvidia-open, in case you intend to try)

This actually worked, sddm seems to work fine now, but this isn‘t a permanent fix, is it?

this is also 4 minutes after reaching the graphical target?
Do you fail to start SDDM or fail to login from there?

Sddm did not start, boot stopped after OK Reached graphical Interface. Sddm also couldn‘t terminate when I tried to reboot via tty.

did you add any custom udev rule (eg. wrt RTD3)?

nope

OMG you totally posted your entire porn library !!!11!!1

you‘re welcome xD

Last edited by washedupplayz (2025-05-09 20:37:40)

seth · 2025-05-09 21:05:17

This actually worked, sddm seems to work fine now, but this isn‘t a permanent fix, is it?

GSP is mandatory for nvidia-open, it is for the time being not necessary for the binary driver.
I *guess* nvidia plans to use this to one day abandon the binary only driver and move nivida-open into the linux tree, but that's guessing the distant future.
Right now there're no repercussions - you're basically using the system as was default like a year ago.

You could occasionally check in whether nvidia fixed their firmware.

washedupplayz · 2025-05-09 22:10:02

Well I guess this fixed my issue then, thank you so much! What was the problem with GSP though?

seth · 2025-05-10 07:07:09

It broke the GPU initialization
The gist is that nvidia is shifting functionality from the driver into the GPU in order to provide an OSS driver w/o revealing all the stolen cod… too many secrets.
This is known to cause problems notably w/ older generations of GPUs and is of course a complete black box.

You could alternatively try whether "rcutree.gp_init_delay=1" helps, but I'd not hold my breath.

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2025-05-08 18:14:25

[solved] stuck in boot, journalctl says xorg timeouts

#2 2025-05-08 21:20:44

Re: [solved] stuck in boot, journalctl says xorg timeouts

#3 2025-05-09 12:50:16

Re: [solved] stuck in boot, journalctl says xorg timeouts

#4 2025-05-09 13:31:13

Re: [solved] stuck in boot, journalctl says xorg timeouts

#5 2025-05-09 13:50:11

Re: [solved] stuck in boot, journalctl says xorg timeouts

#6 2025-05-09 18:46:48

Re: [solved] stuck in boot, journalctl says xorg timeouts

#7 2025-05-09 20:37:20

Re: [solved] stuck in boot, journalctl says xorg timeouts

#8 2025-05-09 21:05:17

Re: [solved] stuck in boot, journalctl says xorg timeouts

#9 2025-05-09 22:10:02

Re: [solved] stuck in boot, journalctl says xorg timeouts

#10 2025-05-10 07:07:09

Re: [solved] stuck in boot, journalctl says xorg timeouts

Board footer