lnxd

Perfect! Thank you, looks like my understanding was correct. I'll update the instructions to reflect as such. 😂 You are everywhere, and yep nice and simple 😉 amdgpu-pro-20.20. This isn't the first time I've heard this, but unlike yourself I'm not a genius so I need to do a lot of research first before I know what works. Now that I know it meets the requirements for CA, it's worth spending some time to thoroughly investigate. I'm curious to learn if there is any impact on using eg. open source in the container, vs. proprietary on the host, vs. different versions of the drivers, etc. I'll probably also need to add tags with different driver versions as different cards don't work with PhoenixMiner on specific amdgpu-pro versions. I also want to see if I get different results on different versions of the kernels available with PhoenixMiner, and I might benchmark against other mining software too.

Hey again @ich777! I just saw that you've released Radeon Top and it should save a lot of time for users trying to install a container I just had added to CA. Just a few things I was wondering about if that's cool with you? 1. I've noticed in the code it runs modprobe amdgpu, does this mean that a reboot isn't necessary after installing it before the GPU becomes available to the host? 2. Does it mean that it's not necessary to run touch /boot/config/modprobe.d/amdgpu.conf per the user guide to get Unraid to load the drivers as long as this is installed? 3. Does this override everything that could prevent Unraid from loading the drivers? eg. vfio passthrough being enabled for the GPU, or the GPU being stubbed Thanks mate!

Overview: Support thread for lnxd/PhoenixMiner in CA. Application: PhoenixMiner - https://github.com/PhoenixMinerDevTeam/PhoenixMiner/ Docker Hub: https://hub.docker.com/r/lnxd/phoenixminer GitHub: https://github.com/lnxd/docker-phoenixminer Please ensure that you know what you're doing before setting this up, as excessively high temperatures are BAD for computers and could damage your hardware / eventuate in data loss. Instructions: Ensure you are on Unraid 6.9.0 or later; otherwise, amdgpu drivers are not included. Ensure your GPU is not bound to vfio at boot, on 6.9.0, and later you can do this by visiting Tools > System Devices and ensuring your card (and its audio device) is not checked. Also, ensure your GPU is not stubbed by checking its ID on the above page and cross-referencing with pci-stub.ids= (by visiting Main > Flash). If you made changes in this step, you need to safely shut down the array and reboot before proceeding. If you use AMD: Install ich777's Radeon TOP via CA (Easiest way to load AMD GPU drivers on Unraid host, which is still necessary even though the container contains AMD drivers). Install lnxd's PhoenixMiner via CA. Make sure you update the pool & wallet address; otherwise, your 'rig' will generate income for me instead. If you use NVIDIA: Remove -amd from Additional PhoenixMiner Arguments. If you want to enable PhoenixMiner to control the fans / undervolt / overclock: leave privileged mode enabled for the container. Run it, check the logs constantly for the first 20 mins or so to ensure it is working and your card doesn't overheat. If something looks incorrect, stop the container and double-check your config. I like to try and keep my 5500XT around 75c and my RX 580 around 55c (modded bios). (Optional) If you want to monitor your miner from a web app rather than a representation of the logs, check out PhoenixStats in CA. Warning: If you don't leave privileged mode enabled for the container, your GPU's default fan curve will be used, which is usually optimised for gaming. Make sure you have Bergware's Dynamix System Autofan installed to prevent overheating. I recommend enabling it and setting the high temperature to 25c at most. Low I set to 20c. I could not get the PWM min speed, but this didn't affect anything for me during testing. Tags: Nvidia cards should work on all tags. Different AMD GPUs require different driver versions, and those different driver versions often don't work very well on Operating Systems that they weren't built for. For this reason, I've gone ahead and changed to using multiple tags, each tag has it's own GPU compatibility table further down. If someone has success with an AMD GPU on a specific tag please reply to this thread and let me know so I can update the table. I only have access to an RX 580 and a 5500XT for testing. lnxd/phoenixminer:latest (Same as latest-20.20 as this is the most compatible with current cards) lnxd/phoenixminer:latest-20.45 (Only for RX6800 and RX6900) lnxd/phoenixminer:latest-20.20 lnxd/phoenixminer:latest-18.20 lnxd/phoenixminer:latest-15.12 (Cards that rely on the radeon kernel module will not work) Compatibility: These lists are very hopeful, they're sourced from the AMD website, and there's a real possibility your GPU might not work with a tag it's supposed to. Please do not make purchasing decisions based on these tables. Also keep in mind you are unlikely to be able to profit from mining with a card with less than or equal to 4GB VRAM available to it. If you try this container you will probably get a DAG generation error or an extremely low hash rate. GPUs possibly compatible with lnxd/phoenixminer:latest-20.20: (click to expand) GPUs possibly compatible with lnxd/phoenixminer:latest-18.20: (click to expand) GPUs possibly compatible with lnxd/phoenixminer:latest-15.12: (click to expand) GPUs possibly compatible with lnxd/phoenixminer:latest-20.45: (click to expand) FAQ: (not necessarily by real people 😂) Q: Where can I find more arguments to use in additional? A: The output of ./Phoenixminer -help for 5.6d is available here. Q: I have multiple GPUs, can I use this container? A: Yes! If you have multiple GPUs, and they are all listed in one table, go for that version. If you have multiple GPUs and they are on different tables, you can have multiple containers on different tags and use the -gpus flag in PhoenixMiner to set which container uses which GPU. Q: What are the mining fees? A: There are none from me. The developer of PhoenixMiner charges 0.65%. This means that every 90 minutes the miner will mine for them for 35 seconds. The default pool, Ethermine, has a 1% fee and shares the transaction fees from the block. You can change to mine on any pool. Q: Why is my card still heating up if I've set a target temperature (tt)? A: PhoenixMiner seems to still rely on the default fan curve, so unless you've optimised that for mining it's probably best to set a fixed fan speed by setting the tt value to a negative, such as -70 (fixed at 70% fan speed while PhoenixMiner is running). The lower you can safely set this, the slightly less power your rig will use and the less the affect mining will have on your GPU fan's lifespan. Q: Why am I getting such a low hash rate (eg. 2.5MH/s)? A: Could be a lot of things, from the card having a very low power limit set, to trying to use a fake card. But the most likely issue is that you're using a card without enough VRAM. 4gb cards are not really suitable for Ethereum mining, please see the Compatibility section above. Q: Is there an easier way to see the data from the Unraid WebUI Dashboard? A: Yes! Users who have ich777's Radeon TOP installed can also install b3rs3rk's GPU Statistics plugin from CA. This will allow you to see things like the GPU temperature, load, fan RPM of one GPU at a time. Please note that it is expected for memory usage to be only around 4gb, as this is the current DAG limit. Q: Does this also work with NVIDIA cards? A: Shh! Yes it does. I don't know enough about the NVIDIA drivers in Ubuntu yet to list a compatibility chart, but thanks to some testing by ich777 I have confirmation that lnxd/phoenixminer:latest-20.45, lnxd/phoenixminer:latest-20.20 and lnxd/phoenixminer:latest work with a GTX1060 6GB. The same limitations with regards to VRAM apply as AMD cards, 4gb cards won't work. Screenshots: Feel free to comment here if you need any assistance.

