Dear Forum Members,

I am experiencing intermittent system freezes on my Linux machine, which seem to occur only after installing the Nvidia driver for my GeForce GTX 1660. I have provided a detailed bug report on the Nvidia forum, along with the relevant log files generated using the command "sudo nvidia-bug-report.sh".

In response, the forum suggested upgrading my kernel through the Liquorix ppa to resolve issues related to potential incompatibility between Linux and the mainboard, see [link]. Although this solution has been effective in most cases, the system still freezes approximately every two weeks without any discernible cause. It is worth noting that this issue does not occur during gaming, as the machine is solely used for software development.

Given the frequency of updates to Liquorix, I assume there is a protocol for reporting such issues. However, I have been unable to locate relevant information on liquorix.net. I am seeking guidance on how to obtain useful log files to investigate this problem, since it occurs infrequently and must be executed after rebooting.

I would also like to clarify that my motivation for installing Nvidia drivers on a non-gaming machine is to improve the usability of KDE plasma.

Thank you for your support.

Best regards,

Stefan


Some details about my system:


Back to top

start with: inxi -bGxxz [do NOT use root to run this, you can use sudo but root removes too much graphics data]

Non free nvidia driver freezing is really not a surprise.

I'll give you credit for doing it right, and reporting the issue to the nvidia people, who are the only ones who can actually fix non free nvidia code.

But you do have one fundamental confusion: since nvidia is a non free, closed source driver, the only people who can handle issues related to nvidia are nvidia, it's not related to linux kernel at all, nor can anyone in the linux kernel actually fix or correct or even work around nvidia issues.

You could also simply have a hardware problem, quite literally, which nothing can resolve since it would not be an nvidia OR a linux kernel issue then.

You maybe without realizing it made a choice when you decided to use non free nvidia (and my experience with nouveau is worse, since nvidia did not release the specs for their cards, nouveau has to be reverse engineered, which is really not practical at all in the real world), and that choice was to suffer issues like this without anyone who can help you.

This is why I switched to AMD a while ago, and have had no further graphics issues, that was money well spent, and very little, since I bought used amd cards to replace my nvidia cards.

The best course with nvidia is to stick to a known stable and reliable kernel that does not have issues, and then only update to new kernels when it's known reliable, and if not good, roll back to the last one that was good.

It's also critical to determine if you have a true system freeze, which means the kernel crashed or locked, or if you have an xorg freeze. An X freeze means if you use something like ctrl+alt+f1 you can login to console and everything is fine, a kernel freeze means nothing works at any level. Also, there's logs for xorg, which may or may not contain pointers to the freeze, but very likely not, also kernel logs, and journalctl logs if you use that, but again, all unlikely in case of a true freeze, because then there is nothing running that can generate log data since it crashed.

note that if you are using wayland, all bets are off since that remains as beta at very best status.

But you have to supply inxi -bGxxz at minimum just to see what you are actually running in the real world.
Back to top

Thank you for sharing. The command output provided doesn't seem to collect the necessary logging information for diagnosing the issue. It's currently assumed that the problem may be caused by nvidia, but this is not certain. The nvidia support team suggested that the issue may be related to the mainboard, and it appears that they were partly correct, as the crashes occurred less frequently after switching from the default kernel to Liquorix.

[/quote]
Back to top

Your assumptions sadly are basically useless. You are running a legacy operating system which is currently about 3 years old, roughly, a bit more if you take the ubuntu focal freeze period into account.

This makes all other issues irrelevant.

The inxi output also is useful since it suggests several easy tests you can do to determine the cause of the issue, number one being to use the native intel graphics device and see if you encounter any issues with that.

This test is so obvious that it shouldn't even need to be mentioned, and since the machine is a desktop, you can do this test easily.

That's your first test in this case.

note that the inxi in that frozen stable pool is maybe 100 releases out of date, roughly, so you're missing a lot of data that has been added since then to help debug these types of user graphics issues.

