bastl

Small observations I noticed for a couple weeks now. Every morning at 6am I do a automated BTRFS snapshot for my VMs on the cache drive to an UD drive. This works for over a year without any issues so far. What I have noticed starting on 23.11.2020 is that the allocation of the UD drive isn't shown correctly when I visit the main page after the snapshot anymore. The snapshots are created as usual (70-80G per day) but the allocation isn't showing the new values. I see the same values as the day before. Refreshing the main page isn't triggering a rescan of the drive. I am on 6.8.3 and installing plugin updates as they come in, nothing else has changed. Almost every day I check for updates. If I do a "BTRFS sub list /mnt/disks/backupdrive" for the UD drive the values are shown correct again. If I don't do this, the old values are still shown. I never had to do this before. For me this is a small problem, because I have to clean old snapshots once every 1-2 months by hand on the 1,5TB drive to not fully filling it up. @dlandon I know it's not really a big think, but maybe someone can explain me whats the reason for this new behaviour.

Same for me. I had 2048 already set in my old config and as shown in your screenshot it's the default value. Does the new SWAG template have a different value? The icon for me also doesn't changed to the new one. Not a big deal.

Make sure you optimize your VM especially for first gen TR4. Try not to use cores from different dies for example. You can find a couple tips in the forums how to improve the performance for gaming. However if this helps or not, the game in the current state isn't relly well optimized. I saw some streams with really beefy hardware and it runs like in your case in low 20fps ranges.

Today I got a info from "Fix Common Problems" the container "letsencrypt" is deprecated. So far so good, I had already read a couple weeks ago that you guys have to switch the name for the container, but I never changed my setting until today. What I did so far: 1. stop the letsencrypt container 2. backup the config folder in appdata (copied to new folder called swag) 3. edit the old "letsencrypt" container 4. changed the name to swag 5. switch to "linuxserver/swag" repo 6. adjusted the config path to the new folder 7. starting the swag container 8. adjusting "trusted_proxies" in the nextcloud config.php in /appdata/nextcloud/www/nextcloud/config to swag Did I miss something?

@Mattaton Unraid 6.9 will be able to read the sensor data from your CPU. Sensor data from Ryzen gen 3 and Threadripper TX40 are currently not fully supported in 6.8.3.

@luca2 You can use a modified 7zip version for example. Either you install that modified version or like I did, only use the desired zstd codec in the already installed mainline 7zip version. https://github.com/mcmilk/7-Zip-zstd#zstandard-codec-plugin-for-mainline-7-zip You should be also able to decompress the file using tar https://stackoverflow.com/questions/45355277/how-can-i-decompress-an-archive-file-having-tar-zst

@luca2 Sry, i thought you're using the plugin, what basically has the same functionality and is based on the older script. In the script you can find the zst compession options starting at line 75

ZST files are compresses vdisk files if you're using the "Zstandard compression" option. Usually the vdisk files is copied first, compressed into a ZST file and the vdisk copy is been removed after compression. In your case there is an older backup in the same folder which isn't compressed. You have to clean your backup destination first or you will end up in 2 big files, wasting space. Check the help!

@rachid596 Whenever i read "Starship/Matisse HD Audio Controller" I get tilted. I had spend a couple days till I finally found the solution which was in front of me all the time. Even the block diagram of my board showed the 2 USB audio controllers. RTFM! 😂

@CatMilk I had the same issue on my Gigabyte TRX40 board. Passing through the Starship/Matisse HD Audio Controller and starting the VM ended up in Unraid freezing and finally crashing. For me the Starship/Matisse Controller splits into 2 extra sound devices shown as USB audio. One is for the front panel connectors and one for the backside 7.1 connections and can be used by 2 different vms at the same time. Took me some time to figure it out. Check if you also have an extra USB audio device shown up like for me. Maybe Asus did something similar with there layout. FLR patch didn't helped in my case. For reference my post in another thread:

@GreenEyedMonster Use the following Docker which does basically the same. Installing MacOS in a VM. Watch SpaceInvaders video and you should be good to go

@odiby It's always a bad idea to expose your server directly to the internet. We had a couple people already in the forums which thought it is a good idea to place there servers in a DMZ, no extra firewall or security features of their routers active. And what happened was they got bombarded with thousands of login attempts, flooding the logs, crashing the server. Even with whitlists for accesing the server or 2FA the servers will be flooded with traffic from unknown sources. With no extra infrastructure you won't be able to prevent this from happening. Best practise is to use a vpn to access your data and with wireguard and openvpn you have all the tools you need.