Looks like we're in the same boat. I did a search on here and there's a couple of posts with people asking for this functionality before they started including the AMD drivers which made it possible. I'm also pleased to see there wasn't any backlash from posting this so I might see if I can apply tonight. It would be possible, and luckily passing /dev/dri doesn't seem to lock the device, the host can still use it and you can even pass it to multiple docker containers. The good news is that most miners already have arguments/flags that let you limit the GPU, eg. for PhoenixMiner: -gpow <n> Lower the GPU usage to n% of maximum (default: 100). If you already use -mi 0 (or other low value) use -li instead. You may specify this option per-GPU. -li <n> Another way to lower the GPU usage. Bigger n values mean less GPU utilization; the default is 0. You may specify this option per-GPU. It would be risky to implement a hard limit though, as these mining applications are usually designed to be in charge of the GPU, including OC and GPU reset, etc. and it depends on the skillset of the mining application's developer as to how they implement these functions. Most of these mining apps are closed source which makes it much more time consuming and risky. I think it's best to leave it up to the built-in arguments. After running it for 6 days I haven't had any unexpected behaviour at all so I think it's just about ready 😄 Edit: This is now on CA for anyone who is interested, lnxd/PhoenixMiner-AMD

Hey guys, Before I do an application for my container to be added to CA, I just wanted to get the general community's opinions on the idea. I wasn't having any luck getting my 5500XT to pass through to a VM without causing a whole bunch of issues, so since LimeTech have kindly gone ahead and included amdgpu driver support in the newer versions of Unraid, I spent the afternoon containerising PhoenixMiner so that the card is at least used for something. Since PhoenixMiner is closed source and a little controversial at the moment, I'm just going to note that it is extremely easy to change it to most other linux supported miners (eg. teamredminer). On my Unraid server personally, there shouldn't be any ill effects of letting it mine. My hard drives are all stored in a cooled enclosure enclosure separate from my PC, I have an overkill RM850x PSU, good airflow, and my server runs off a 1500va PSU. I've also been letting NiceHash mine in an NHOS VM when my other GPU isn't in use now for a few weeks without any noticeable side effects. That said, I'm sure there is a lot of hate here just like everywhere for the mining community, and with the potential risks (eg. users overheating their storage devices in a storage oriented OS) I wanted to leave it up to you guys to decide whether this is something you want to see in CA or not. I've set the poll to a week just so that I have the opportunity to confirm it doesn't cause unexpected shutdowns, etc. but if anyone needs the code urgently it's on dockerhub. Also please don't judge, it's the first container I've ever made public 😅 EDIT: I should note, I know ptrfrll has trex-miner on there, but that only works with Nvidia cards as far as I could tell. This is for AMD cards.

