Unraid_Student

That's fair - after the random drop I just wanted to control what was going on in case of a random bug. Thanks for the tips unraid team!

I was scared to use the GUI so I did this in maintenance instead - worked perfectly! I think the main issue was non maintenance mode and targeting wrong disk naming convention. 1st Command: xfs_repair -v /dev/md2p1 Phase 1 - find and verify superblock... - block cache size set to 3823616 entries Phase 2 - using internal log - zero log... Log inconsistent or not a log (last==0, first!=1) empty log check failed zero_log: cannot find log head/tail (xlog_find_tail=22) ERROR: The log head and/or tail cannot be discovered. Attempt to mount the filesystem to replay the log or use the -L option to destroy the log and attempt a repair. 2nd Command: xfs_repair -vL /dev/md2p1 Phase 1 - find and verify superblock... - block cache size set to 3823616 entries Phase 2 - using internal log - zero log... Log inconsistent or not a log (last==0, first!=1) empty log check failed zero_log: cannot find log head/tail (xlog_find_tail=22) - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 clearing reflink flag on inode 8949 clearing reflink flag on inode 4429733124 clearing reflink flag on inode 2147483778 clearing reflink flag on inode 2671464208 clearing reflink flag on inode 2671464209 clearing reflink flag on inode 2671464210 clearing reflink flag on inode 2671464211 clearing reflink flag on inode 2671464212 clearing reflink flag on inode 2671464214 clearing reflink flag on inode 2671840328 clearing reflink flag on inode 2671840337 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (7:625855) is ahead of log (1:2). Format log to cycle 10. XFS_REPAIR Summary Fri Jun 6 00:42:39 2025 Phase Start End Duration Phase 1: 06/06 00:28:14 06/06 00:28:14 Phase 2: 06/06 00:28:14 06/06 00:28:51 37 seconds Phase 3: 06/06 00:28:51 06/06 00:29:03 12 seconds Phase 4: 06/06 00:29:03 06/06 00:29:05 2 seconds Phase 5: 06/06 00:29:05 06/06 00:29:06 1 second Phase 6: 06/06 00:29:06 06/06 00:29:14 8 seconds Phase 7: 06/06 00:29:14 06/06 00:29:14 Total run time: 1 minute done Thanks :)

Thanks! Will do this after recovering mission critical stuff and report back.

Had a random disk drop that was healthy. After running dry runs of xfs_repair, it could not find a superblock. Running xfs_data on it found a zeroed out header and a version of xfs that is really old. Output: xfs_db: /dev/sdc is not a valid XFS filesystem (unexpected SB magic number 0x00000000) xfs_db: V1 inodes unsupported. Please try an older xfsprogs. Diagnostics attached. Currently thinking of running an older version of unraid (6.10 era) to see if xfs_data or xfs_repair can communicate with whatever metadata got scrambled during the final phases of repair. Parity process reported 0 errors once finished. Ordering a HDD now to dd image the disk to for non-destructive troubleshooting. Any suggestions? tower-diagnostics-20250530-1250.zip

I've tried and tried but its one of those things where I think if you find a fix, they will find a patch anyways. Might be better to just get a separate machine for games that use BattleEye/EAC. Edit: Or, get another NVME/SSD/HDD and dual-boot into windows for that exact purpose if you have any slots left over.

I love all the community support here to get it working while we wait! I will practice my zen and still wait for SpaceInvaders version as I’m sure there’s a logical reason behind delay (Work is kicking up,etc) 😌