Thanks for the quick feature implementation. 👍 Do you have any plans to add a function to show VM specific log files in the future and maybe the system log? AND again another feature request, i know, I'am annoying sometimes, but maybe if you have to much time to spend, have a look into the Corsair PSU statistic plugin. This adds a widget on the dashboard with the stats for the PSU. With this the app for me would be 100% complete. I swear, no more feature requests. 😂 If I can provide you some help, let me know.

@IanB No problem dude. Wouldn't be the first time i missed some hidden setting somewhere or an easy step to make something work. "wasted time" was maybe the wrong wording. 😂

@Subtletree One of the passed through devices causing this error. Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: AER: Uncorrected (Non-Fatal) error received: 0000:00:03.1 Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: device [1022:1483] error status/mask=00100000/04400000 Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: [20] UnsupReq (First) Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: TLP Header: 34000000 0a000010 00000000 80008000 Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: broadcast error_detected message Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: broadcast mmio_enabled message Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: broadcast resume message Apr 28 18:37:25 Tower kernel: pcieport 0000:00:03.1: AER: Device recovery successful 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] Kernel driver in use: pcieport One of the devices you pass through causing this PCI-bridge to throw an error. It might be the following or one of the 2 USB controllers you're passing through 07:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] Remove them one by one and test if it helps.

@IanB No problem and thanks for the implementation. 👍 I only wasted half an hour stopping the app multiple times, clearing cache, re-adding the server, restarting the phone, reinstalling the app a couple times 😂

@IanB on Android? Am I blind? I can't find any settings to enable it.

@Leoyzen Thanks for that hint, but it is not in the same group with other devices. IOMMU group 29: [1022:148a] 22:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 30: [1022:1485] 23:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 31: [1022:1486] 23:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP IOMMU group 32: [1022:148c] 23:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller IOMMU group 33: [1022:1487] 23:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller IOMMU group 34: [1022:1482] 40:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 35: [1022:1483] 40:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 36: [1022:1483] 40:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 37: [1022:1482] 40:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 38: [1022:1482] 40:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 39: [1022:1483] 40:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge

Updated the plugin and the color of the UD devices is slightly different than normal. Are we changing now to a Twitch color theme? 😂

@IanB Thanks for that nice app. Purchased, installed, working! 👍 Small feature request: Is it possible to implement a fingerprint or face unlock option when starting the app?

How could I missed that????WTF!!1!!!1 Ok, so during all my testings I completely missed that the Aorus Extreme TRX40 provides 2 USB audio devices The first one is for the front panel audio and the second for the rear 5.1/7.1 audio links. I always tried to passthrough the onboard "[AMD] Starship/Matisse HD Audio Controller" without success. 😑 Both these controllers are connected to the chipset and can be passed through to different VMs at the same time. RTFM 😂 I reverted back to default 6.8.3 kernel and had no issues to passthrough both controllers to different vms, running them simultaneously with 5.1 speakers at the back and headset attached to the front without any issues. No patched kernel needed 👍

