[RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

VetheonGames · 2023-12-13 18:17:52

Hey guys,

Long time since I've posted on the forums here. I can usually stumble my way through just about any problem I have with my machine, but I can't seem to implement any sort of permanent fix for this.

This is probably gonna get super duper technical (I want to provide you guys as much info as possible to hopefully solve this permanently) so buckle up, get ready for the wild ride through everything I've tried already...

So, the start of the problem, and the symptoms:

The Start & The Temp Fix:

So a while back, I noticed it was taking a little bit longer for my desktop to appear when I booted up. This wasn't super worrying at first (as even GnuPG takes a while to start from time to time) so I ignored it. For reference, my system usually takes only a couple seconds to post, a couple seconds to boot, and then a couple more seconds after login to properly bring up my desktop environment and user space. For a total boot time of around 20-30 seconds. I could probably have gotten this faster, but I have a bunch of custom programs and scripts that start on boot, that are admittedly shoddily coded.

Eventually, as kernel updates rolled out, and other kernel modules updated, I noticed boot times were taking longer and longer. Almost like the time it takes to boot was increasing with each time `mkinitcpio` is triggered by a kernel update (I know that's likely not the case and it's some other issue causing the problem, I won't blame the kernel for my own issues, I doubt they'd not notice such an obvious issue, plus nobody else appears to be having the issue that I've been able to find, which means it's just my system)

So digging away I went, and I found a thread here on the Arch Forums about a very similar issues, where a very helpful user who goes by @Seth helped a user resolve it. I followed along with their instructions, but it didn't rectify the problem. Next, I decided to benchmark my boot process, as well as take a peek at the system logs from boot time. In the logs, I didn't find any issues regarding KDE starting (there was some errors being thrown by some KDE module that's meant to manage battery life. I think it was called "Powerdevel"? I have a desktop with no battery, so I doubt that's the problem)

I really couldn't come across anything that would give me an inkling on what the problem could be. So, I reinstalled my kernel, and my nvidia drivers. This rectified the issue, but only until the next kernel update. Reinstalling just Nvidia after that fixed it, until the next Nvidia update. So, I'm stuck in this repeated cycle of having to repeatedly reinstall my kernel every time it updates.

The Symptom:

The symptom is that everything starts off normally, we pass post no issue nice and fast and end up in rEFInd nice and fast. I boot Arch from rEFInd and the actual Arch boot process seems to go fine, no issues there. SDDM comes up on time, and everything there seems normal. But once we pass SDDM and try to actually load into the desktop environment and user session, I get stuck looking at an all black screen for like a solid minute or longer. I can tell that KDE is working to a degree, because my desktop widgets come up as expected, and Solaar/GnuPG start as well.

The problem is, all the GFX are absolutely borked until it figures itself out. Aspect ration is wrong, everything either has screen tears all over it, or it's all squished and blurry.

After about... 40-60 seconds, the desktop environment properly starts, and everything goes back to normal. From there on, it'll preform as expected, as it always does. Until I reboot. Then we start the gambit all over again. Needless to say, this is super obnoxious.

The Details about my system:

So, here's my system hardware:

GPU: NVIDIA GeForce GTX 1060 6GB
CPU: Intel i5-6500 (4) @ 3.600GHz
DE: Plasma 5.27.10
Memory: 23970MiB

Here's my software system versions:

Kernel Version: 6.6.6-arch1-1
Packages: 1527 (pacman), 1 (rpm), 9 (snap)
Shell: zsh 5.9
Nvidia Driver Version: 545.29.06
CUDA version: 12.3
Nvidia-SMI Version: 545.29.06

(If any of that wasn't needed, I apologize)

The Logs:

Now here's the logs from my system, along with a benchmark of my current boot (with the issue) using systemd-analyze

I will note, since this issue has been so enigmatic for me, I've included all the logs with only minimal censoring of sensitive data (mostly networking stuff like my server IPs and stuff). If you need me to, please ask me to run any command to get more specific logs for you.

Boot logs: https://pastebin.com/k3nY07vu
Xorg logs: https://pastebin.com/wG4m8gRE
systemd-analyze blame output: https://pastebin.com/3xR0U1fd
systemd-analyze critical-chain output: https://pastebin.com/zxp9EtRy

As you can see from all these logs, there doesn't APPEAR to be anything wrong... but reality would beg to differ. Any and all help or advice would be much appreciated. Constantly reinstalling Nvidia drivers and my kernel isn't viable forever.

~Vetheon

Edit: I forgot to mention, I've since disabled all my custom stuff at startup (aside from a simple script that sets my HDMI monitor as primary, because it likes to set my Display Port monitor on the far right as primary, which makes my whole DE work right to left, whereas I prefer left to right.

Last edited by VetheonGames (2023-12-17 14:08:07)

seth · 2023-12-13 21:41:23

First off all

[    20.528] (II) xfree86: Adding drm device (/dev/dri/card1)
[    20.528] (II) Platform probe for /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
[    20.529] (II) xfree86: Adding drm device (/dev/dri/card0)
[    20.529] (II) Platform probe for /sys/devices/platform/simple-framebuffer.0/drm/card0
…
[    20.924] (II) modeset(G0): using drv /dev/dri/card0
[    24.086] (==) modeset(G0): Depth 24, (==) framebuffer bpp 32
[    24.086] (==) modeset(G0): RGB weight 888
[    24.086] (==) modeset(G0): Default visual is TrueColor

Enable https://wiki.archlinux.org/title/NVIDIA … de_setting

Dec 13 03:13:27 archlinux kernel: Linux version 6.6.6-arch1-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC Mon, 11 Dec 2023 11:48:23 +0000
…
Dec 13 03:13:35 VethPC kernel: nvidia: loading out-of-tree module taints kernel.
…
Dec 13 03:13:43 VethPC systemd[1]: Started Simple Desktop Display Manager.

it takes you 8 second to just load the nvidia module and a total of 16 seconds to just get to the point where the display server is started.
There're no obvious stalls, everything just moves at glacial pace.

So, I reinstalled my kernel, and my nvidia drivers. This rectified the issue, but only until the next kernel update. Reinstalling just Nvidia after that fixed it, until the next Nvidia update. So, I'm stuck in this repeated cycle of having to repeatedly reinstall my kernel every time it updates.

I suspect this has some side effect, check the CPU frequencies, https://wiki.archlinux.org/title/CPU_fr … _governors and disk performance, https://wiki.archlinux.org/title/Benchmarking#dd

But once we pass SDDM and try to actually load into the desktop environment and user session, I get stuck looking at an all black screen for like a solid minute or longer. I can tell that KDE is working to a degree, because my desktop widgets come up as expected, and Solaar/GnuPG start as well.

That aside,

The problem is, all the GFX are absolutely borked until it figures itself out. Aspect ration is wrong, everything either has screen tears all over it, or it's all squished and blurry.

https://wiki.archlinux.org/title/KDE#Un … lution_set

VetheonGames · 2023-12-13 21:55:31

Hey @seth!

Thanks for all the helpful links, I'm just away from my PC right now, but I'll go through everything you said and report back asap!

VetheonGames · 2023-12-14 08:13:06

Hey @seth,

So, I followed all the links you gave me, and I read through them thoroughly. I followed the guides, and adjusted my configuration as the wiki entries (and you) advised.

I'm glad to say, that the issue with the DE not coming up properly at first, and taking forever to properly render itself on the screen has been resolved (at least so far, it is persisting through several reboots, but until I have a kernel/nvidia update we won't know for sure). It's not NEARLY as lickity split as it was when I first installed Arch on the machine, but it's at least not taking over a minute to actually be able to use the DE anymore, and it's not like it's the greatest thing on earth in terms of hardware lol (I mean, I got this little workstation for $200 CAD after all) So I think I'm pretty content with where things have ended up, and I thank you for the advice and guidance my friend.

In terms of all the benchmarking and CPU frequency, and checking the governor, and also making some more configuration changes of my own, that I learned about just by reading further into the wiki from the starting points you guided me to.

I wrote two little things made just to stress out my processor (with it running the "powersave" governor, which is what it's always been on), in Go and Ruby. Just to have two good metrics

So, at idle it'll be chilling at like... 900 MHz on each core (appx). And I can throw a LOT of math at it to try to stress it (generating 1 million prime numbers, and generating Fibonacci numbers with a bunch of threads), I can see that the processor seems to jump up from 900 MHz, to 3.3(ish) GHz. And it does it basically instantly. So, it's certainly not a frequency issue I wouldn't think (the graphical issue I mean). Seeing as the processor says it can go up to 3.5 GHz (and it's old).

In terms of a disk benchmark, according to the steps outlined in the wiki link you sent, I'm looking at a write speed of 365 MB/s, and a 498 MB/s read speed. Which is about what I would expect out of this drive.

So, I managed to fix several other issues I was having by diving into this rabbit hole of troubleshooting, that I didn't even know I had. On top of hopefully permanently fixing the weird KDE issue.

The particular fix that I think will have it this time, was in the kscreen folder, there was like, 9 different copies of literally the exact same configuration files, but in various different arrangements and stuff. So I deleted those (after backing them up), and rebooted. Now there's only one, and the issue didn't happen (even though I didn't reinstall nvidia). I also enabled DRM, as you suggested, which may have also contributed to the resolution.

So if anyone has this same issue in the future (since I couldn't find any reference to this specific issue), I strongly recommend following the instructions and reading the resources @seth provided.

seth · 2023-12-14 13:50:02

1. Was the journal in your OP not for the "catastrophic" situation, but also mitigated by a driver re-installation? Do you still have a journal for the catastrophic conditions (eg. "… -b -5" for five boots ago)?
2. Do you have an udpated journal for the status quo? No matter how much $200 CAD is in real money, you can expect the system to move faster than that.

VetheonGames · 2023-12-14 21:07:02

All of the original logs that I posted were from my system in a state where it HAD the issue. (Desktop Environment taking forever to actually appear on screen)

The reason I made a post, is because going through my journal, Xorg logs, etc, I wasn't able to find anything that jumped out at me as to why the desktop wouldn't be showing up like it should. I tried repeatedly to troubleshoot the problem, but for the life of me could only ever band-aid the issue by reinstalling my Nvidia drivers, and if that didn't work, completely reinstalling my kernel fixed it (I'm using the standard Arch kernel, since my system wouldn't cooperate with the Zen kernel fsr). Though it would only fix the issue with the Desktop Environment loading until the Nvidia package had an update, or the kernel had an update. Post update, the issue would begin again.

So, generally speaking, I was more concerned about the DE problem (black screen for like a whole minute before my desktop actually loads up) than the time it takes my system to boot. Honestly.

Though, my system does feel a lot faster since making all the config changes, so, just for the sake of brevity here's the output from systemd-analyze from yesterday immediately after I implemented all the changes:

❯ systemd-analyze
Startup finished in 12.197s (firmware) + 1min 55.578s (loader) + 1.103s (kernel) + 2.505s (initrd) + 30.116s (userspace) = 2min 41.501s 
graphical.target reached after 30.116s in userspace.

Like, it's saying it's taking nearly 3 whole minutes to boot. There's NO WAY that's accurate. I mean, it definitely didn't take nearly 3 minutes to boot up.
So, just to be safe, I rebooted again just now, and timed it with a stop watch at each step, follows are the results.

From Total Power Off:

Power Off to rEFInd GUI: 13.27 Seconds
rEFInd GUI to SDDM: 35.40 Seconds (give or take, as I can't press enter instantly to boot Arch)
SDDM to Desktop Environment: 35.01 Seconds
Total Power off to Fully Booted time: 1 Minute, 23.69 Seconds

(give or take, seeing as obviously I'm unable to press my stopwatch instantly either)

The biggest difference is the loader time. Though, I'm unsure if that's measuring how long it takes to reach the boot loader, or how long it takes to PASS the boot loader. I use rEFInd, as I'm sure you know it's graphical boot loader, and I have it hang at the boot loader until I manually choose what kernel to boot into. (I have many portable linux installations, and other OS' that I swap between)

So, if we take the loader time out of the first systemd-analyze, we get a total boot time of 46 Seconds. (2 minutes 41 seconds - 1 minute 55 seconds), which seems much closer to what I actually experienced with that first boot.

That's assuming that it's measuring the time it takes to proceed past the loader. Which I feel like is safe to assume, since in the next time I get much lower loader time out of systemd-analyze (because I hit enter to boot into Arch as soon as the loader appeared)

The systemd-analyze output from this last boot that I timed with a stopwatch:

❯ systemd-analyze
Startup finished in 12.205s (firmware) + 1.153s (loader) + 893ms (kernel) + 2.645s (initrd) + 28.910s (userspace) = 45.808s 
graphical.target reached after 28.769s in userspace.

So, this is MUCH more acceptable. It's still not super duper fast like when I first bought this cheap little workstation, but it's more than fast enough. And I didn't need to reinstall my Nvidia Drivers, or my Kernel to fix it this time, which is why I'm hoping the issue is resolved permanently.

If you want the full blown total logs like I did originally, I can definitely do that for you. I'm always down to learn new things I should do to my system to improve it. But as it stands, my system is preforming way better now, and the strange DE issue isn't happening. So I'm pretty content in the fix I managed to accomplish with your advice.

Here's the actual boot journal from this last boot, since you asked, but I can't pull my boot journal from 5 boots ago, or even anything more than my last boot. My boot logs don't persist for longer than 1 boot at a time. This is default behavior afaik, because I never tinkered with the settings regarding the system journal.

https://pastebin.com/nmeFxb14

I hope this is what you were looking for! If you have any more advice based on the latest boot journal, lemme know!

Edit:

For clarity, the things I changed in my system config are as follows:

1: I changed from the "powersave" governor to the "performance" governor, then back again (dunno if this had an effect, but I did do it)
2: Adding "nvidia_drm.modeset=1 fbdev=1" to my kernel options
3: removed all files from "./.local/share/kscreen"
4: Installed cpupower package (it literally didn't exist on my system, which I needed to mess with the governor)
5: Installed lm_sensors package (it didn't exist either, but I needed it to check thermals after messing with the governor)
6: Rebooted

After all these things, the issue disappeared, for the first time without reinstalling my Nvidia drivers or kernel. So, fingers crossed. But until a Nvidia or kernel update, there's no real way to know for sure if it's fixed for good or not.

Edit the second:

I actually apparently have both a kernel and nvidia update to do right now, so I'm gonna do that, reboot and see what happens. I'll post an update edit after

Edit the final:

Ok! Can confirm, the strange issue with KDE not starting until I stare at a black and glitchy screen for like a minute has been 100% RESOLVED!!

So, I'm very happy about that. No black screen, no screen tears, no flickering, no weird aspect ratio, nothing. Everything works as expected.

Here's the boot logs, and the output of systemd-analyze:

https://pastebin.com/ymtW3y4j

❯ systemd-analyze
Startup finished in 12.243s (firmware) + 712ms (loader) + 904ms (kernel) + 2.021s (initrd) + 26.579s (userspace) = 42.461s 
graphical.target reached after 26.470s in userspace.

And here's systemd-analyze blame:

https://pastebin.com/C7GNyhKi

And here's systemd-analyze critical-chain:

https://pastebin.com/wRkAD6jt

One thing I do notice, is it seems like SDDM is throwing a bunch of warnings/errors when it's doing it's thing. Which probably contributes to my boot times, and I think is coming from my KDE themes. So I don't even know how to go about fixing that other than, ya know, removing all my theme customization...

Last edited by VetheonGames (2023-12-14 21:41:16)

seth · 2023-12-16 15:10:59

Coming back to this, I suspect the slow part is the Timetec ata device (seems some SSD but there're littel google hits on that)

The SDDM warnings are QML errors because QML is like webdevelopment done by poking around until it somehow works… most of the time.
They don't seem critcak, but you might just switch to a different theme.

sda (samsung SSD) is a windows installation?

VetheonGames · 2023-12-16 20:51:09

The Timetec (SDC) device is indeed a crappy Amazon Special SSD. I don't expect much speed out of it.

The Samsung device does indeed hold my Windows installation (because the Samsung SSD is way older than the Timetec one, and I play games on Windows)

So basically, my bootloader is on the Timetec drive, as is my Arch Linux install (just on a separate partition from /boot), and the Samsung SSD runs Windows for me.

I use Windows primarily for games, hence why it gets the nicer SSD. Arch Linux I use exclusively for programming/daily driving (web browsing, emailing, etc), so it's boot times/speed isn't top priority, the amount of R/W ops I have left in the disk is.

But thankfully, your advice helped me solve the problem with my Desktop not loading properly, so thank you a ton for that Seth! I salute you my friend.

If you actually have a minute, I've never tinkered with the nvidia kernel module settings before (I try not to mess with my gfx drivers on Linux after I borked my whole system playing with them once before). What exactly is the drm modeset=1 option that I set? And what does it do?

seth · 2023-12-17 10:24:55

https://wiki.archlinux.org/title/NVIDIA … de_setting has some sublinks that explain DRM and KMS, it also blocks the simpledrm device.

Because of the parallel windows installation, make sure to see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

You can benchmark the timetec against the samsung performance, https://wiki.archlinux.org/title/Benchmarking#hdparm or https://wiki.archlinux.org/title/Benchmarking#dd (be careful w/ dd, if you type something you don't understand you'll at least understand why it's dubbed "diskdestroyer"…) but I'm pretty sure that the glacial pace of the boot is simply because of the low read performance.

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.

VetheonGames · 2023-12-17 14:09:49

Don't worry, I've already disabled windows fast start. It's the first thing I do after I install windows.

I'm not new to Linux by any means, just new to using it as my daily driver. And by new, I mean I've been doing it for like... 2-3 years as my main desktop OS.

Also, I marked the thread as resolved. Thanks again for your help!

Arch Linux

#1 2023-12-13 18:17:52

[RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#2 2023-12-13 21:41:23

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#3 2023-12-13 21:55:31

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#4 2023-12-14 08:13:06

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#5 2023-12-14 13:50:02

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#6 2023-12-14 21:07:02

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#7 2023-12-16 15:10:59

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#8 2023-12-16 20:51:09

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#9 2023-12-17 10:24:55

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

#10 2023-12-17 14:09:49

Re: [RESOLVED]Plasma super slow to start, possibly Nvidia driver issues?

Board footer