Okay. so have an update here. Updated to the latest Unraid today which addressed freezes when using a 2.5GB Realtek Card (which my computer had). Updating Unraid and running previous configuration made it SLIGHTLY more stable, but the remaining steps taken returned my PC to a normal condition. A.) Reverting to old bios (one version back, v4602) using Flashback method. First I re-installed the current bios using Flashback. Then I waited, and installed the old version, just to make sure it was as clean of a process as possible. B.) Once the BIOS was fresh, I realized that any tinkering I did in the past would be gone, and allowed me to focus on the only 2 settings that matter (from a fresh, default config). IOMMU Enabled SVM C.) When creating VM, changed Virtio-net to Virtio, added my passed through GPU (with paired Audio Controller under Sound Card) and set my machine type to i440 7.2, installed, allowed Windows Update to grab WHQL drivers for display and network - then I received Black screen (known bug on my machine - i440fx does not like default WHQL from windows) Note: I also did not VFIO bind GPU under "System Devices". Under "VM Settings" I have the following: PCIe ACS Override: Both VFIO allow unsafe interrupts: Yes D) After driver installed and black screen - force stopped machine, changed from i440 to Q35. Windows login now displays when starting machine. E.) CPU Pinning settings remained the same - isolating cores for VM specifically and allowing Unraid 2-4 cores. F.) VM Ram was set to 32GB, I've read going beyond has iffy results. G.) Ran a download test and wiggled my mouse around and everything is smooth again! It could've been only one of the things from A-G, but something did it and I just wanted to document the process in case any one else encounters this issue. Thanks Unraid team for latest update, and forcing me to rethink the whole process resulting in a smooth download/network experience.

Also looking forward to this 😇

Issue still remains after disabling WSD

Checking this thread now to see if its the cause - because its similar where one CPU core will spike, then the next core, etc.

Hey, I'm running a KVM following Space Invader One's best practices for setting up a gaming VM and as of recently, I'm having GPU issues with my VM. The only real change I made was switching the motherboard, and going from non-UEFI to UEFI. I disabled C-States and enabled virtualization in BIOS settings as suggested. System Specs Motherboard ASUSTeK COMPUTER INC. ROG CROSSHAIR VIII DARK HERO , Version Rev X.0x American Megatrends Inc., Version 4201 BIOS dated: Tue 26 Apr 2022 12:00:00 AM PDT Graphics Card AMD 6600XT (Not using GPU BIOS dump) CPU AMD 5950X RAM 32GB Cache Drive for VMs (domains) - NVME Cache Drive for App Data - SSD VM Config: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm' id='4'> <name>Unraid Support Log</name> <uuid>285853cd-56aa-0ff6-edd7-684704245625</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>17301504</memory> <currentMemory unit='KiB'>17301504</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>18</vcpu> <cputune> <vcpupin vcpu='0' cpuset='6'/> <vcpupin vcpu='1' cpuset='22'/> <vcpupin vcpu='2' cpuset='8'/> <vcpupin vcpu='3' cpuset='24'/> <vcpupin vcpu='4' cpuset='9'/> <vcpupin vcpu='5' cpuset='25'/> <vcpupin vcpu='6' cpuset='10'/> <vcpupin vcpu='7' cpuset='26'/> <vcpupin vcpu='8' cpuset='11'/> <vcpupin vcpu='9' cpuset='27'/> <vcpupin vcpu='10' cpuset='12'/> <vcpupin vcpu='11' cpuset='28'/> <vcpupin vcpu='12' cpuset='13'/> <vcpupin vcpu='13' cpuset='29'/> <vcpupin vcpu='14' cpuset='14'/> <vcpupin vcpu='15' cpuset='30'/> <vcpupin vcpu='16' cpuset='15'/> <vcpupin vcpu='17' cpuset='31'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-7.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv mode='custom'> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='9' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/xxxxxx/vdisk1.img' index='3'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='2'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Windows/Windows10_x64_en-US_IoT-ENT.iso' index='2'/> <backingStore/> <target dev='hda' bus='sata'/> <readonly/> <boot order='1'/> <alias name='sata0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.240-1.iso' index='1'/> <backingStore/> <target dev='hdb' bus='sata'/> <readonly/> <alias name='sata0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='sata' index='0'> <alias name='sata0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <alias name='usb'/> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <alias name='usb'/> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <interface type='bridge'> <mac address='52:54:00:40:be:1a'/> <source bridge='br0'/> <target dev='vnet3'/> <model type='virtio-net'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/0'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-4-xxxxxxxx/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'> <alias name='input0'/> </input> <input type='keyboard' bus='ps2'> <alias name='input1'/> </input> <audio id='1' type='none'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0d' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0d' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x10' slot='0x00' function='0x3'/> </source> <alias name='hostdev3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> Diagnostics attached. Edit: To clarify, my graphics will stutter/freeze randomly while audio continues. If I check the dashboard in Unraid, in the past I'd get CPU spikes around the same time it was freezing. Don't know if that was purely coincidence - but I didn't see anything obvious in the logs. bad-logs-diag.zip

