ich777

Exactly that is the case what @vojtagrec said, the contents of your file /boot/config/modprobe.d/i915.conf are: enable_dc=0 whereas it should be: options i915 enable_dc=0 The path from the file that you have to change is: /boot/config/modprobe.d/i915.conf After you've changed that you have to reboot!

What client or better speaking initiator are you using? Are you sure that you aren't limited by the client? Have you yet tried another machine?

I don't know that card but I know such cards exist. What is the correct driver? You can install the legacy driver 470.xx in the plugin and of course the latest ones. If the driver is not publicly available from Nvidia I can't help here because this would violate their EULA.

I can not reproduce this on my server, I've attached the log and it starts up just fine: dontstarvetogether.log On what Unraid version are you? The dedicated server starts up just fine on my system, of course I have no token installed but it is starting fine.

On startup it pulls always the latest one (from the Ombi GitHub itself). My containers work a little different and they are self maintained, however you can also set a static version that you want to stay on. I'm using the default SQL database, configuring or better speaking if one wants to use MariaDB that's up to the user. Hope that helps...

Then the ssh keys are not set up properly if you are still asked for a password. Please also note that you have to put the ssh key into /luckybackup/... and not into /root/...

No, because luckyBackup was designed as Desktop application and not to be run in a Docker container. The cron jobs are definitely working if you've enabled console mode. Did you ran the sync already one time manually to test if it syncs correctly? No issues over here with cron schedules.

Open up a terminal and issue: rm /root/.config/htop/htoprc After that htop should be sorted as usual.

This is completely random, if it stops working it stops and usually won't work again until you reboot. It should be always fixed after a reboot, at least from my experience (this is also not platform specific, I know this issue from Sandy Bridge - 2nd gen Core-i series up to Raptor Lake - 13th gen Core i series. Yes, but it's not used for transcoding, usually it's used for drawing stuff on screen by calling the blitter function if I'm not mistaken. EDIT: You can learn more about blitter here: Click

The path mappings in the container have to be exactly the same so to speak if your download path in the container in SABnzbd is /mnt/downloads you also have to set it to the same path in the other containers. The only thing that matters is that the path in the container is the same, so to speak, simply change the path in the container and also don't forget to change it in the configuration from the application itself.

I have to look into that issue when I got home from work. It is really strange to me since another user on 6.12.1 is utilizing the driver just fine: With the Nvidia Driver yes, however if you haven't experienced any issues so far then it should work on 6.12.1 also just fine. Most AMD users have to disable C-States so that the card can work properly. I think something else is going on on your system but I can't tell for sure what. BTW just because I noticed it, don't switch between various driver version since this won't magically solve your issue, stick to the latest one by switching it makes diagnosing the issue much harder for me. What is the device 0000:07:00.0 in your system and why did you bind it to VFIO? If all of that doesn't help can you try to downgrade to 6.12.0 and see if that fixes the issue? I've also now took a quick look how often driver version 535.54.03 was downloaded and as of time of writing it was downloaded about 2000 times, so I'm assuming it is working fine since otherwise I would have many reports that the driver isn't working.

Please share a bit more information about how you've set it up. A screenshot from the configuration would be nice, also are you using a image, do you have write-through activated? The Diagnostics missing in your post.

These Diagnostics are the same as before, the driver did not install for whatever reason on your system even if it tells it in the syslog. The message on boot just tells you that the driver package did not install I need the Diagnostics when the plugin reports that "nvidia-smi is not able..." Do the following: Uninstall the plugin Reboot Pull a fresh copy from the plugin from the CA App Reboot The plugin should report that nvidia-smi failed -> pull the Diagnostics imitatively and post them here Did you change anything in the BIOS, did you maybe do a BIOS update or anything similar, was it always the case that you've booted into UEFI instead of Legacy mode? Please check also if you have C-States in the BIOS disabled -> this causes mostly issues with Nvidia cards.

What container are we talking about? Do you use Unraid? This log output seems really convoluted... Please post your docker run command and also a screenshot from your Docker template if you are using Unraid.

You can do that yourself, simply restart the container, if it doesn't pull the update set validation to 'true' (without quotes), if that also doesn't pull the update either you have to delete the container and the directory for Satisfactory from your appdata directory and pull a fresh copy from the CA App (don't forget to save your savegame somewhere safe so that you can import it later). Most of my containers work differently and they update themself on a restart (this is also mentioned in the description from the container). BTW this is also the wrong support thread, if you click on the container icon on the Docker page you should have a entry named "Support", click on that and it will take you to the right support thread.

The usual way is that you remove the plugin, then reboot and then reinstall the plugin again and reboot again. Please post your Diagnostics, this is completely different from before.

Where does it say this, do you have a screenshot please? The driver size seems correct to me and I don't think the checksum is wrong. Have you yet tried just to reboot after verifying the checksums? From what I can tell from your syslog it wasn't downloaded and installed later on in the boot process.

Did you read the description from the container? Did you enable console mode?

It seems that you are trying to applying it in multiple places and hope that one is working which is definitely not the way to do it. Please remove the line with the modprobe or comment it since this won't do anything because the module is already load at that stage. Also remove these lines for the i915 module because this is not how you would append that. Where are the contents from this file? They should be: options i915 enable_dc=0 (please note that if you are using the default editor from OSX it will destroy the formatting and Linux can't read it) Why are you not on 6.12.1 since it is now stable and try it there?

& @SimonF this is a common issue and is not related to the GPU Statistics plugin, this is actually caused by intel_gpu_top Just issue intel_gpu_top from a terminal and you should see that it reports 0% even if no load is on the GPU (this is when it doesn't work correctly). I've already reported that multiple times over on the Intel-GPU-Tools Gitlab but they can't reproduce this issue.

This is a plugin and you should always use the support thread because strictly speaking Limetech has nothing to do with it. Did you waited with the reboot until the Plugin-Update-Helper told you it is safe to reboot? After the download finished it should have told you just to reboot. No, it tells you to wait until the Done button appears and that you should not close this window. Glad that it is now working again, please always read the dialogues.

Solved:

Not that I‘m aware of, what issues are you talking about? If you are ecperiencing issues, please always include your Diagnostics. 6.12.1 is in terms of the Nvidia Driver plugin the same as 6.12.0

Please post your Diagnostics so that I can tell what‘s going on, you can also send them via PM if you feel more comfortable that way.

Nothing to worry about, this message doesn‘t prevent the server from running. Can you maybe post the full log output?