b3rs3rk

If you're happy with staying version locked forever, cool. But if you want help fixing the issue I will need a lot more detail starting with everything I outline in the troubleshooting section of the first post of this thread.

That is bizarre to say the least. I need to set up a screen share session with you to diagnose further as there really shouldn't be a disparity between running it from web and CLI.

@Wookiee of the Year What is the result of the following command on your system? lspci | grep VGA

Hmm, I was under the impression that it hasn't worked yet. When did it start working for you?

Can you expand the error property in those responses and share?

It 'spamming' is correct and configurable as to how often the javascript runs the collector to refresh the widget if it's too often for your liking, but there's really no other way to do it. If you click on any one of those requests and look at the actual response, does it reflect the same data as manually running the gpustatus.php script from the CLI (from the troubleshooting steps)?

When watching the Network tab of the Developer console and sitting on the Dashboard, do you see repeated calls to gpustatus.php? To me it looks like your dashboard isn't even attempting the Javascript-based calls to populate the data.

If you look at the Dashboard page and open the Developer console of your browser are you getting any errors? Anything coming up in the UnRAID system log when accessing that page? Your diagnostics upload from before didn't show anything but I just want to be sure. Near as I can tell with all the information you gave me there really shouldn't be an issue.

The only thing I'm missing is number 2 from that same list in the first post. I need to see what is getting spit out when the data collection actually runs.

I see the issue, dumb mistake on my part. Will push a new release shortly that should fix the problem. EDIT: Released, sorry!

@Joker169 @Slycooper I just edited the support requirements in the first post of this thread. Of particular interest to me in both of your cases is your gpustat.cfg file. Look at Item 4 in the list for more info. Send it to me when you have the chance and I can review. Thanks.

@sersh @Ulrar @Marlat When running intel_gpu_top manually as a test is there a closing curly brace at the end? Look at @sersh's output before. I'm not seeing a closing curly brace which is not valid JSON. Let me know if that is the case.

Hmm, the regex to capture AMD devices matches on that output, which means it should be sending it to inventory. I'd have to do some debug tests to figure out why it isn't making it to the combined inventory used to display the choices in the Settings page.

Run lspci | grep VGA and paste the result.

Sorry for the delay, for some reason I stopped getting notifications of posts for the thread. Are you still having this issue? My guess is your GPU isn't being caught be the regex for inventory. Should be a simple fix if we can narrow it down to that.

I commend their effort, but I wouldn't accept a PR if they opened it in its current state. Plainly put, there's a big difference between doing it right and what they did. 1) They triplicated the page content that is embedded into the dashboard. Not sure why considering they could have just looped the GPUStatus page for each GPU present. 2) They did not address the single largest issue, which is having individual settings for each card. Instead, all cards have to use the same settings. So if you had two NVIDIA cards that had different metrics available, you'd be stuck with a bunch of N/As on one or both of them. Would probably work fine for an Intel iGPU and NVIDIA dGPU user, but inevitably someone would ask why they can't select individual settings and I'm not about to tempt them with a less than half working product. The reason this is so difficult is because the config file needs to change completely to support multiple GPUs along with the Settings page to correctly populate it. Then you have to consider the upgrade path for everyone to move from a single GPU config to a multi GPU config without 5K forum posts asking why it is broken.

Did your issue get resolved?

@srfsean Not sure if this is resolved for you in some update of the NVIDIA drivers, but I can't fix what isn't given to my plugin from the nvidia-smi output: <power_draw>N/A</power_draw> Because nvidia-smi is reporting N/A for your power draw there's nothing I can do. My plugin accepts the values from nvidia-smi as ground truth. This happens a lot with NVIDIA driver releases. They seem to regress or deprecate a lot from release to release. Perhaps it was a mistake and they already fixed it in a newer release?

@rm414 I haven't seen output like that before. Unfortunately, my plugin only takes what radeontop outputs at face value, so the issue is outside of this plugin's control. You would probably need to seek help in the RadeonTop support thread or otherwise.

Correct. The card is no longer visible to the nvidia-smi utility so the plugin cannot retrieve data from it.

There is nothing in my plugin that would or could prevent UnRAID from booting. If you didn't choose a vendor, at worst the dashboard page would render a blank widget.

Having trouble understanding your first sentence. Is this the first time you are using the plugin? Have you at least once clicked 'Apply' at the bottom of the settings page? Show me the contents of your config file: more /boot/config/plugins/gpustat/gpustat.cfg

If you just changed cards, you need to change a setting with the new card selected and actually click Apply. I'm betting your config still has the GUID from the previous card you had installed.

At this point, it might be beneficial if we could set up a screen share session. Otherwise it is going to be a PITA to send you all the debugging changes to find the root of the problem.

If you can, open an issue on GitHub and I'll push some kind of fix in the next release.