Thank you! This is just what I was looking for. Just one small bug that's easily worked around that affected both AMD cards I have: they are named Radeon RX 470/480/570/570X/580/580X/590 and Radeon RX 5500/5500M / Pro 5500M. This causes the script to try to save a file as eg. "/mnt/user/appdata/isos/vbios/Radeon RX 470/480/570/570X/580/580X/590" which of course on a linux based system doesn't work. The script then fails and causes a generic error, there's a few issues on the repo's GitHub page that look like they could be due to the same error as well. The affected line is #294. It's not like @SpaceInvaderOne didn't warn me via the Readme that it will try to make a name before I wasted about 20 mins on the wrong path 😅 Maybe next time I'll read the documentation more closely. Until @SpaceInvaderOne has a chance to review it, all anyone with an AMD card needs to do is set the "vbiosname" variable to a suitable name.

Hey guys, ich777's kernel builder solved it for me. He's made it very straight forward: 1. Add the container via community applications and select the options you want. Deselect anything you don't need but mark vendor-reset as true, it will compile a kernel for you 2. Back up your existing kernel just in case (download a dump of your flash drive via the GUI), copy the generated kernel files from the output folder to the root level of the flash drive, overwriting the existing ones. 3. Reboot You'll see the discussion I had with him in that post as well, I had to change to a legacy boot mode to get my Asus RX 580 OC working in VMs but that might depend on your other hardware. It's working fine for me on 6.9.0, I haven't upgraded to 6.9.1 just yet, but I'll be doing that shortly. My understanding is the vendor-reset patch is still technically in Beta, but I'm hoping Unraid devs can move to include it in the kernel soon as it's pretty much impossible to use anything other than brand new AMD GPUs with Unraid otherwise. EDIT: Just upgraded to 6.9.1, still works like a charm with my RX 580.

Booting in Legacy mode fixed that problem as well. Thank you so much! You saved me giving up on using GPUs in my Unraid server! I was ready to go out and buy a second PC. I wonder if there is something wrong with my GPU that makes it crash so often 🤔 but at least now I can start to investigate the underlying problem without putting my data at risk and bothering my family. Thank you so much!!!!!!!!! Edit: I can't believe it, I've started and stopped VMs 5-6 times while setting up an underclock, the GPU has even crashed a linux VM, and I haven't had to restart the whole server once. Wooh!

I was just about to give up on getting my RX 580 to not take down my whole server all the time when I saw this in my system log: root@server:~# dmesg | grep vfio [ 105.052090] vfio-pci 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none [ 107.282570] vfio-pci 0000:01:00.0: enabling device (0002 -> 0003) [ 107.282661] vfio-pci 0000:01:00.0: AMD_POLARIS10: version 1.1 [ 107.282662] vfio-pci 0000:01:00.0: AMD_POLARIS10: performing pre-reset [ 107.295589] vfio-pci 0000:01:00.0: AMD_POLARIS10: performing reset [ 107.295594] vfio-pci 0000:01:00.0: AMD_POLARIS10: CLOCK_CNTL: 0x0, PC: 0x2b4c [ 107.295595] vfio-pci 0000:01:00.0: AMD_POLARIS10: performing post-reset [ 107.321575] vfio-pci 0000:01:00.0: AMD_POLARIS10: reset result = 0 You are amazing ich777! The only problem I'm having now is that VMs seem to crash during launch with the GPU selected 😅 funny how that seems like a smaller problem. I can see it says that there are no available reset mechanisms. I've attached the logs from a fresh Windows 10 VM. Do you guys have any idea what's going on? doonserver-diagnostics-20210306-1948.zip Windows-10-logs.txt

I just want to say thank you so much for making this plugin. I unexpectedly lost all the data on my cache drive earlier today but luckily I had this installed, so while I lost some very critical data I didn't have to waste a whole lot of time manually setting up all my containers again. It was just a matter of pressing restore and everything was back minus today's changes. Thank you!!!