But the age of your distro, not even the current ubuntu stable lts, 22.04, make any further discussion irrelevant and pointless. If you want to run a cutting edge kernel, you can't use legacy frozen pool operating systems, they are not debuggable, they have old Xorg versions, old tool chainis.

Even the intel test would be largely irrelevant on that system since it would be too much old stuff involved to be meaningful.

This is an invalid issue top to bottom. Nvidia can't help you here, Liquorix can't help you, but you can help yourself by not requesting support for an operating system that has already been replaced by next ubuntu lts.

Note I don't know Feren off the top of my head, so don't know if they are current with ubuntu LTS, if not, that's the cost of using a smallish derived diistro like Feren.

But checking there, sadly:
medium.com/feren-os/feren-os-2023-01-minor-iso-update-for-january-2023-7440716e0c3a

you aren't even current with Feren itself, which looks like it shipped 22.10, which is only a few months old.

You can't ask for support when you yourself are not updating your operating system in a timely manner, and Liquorix is not designed for long term support / stable package pools like Ubuntu LTS or Debian stable releases.

If this was github issue I'd close the issue.
Back to top

Yep, I'll concur with techAdmin here. Liquorix follows the latest upstream stable kernel, but the farther away that kernel gets from the version of user space utilities and firmware installed by your distro, the more unpredictable and strange behavior you'll get.

This is making me think I should add a disclaimer to the website mentioning that old distributions are only supported because the kernel builds, not that it's been tested or known to work. If you have an issue, it's always important to test on a recent distribution to make sure it's not a conflict between new kernel and old software.
Back to top

Just an update, I'd definitely add Feren to the list of distros Liquorix should not try to support, what they are doing is strange, it appears that they are updating Ubuntu focal 20.04, including in their 2023.01 release, instead of actually updating to current at least LTS release, which makes absolutely no sense. Ships with GCC 9.4, not even remotely current, which makes me absolutely second damentz, this type of distro cannot be debugged or supported by rolling release current kernels, there is absolutely no way to know what they are doing internally, what firmware is shipping, it's not possible.

I discovered this while trying to add Feren to systembase support distro list in inxi, something that should have been simple and obvious, but wasn't, but while doing that, I found that they are literally shipping focal as current latest release in 2023, which is just not worth even thinking about re support, at least 22.04 would be somewhat recent, and at least is current LTS, so this type of distro is doing things that have to make them support everything themselves since nobody else can do that.
Back to top

Thank you for reminding me to use standard and up-to-date software versions. I have now switched to Kubuntu 22.04. Initially, I tried KDE neon, but due to issues with packages and my need for a lot of development software, I switched to Kubuntu. To ensure a smooth transition, I tested everything in a virtual machine using a bash script that I also use to document what I need to install.

I would like to express my gratitude because (1) the installation of the Nvidia driver went smoothly with only a minor setback when I encountered a black screen after the initial installation. However, this was resolved by rebooting in recovery mode, and Kubuntu automatically installed the necessary updates to the Nvidia driver.

(2) The issues I had been experiencing, such as frequent freezes and sporadic loud fan noise from my graphics card in desktop mode, have completely disappeared.

Initially, I chose Feren OS because Kubuntu was not able to install the Nvidia driver automatically. However, this turned out to be a bad decision that cost me a lot of time. I would like to mention that I conducted experiments with all available nvidia driver versions and eventually followed the recommendation of the nvidia forum to try Liquorix, which resulted in an improvement in the situation. Currently, with Kubuntu, I am using Kernel 5.15.0-60-generic, and everything is running smoothly. Thus, it appears that the cause of the issues with Feren OS was located elsewhere in the operating system, and not in the kernel or Nvidia driver.
Back to top

Yes, that confirms that using Feren made the entire thing undebuggable. There are similar issues by the way using Mint and LMDE because they are also a random mix of things, with the main difference being that Mint has a large, and pretty good, support community on their forums.
Back to top