@Leoyzen First of all thanks for your work to provide custom kernels. 👍 Let me explain the issue i have. I upgraded from a TR4 1950x to a Threadripper 3960x on an Gigabyte Aorus Extreme TRX40 and kinda see the same issues people having with passing through the onboard audio. In my case it's the following device: IOMMU group 42: [1022:1487] 23:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller root@UNRAID:~# lspci -v -s 23:00.4 23:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller Subsystem: Advanced Micro Devices, Inc. [AMD] Device d102 Flags: bus master, fast devsel, latency 0, IRQ 154 Memory at b1400000 (32-bit, non-prefetchable) [size=32K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150] Advanced Error Reporting Capabilities: [2a0] Access Control Services Capabilities: [370] Transaction Processing Hints Kernel driver in use: vfio-pci With the default 6.8.3 Kernel I have the same issue like other users with an 3rd gen Ryzen. Passing through the onboard audio controller to a VM and starting it up causing the server to freeze/lockup. No matter if I bind the device to vfio or not. Only way to get the server back to a working state is to force a shutdown. Short snippet in the state when the server locks up. I can't pull the full diagnostic at this point, not via ssh nor via webui. Apr 25 15:46:29 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 1023ms after FLR; waiting Apr 25 15:46:31 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 2047ms after FLR; waiting Apr 25 15:46:34 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 4095ms after FLR; waiting Apr 25 15:46:39 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 8191ms after FLR; waiting Apr 25 15:46:48 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 16383ms after FLR; waiting Apr 25 15:47:06 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 32767ms after FLR; waiting Apr 25 15:47:44 UNRAID kernel: vfio-pci 0000:23:00.4: not ready 65535ms after FLR; giving up Apr 25 15:48:16 UNRAID nginx: 2020/04/25 15:48:16 [error] 11486#11486: *1680 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.0.0.7, server: , request: "POST /plugins/dynamix.vm.manager/include/VMajax.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "unraid.local", referrer: "https://unraid.local/VMs" Apr 25 15:48:43 UNRAID kernel: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: Apr 25 15:48:43 UNRAID kernel: rcu: 31-....: (59 ticks this GP) idle=a66/1/0x4000000000000000 softirq=131201/131201 fqs=14340 Apr 25 15:48:43 UNRAID kernel: rcu: (detected by 32, t=60002 jiffies, g=412949, q=631295) Apr 25 15:48:43 UNRAID kernel: Sending NMI from CPU 32 to CPUs 31: Apr 25 15:48:43 UNRAID kernel: NMI backtrace for cpu 31 Apr 25 15:48:43 UNRAID kernel: CPU: 31 PID: 47678 Comm: qemu-system-x86 Tainted: G O 4.19.107-Unraid #1 Apr 25 15:48:43 UNRAID kernel: Hardware name: Gigabyte Technology Co., Ltd. TRX40 AORUS XTREME/TRX40 AORUS XTREME, BIOS F4d 03/05/2020 Apr 25 15:48:43 UNRAID kernel: RIP: 0010:pci_mmcfg_read+0x98/0xa6 Apr 25 15:48:43 UNRAID kernel: Code: 83 fe 02 74 15 41 83 fe 04 74 1a 41 ff ce 75 1d 48 01 d8 8a 00 0f b6 c0 eb 10 48 01 d8 66 8b 00 0f b7 c0 eb 05 48 01 d8 8b 00 <89> 45 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 81 fa ff 00 00 00 41 56 Apr 25 15:48:43 UNRAID kernel: RSP: 0018:ffffc900122e3cc8 EFLAGS: 00000286 Apr 25 15:48:43 UNRAID kernel: RAX: 00000000ffffffff RBX: 0000000000000ffc RCX: 0000000000000ffc Apr 25 15:48:43 UNRAID kernel: RDX: 000000000000007f RSI: 0000000000000023 RDI: ffffc90008000000 Apr 25 15:48:43 UNRAID kernel: RBP: ffffc900122e3cfc R08: 0000000000000004 R09: ffffc900122e3cfc Apr 25 15:48:43 UNRAID kernel: R10: 0000000000000004 R11: 0000000000000084 R12: 0000000002304000 Apr 25 15:48:43 UNRAID kernel: R13: 0000000000000004 R14: 0000000000000004 R15: ffff888ebcb25b40 Apr 25 15:48:43 UNRAID kernel: FS: 00001524a07b4e00(0000) GS:ffff88902d5c0000(0000) knlGS:0000000000000000 Apr 25 15:48:43 UNRAID kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 25 15:48:43 UNRAID kernel: CR2: 000014f97fed62b0 CR3: 0000000f3cf9a000 CR4: 0000000000340ee0 Apr 25 15:48:43 UNRAID kernel: Call Trace: Apr 25 15:48:43 UNRAID kernel: pci_bus_read_config_dword+0x44/0x65 Apr 25 15:48:43 UNRAID kernel: pci_find_next_ext_capability+0x9e/0xc9 Apr 25 15:48:43 UNRAID kernel: ? _raw_spin_unlock_irqrestore+0xc/0x12 Apr 25 15:48:43 UNRAID kernel: pci_restore_vc_state+0x20/0x5c Apr 25 15:48:43 UNRAID kernel: pci_restore_state+0xd0/0x26e Apr 25 15:48:43 UNRAID kernel: pci_dev_restore+0x18/0x34 Apr 25 15:48:43 UNRAID kernel: pci_try_reset_function+0x3f/0x4e Apr 25 15:48:43 UNRAID kernel: vfio_pci_open+0x7e/0x3af Apr 25 15:48:43 UNRAID kernel: vfio_group_fops_unl_ioctl+0x355/0x42e Apr 25 15:48:43 UNRAID kernel: vfs_ioctl+0x19/0x26 Apr 25 15:48:43 UNRAID kernel: do_vfs_ioctl+0x533/0x55d Apr 25 15:48:43 UNRAID kernel: ? __se_sys_newlstat+0x48/0x6b Apr 25 15:48:43 UNRAID kernel: ksys_ioctl+0x37/0x56 Apr 25 15:48:43 UNRAID kernel: __x64_sys_ioctl+0x11/0x14 Apr 25 15:48:43 UNRAID kernel: do_syscall_64+0x57/0xf2 Apr 25 15:48:43 UNRAID kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Apr 25 15:48:43 UNRAID kernel: RIP: 0033:0x1524a1fa24b7 Apr 25 15:48:43 UNRAID kernel: Code: 00 00 90 48 8b 05 d9 29 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 29 0d 00 f7 d8 64 89 01 48 Apr 25 15:48:43 UNRAID kernel: RSP: 002b:00007fff5878e818 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Apr 25 15:48:43 UNRAID kernel: RAX: ffffffffffffffda RBX: 000015241dfc14e0 RCX: 00001524a1fa24b7 Apr 25 15:48:43 UNRAID kernel: RDX: 000015241c9a1520 RSI: 0000000000003b6a RDI: 000000000000001b Apr 25 15:48:43 UNRAID kernel: RBP: 00001524181605c0 R08: 000015241c9a1520 R09: 00007fff5878c783 Apr 25 15:48:43 UNRAID kernel: R10: 0000000000000018 R11: 0000000000000246 R12: 00001524181605c0 Apr 25 15:48:43 UNRAID kernel: R13: 000015241c9a1520 R14: 00007fff5878fa30 R15: 000015241dfc0c00 At this point, the server becomes basically unusable. If I use your custom Kernel "6.8.3-5.5.8-2" you posted 2 pages back and the kernel agument "pcie_no_flr" append pcie_no_flr=1022:1487 vfio-pci.ids=1022:1487,1b21:2142 isolcpus=12-23,36-47 initrd=/bzroot I'am able to passthrough the device to a Windows VM without freezing the whole server, BUT the device isn't shown in the device manager as new device. 1b21:2142 is one of the USB onboard controllers and passthrough is working fine. Drivers are installed in a bare metal Windows install on an NVME which I use in this VM. I can't trigger Windows to show it in the device list. No errors in the VM log except for some warning: 2020-04-25T15:24:26.974831Z qemu-system-x86_64: vfio: Cannot reset device 0000:23:00.4, depends on group 39 which is not owned. 2020-04-25T15:24:29.155826Z qemu-system-x86_64: vfio: Cannot reset device 0000:23:00.4, depends on group 39 which is not owned. IOMMU group 39: [1022:1485] 23:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP The "Starship/Matisse Reserved SPP" isn't bind to vfio or used for passthrough either. Do I have to bind and passthrough that device as well??? Any idea for an workaround to have the onboard audio device to show up in the Windows VM? I really wanna figure this out and maybe try to help @limetech to implement the fix for the onboard audio issue in the next builds hopefully. I'am willing to test to find a solution for this. From all I've read so far, a couple people have issues passing these devices to a VM on the latest AMD platforms. Maybe we can workout a solution thats worth to implement in the future Unraid builds. I've not ried the 6.9 beta build yet. It's kinda the next step for me to try, but I think this won't make any difference. I'll report back soon. Thanks for the help ❤️ syslog_683_default_kernel.txt syslog_patched_5.5.8-2_kernel.txt Win10_VM_log_patched.txt 01_W10.xml IOMMU.txt EDIT: Tried the 6.9 beta 1, same issue as with unpatched 6.8.3 kernel. Same freezes, same errors. No passthrough of the onboard audio possible. After reverting back to 6.8.3 with the patched 5.5.8-2 Kernel I tried a couple combinations of binding and passing through the device in group 39 with no success. Either the "FLR; waiting" error occures and server freezes or VM starts fine without any extra audio device showing up in the device manager.

Remove the following section <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> For explanation, the error is complaining to not find the device on bus 01, slot 00 with function 1. As you can see in the <source> section above this is the culprit

You propably had. When editing your VM you can switch to xml view, top right corner, and remove the section. Post your xml and the VM logs. In case you don't know which hostdev section to remove. Are there any other devices passed through to the VM?

Indeed it is. Thanks for the help 👍