Adding a cache pool for domains, switching array to WD Red, adding pcie_aspm=off, switching SATA Cables, and adding new controller seems to have fixed it. Let the VM stay on over night, it hibernated, VM Paused, resumed the VM, and still stable. Solved for now!

Good to know lanes isnt the issue - just ordered the new SATA controller with new cables and will report back to see if that resolves the issue. Thanks mod team for responding! @JorgeB

Currently looking to setup an Unraid Machine with AMD 5950X AMD 6600XT MZHOU PCI-E SATA Expansion Card (ASM1064 Chipset w/ 4 Connections) https://www.amazon.com/gp/product/B096DM8YMR/ 2TB SSD for VM/Docker Cache 2TB WD RED for Array (No parity at moment, cannot afford) Intel 4 Port NIC MSI MEG Unify X570 (https://www.msi.com/Motherboard/MEG-X570-UNIFY) Currently ran a test run and SATA would drop with error when running VM. After further reading, I saw this is associated with a bad SATA controller. Guessing onboard isn't the best way to go lol. With all of that in mind, looks like Im hitting ~20 lanes with that setup, and if I add an NVME, looks like I'll be maxed out. Curious what's causing this error? Sorry for the noob questions - I think I have it 90% figured out Appreciate your help! Edit: Lane Calculations Ryzen 5950X PCI/E Lanes Total: 24 ——— Chipset: 04 GPU: 08 NVME: 04 SATA/PCIE Card (X4 SATA): 04 Ethernet Card (x4 1.0Gb): 04

Hey all, Use case: I use unraid in GUI mode, plugging my monitor directly into the Unraid machine and logging in there. I'd like to use this machine as a VM host with GPU Passthrough for everyday use, with the option to allow Dockers/Apps to run in BG, accessible through VM. I'm currently testing my config on an Unraid trial using the following hardware: Unraid Version: Latest Stable Motherboard: ASROCK B550 STEEL LEGEND ATX CPU: Ryzen 5950X GPU: SAPPHIRE NITRO RX6700XT RAM: Non-ECC, 16GB (if you need specific speed/brand please let me know) USB Stick: Cruzer 2.0, plugged into an onboard USB 2.0 port Networking Port: Onboard Realtek Unraid is REALLY slow sometimes. Random menus will hang on the loading animation, DHCP randomly drops or takes a long time to pickup its determined IP. It used to be just the networking menu would hang when switching from Automatic to Manual - but now it seems to be across most of the menus. I've read some posts about disabling C-States, enabling IOMMU grouping, and other preferred BIOS settings. Question time: What could be causing this slow down? This is all brand new hardware I recently purchased. Slightly unrelated - I know AMD video cards have issues with Unraid, and there are workarounds by installing the V-BIOS within the VM settings. Do I still need 2 video cards to switch from a live VM session back to Unraid in "Unraid GUI Mode"? OR if I shutdown the VM, will Unraid automatically recognize the GPU has been released and pick it back up? What is best practice for this scenario? I'm realizing the importance of getting a big fancy motherboard now with the most ports possible for expansion cards and GPUs - will be upgrading to a better motherboard soon, but would like to determine whats causing this, so my next purchase doesn't yield the same results. I've seen plenty of successful B550 builds, so Im hoping that's not the issue. Cheers, Unraid_Student