blodfjert

Ich777: Thank you! Just aborted my long overdue bedtime, picked myself by the neck and dragged me back to my office for a bit of late night patching. Long story short; Now running 6.9.2, 7d2d launches like it should, VMs running well, and threw in the latest PfSense update while at it. All good! I'd replace heartbleed with 'sleep deprevation on christmas eve' any day:) Happy holidays guys, stay safe and enjoy yourselves!

Thanks for your valuable inputs, Ich777! Since posting I've tried making another 7dtd docker, pulled down the dedicated server files through regular desktop steam on my main computer, and copied all the files into the new container directory. Probably not the correct way to handle this issue, and certainly not working out as i hoped. Launching either container (original or the new) leads to a new issue: ---Prepare Server--- ---SaveGameFolder location correct--- ---Savegame location found--- ---UserDataFolder location correct--- ---UserDataFolder location found--- ---Server ready--- ---Start Server--- Found path: /serverdata/serverfiles/7DaysToDieServer.x86_64 ---Update SteamCMD--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' Looks like steam didn't shutdown cleanly, scheduling immediate update check src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize [ 0%] Checking for available updates... src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize ---Update Server--- ---Validating installation--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' Looks like steam didn't shutdown cleanly, scheduling immediate update check src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize [ 0%] Checking for available updates... src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize I've tried stopping all the Steam-related dockers I had running, hoping this would somehow release the "deadlock" to no avail. Now I know my Unraid is getting dated (uptime 603 days, 5 hours and counting). But my issues here and not related to me running an older build of Unraid, is it? Yes, I have the file '7DaysToDieServer.x86_64' in the docker folder. Tried removing it and forcing a validation, but I guess this file was originally added by me manually. Sorry, really cannot remember how this was all set up back in the day. According to the docker tab, the application is up to date. I did a force upgrade as well, but perhaps removing the docker all together and pulling it down again would somehow get a more recent release?(Sorry for my ignorance, but this has been 'set and forget' on my part, and it's been running so well that I've not even restarted my server in almost two years...)

Thanks for your effort on these containers, Ich777! I am now in a pickle with my 7d2d server hosted on Unraid 6.6.6. It's been a while since me and my friends have played on my hosted server, but we got a new urge to start fresh again now that 7d2d alpha 20 b238 went live. Usually I'd then just backup the current serverconfig.xml (to keep the settings for a future revisit), then change some details like the seed and servername and reboot the docker to have a new map created. However, this time around it has proven rather difficult, and I'm now facing error messages in the docker log that I haven't experienced before. Here is an excerpt of what appears to be a continously reboot server docker: [ 0%] Checking for available updates... [----] Verifying installation... Steam Console Client (c) Valve Corporation - version 1639697740 -- type 'quit' to exit -- Loading Steam API...OK Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK ---Update Server--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' [ 0%] Checking for available updates... [----] Verifying installation... Steam Console Client (c) Valve Corporation - version 1639697740 -- type 'quit' to exit -- Loading Steam API...OK Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK [33;1mPlease use force_install_dir before logon! [0mSuccess! App '294420' already up to date. ---Prepare Server--- ---SaveGameFolder location correct--- ---Savegame location found--- ---UserDataFolder location correct--- ---UserDataFolder location found--- ---Server ready--- ---Start Server--- Found path: /serverdata/serverfiles/7DaysToDieServer.x86_64 ---Checking if UID: 99 matches user--- usermod: no changes ---Checking if GID: 100 matches user--- usermod: no changes ---Setting umask to 000--- ---Checking for optional scripts--- ---No optional script found, continuing--- ---Starting...--- ---Update SteamCMD--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' [ 0%] Checking for available updates... [----] Verifying installation... Steam Console Client (c) Valve Corporation - version 1639697740 -- type 'quit' to exit -- Loading Steam API...OK Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK ---Update Server--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' This log is basically repeating endlessly. As far as I can remember, 7d2d have had a history of being a bit picky with the serverconfig.xml between certain versions of the game, yet I cannot seem to find any templates for this release on the web. This makes me believe my serverconfig.xml may be alright after all, and that the problem is somewhere else. The log line "[33;1mPlease use force_install_dir before logon!" may be a hint, but I've no idea how to solve it on Unraid / inside a docker. At the same time; If it were a steamcmd-related problem causing 7d2d server not to run, I would expect other steam-game dockers to fail as well, but that is not the case. Valheim, for instance, works as it should. Would love to get any input on where my problems may come from. If anyone also could provide me with a template of the serverconfig.xml for 7 days to die alpha 20 b238, that would be nice. Oh and please don't just point me into the direction of that Discord-channel. I tried going there, but got lost in some account claim stuff that I also newer figured out how to solve (trying to avoid rabbit holes all together)

Hi, and thank you for your inputs @Leftie, @billington.mark and @SpaceInvaderOne The same afternoon as I posted the OP, I came to realize that no matter how optimized my gaming VM could turn out to be, the experience would never be as fluid as the bare-metal install I tried. This epiphany made me fork out some dough, and on friday the upgrade kit arrived in the mail. For now I've been running the unraid server on the old computer hardware, and build my new gaming rig up as a bare-metal install. The replies in this thread humbles me, and I really want to find time to pursue the tips that you guys have provided. The overall performance on the new processor is really something, and I really think its 12 HT cores @3200 (up to @4600 in turbo) would make a lot of sense in a unraid kvm build, giving 'lebensraum' for both the hypervisor and the VM. Looking back at the two odd years I've been gaming on this setup with the i5 6600, I feel the old i5 did a very decent job. Even after building the new gaming rig, 'Job Simulator' on SteamVR have had med puzzled, as the laggy/choppy gaming experience carried over. Last night I set to find out why, and decided to temporarily boot up the bare-metal SSD I used on the old hardware. Upon boot, Windows 10 installed the missing chipset drivers itself. I kept the old 'nVidia 399.24' driver from the previous run, and fired up Oculus Home -> SteamVR -> Job Sim. It ran smooth as silk. Eager to try the same driver on my M.2 install, I quickly removed the SSD, booted the M.2 drive, removed my newer nVidia driver and installed 399.24 instead. This didn't have any effect, as the game performance (only in SteamVRs 'Job Simulator') were still very very bad. 'What is the difference between these setups?', I asked myself. Well, the one thing I hadn't altered yet, which shouldn't make a difference really, is the fact that my new gaming rig has its steamapps library on the Unraid array, connected through my LAN. The temporary SSD bare-metal install had its copy of 'Job Simulator' installed locally. I therefore moved the game folder (available as an Steam option on the games properties tab) from the Unraid steamlibrary array onto my local M.2 drive, and fired it up once again. And what do you know; it ran flawless! Now this has left me thinking. What difference does it make to have the steamapps library on the unraid array as opposed to having it installed locally? I would have thought this would only affect loading times? If the fluidness of the game is affected by file access times on the folder in which it is installed, either I've completely misunderstood the point of having RAM or the game have very questionable coding... All my other Steam VR games (including SkyrimVR) are installed on the array, and they're not affected in terms of laggy/choppy gameplay because of this.

Hi there! This holiday my inner child ordered the Oculus Rift with an extra sensor. While waiting for the delivery, I installed an 'USB3.0 x4 ports PCIe' expansion card that I passed through to my VM. Beforehand I've done passthrough on an ASMedia USB controller integraded on my motherboard. According to the 'oculus compatibility tool', I was good to go. Upon delivery, I do the usual tedious setup, spreading the three sensors and the Oculus HMD across available USB ports. Tracking is a bit questionable, and according to the Oculus software it was often the Oculus HMD itself that got messages stating 'poor tracking quality'. These messages would come and go, and while some games were quite playable, other game titles would go completely bonkers trying to track my movement. 'Job Simulator' being the one I've been using to benchmark the performance. Now, this was on my fairly old Unraid setup, with the following specs: - Gigabyte ga-z170xp-sli (Firmware F22c) - Intel I5-6600 (Skylake) - Crucial DDR4 2133MHz 32GB (4x8GB) - EVGA GeForce GTX 1060 3GB - Creative Sound Blaster Audigy FX - 4 WD Reds in 11TB array with parity - 512 SSD cache with VM - USB3.0 x4 ports Renesas PCIe card with direct molex power - Corsair TX 750W PSU I ran Unraid 6.1.9, and both my onboard ASmedia USB controller and the PCIe Renesas USB3.0 card were isolated on boot and passed through to the VM. The Creative Sound Blaster card have also been passed through as well as my GPU. My VM is Win10 build 1709, accessing all 4 cores of my CPU and have 16GB dedicated RAM. Virtio drivers are fairly old. I've never felt as if the gaming experience have been especially impaired by this setup, but then again I've never tried running Win10 natively in bare-metal install on this setup until now. I tried upgrading GPU drivers, rearranging Oculus USB wires for sensors and HMD, and updating USB card drivers through device mananger. Nothing seemed to make a difference. My tracking would lag out. The Oculus Diagnostics Tool - which puts a small HUD atop any VR experience - stated that I frequently lost a lot of frames while gaming, and that the headroom in terms of CPU and GPU power were underwhelming. While troubleshooting these issues, the Unraid reboots caused my old PSU to commit seppuku. Fair enough I thought; It was old, after all. A newly purchased Corsair RM750x brought me back up. At this point I decided I'd try a bare-metal install. This quickly led to more problems - albeit not necessarily related to the performance problems of the Oculus, they are interesting nonetheless; It turned out my motherboards firmware F22c were not fully compatible with my Skylake CPU (Kaby Lake support were introduced in F20, apparently), and my computer would suddenly reboot on a bare-metal install. Flashed to the latest bios - F22f - bare-metal install would work as intended. I have now tried VR in this setup - with and without the Renesas USB PCIe card - and I can say that it's a whole different experience all together! Movements are fluid, tracking is spot on, and the diagnostics tool proves that theres plenty of headroom both CPU- and GPU-wise in the titles that I've previously struggled with in a virtual machine setup. Now this led me to believe that the firmware was to blame. Last night I reinstated the array, the PCIe cards in their respective slots and booted unraid again. I then did a unraid upgrade in two steps - 6.1.9 to 6.3.5 (i believe it was), and after the subsequent reboot I upgraded Unraid from 6.3.5 to 6.6.6. After a couple of tweaks on my VMs XML, it fired up as usual. And then also downloaded and mounted up the latest VirtIO iso. I managed to upgrade the virtio drivers on a couple devices in the device management. I did not find the "Virtio Balloon" device, so I could not do anything about that one. Upon trying to reinstall the the "guest agent", my previous disappeared and the new one would not install because of some strange error message. Anyhow my VM seemed to work as inteded and I carried on benchmarking the VR experience, which were shattered quite quickly, as the tracking were now just as bad as they initially were. So, in light of this journey, I'm once again reaching out to this community to ask for help: - Would I be right in assuming that my CPU is in fact the bottleneck in my gaming VM, as it's a regular 4core non-hyperthreaded processor? Seems to me that it's loosing a bit to much performance since it's also keeping my hypervisor running while serving my childish gaming needs. Bare in mind that this was without the usual TeamSpeak, Plex etc.etc dockers running. - This afternoon I plan on dedicating only two CPU cores to the VM, leaving the other two to the hypervisor. I somewhat doubt that will help, though. - Are there anything particular that anyone can think of in regards of testing this further? Any settings I should tweak on the VM template, any drivers to avoid/seek in regards of my USB controllers inside the VM? As previously stated; I did not manage to install the updated virtio guest-agent due to a strange error message. The old drivers disappeared as well. Don't know what impact this would cause, if any? Unless someone can shed some light on this for me, I'm now strongly considering buing a upgrade kit consisting of an Asus ROG Strix B360-F mainboard, Core i7 8700 and 16GB Ballistix LT DDR4 2666MHz. I figure this processor would be far better at what I'm trying to achieve, and if not, it would make one hell of a stand-alone gaming rig if I move the GPU across, leaving my Unraid to a KVM-free future. Thanks for reading, hope to hear from you!

@1812 If you're wrong about that second part, I sure hope someone will be kind enough to shed some light on it for us both. Pooling cores into a single vcpu would also be worth a try, as I'd be curious to measure the possible gains in fps through said game. Do you know how it is done?

So; I am a gamer, completely addicted to one particular game which is known for being very CPU dependant, not so much GPU. Problem is; this games utilize only one core, and there's always a certain battle within the game community to get the best fps. Devs will not rewrite the game into supporting multicore processors, and so I thought to myself: "Since I'm playing inside a virtual machine hosted on my Unraid, would it be possible to "trick" the VM into believing it has more GHz at hand than it actually does? Could I for instance do some tweaks to the VMs KVM XML into presenting two or more cores as one to the VM, making the game inside the VM utilizing my processor in a better manner?" Dropped this question to a colleague of mine today, and he went "- yes, that should be possible. Although I'm coming from VMWare, and do not know exactly what the correct term is within the KVM universe, or how to actually do it within KVM..." I've been googling this topic back and forth for quite some time (- not only today -), yet I've got little to no information on exactly what I'm trying to accomplish. Would anyone be able to help me make this happen? My rig: M/B: Gigabyte Technology Co., Ltd. - Z170XP-SLI-CF CPU: Intel® Core™ i5-6600 CPU @ 3.30GHz HVM: Enabled IOMMU: Enabled Cache: 256 kB, 1024 kB, 6144 kB Memory: 65536 MB (max. installable capacity 128 GB) Network: bond0: fault-tolerance (active-backup) eth0: not connected eth1: 1000Mb/s - Full Duplex Kernel: Linux 4.1.18-unRAID x86_64 OpenSSL: 1.0.1s VM: Windows 10 Professional. Currently running on 3 virtual processors, with 16GB RAM Dockers: TeamSpeak Krusader Plex Basically: Make KVM dedicate two or three of my CPU cores (as "pool" or something), and use this as the VMs processor, effectively tricking my game into seeing the VMs processor as one CPU on steroids instead of 3 separate virtual processors. I may of course be completely off with my request/thoughts, but since my colleague didn't laugh himself into a hernia upon my question, I've summoned up the courrage to ask this community. Sincerely, Blodfjert

1. i've now bonded the network cards in 'active-backup mode'. Still getting some packet drops, but not experiencing any problems in stability or slow networking. 2. DMAR messages are still the same. 3. Tried moving my PCIEx1 sound card to another slot (PCIEx4), and now the card is not even available as a passable choice in the VM edit. Under System devices its recognized as: 07:00.0 Audio device: Creative Labs SB Recon3D (rev 01) It's grouped with the following devices in IOMMU-group 7: 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 (rev f1) 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1) 06:00.0 USB controller: ASMedia Technology Inc. Device 1242 I've currently disabled the PCI ACS Override. To my great joy my VM is still working with passthrough on the GPU and other needed peripherals. Think I'll keep this setup for now. Solved the VM sound by hooking my old Hercules Muse USB-soundcard and passing it through. 4. For some weird reason "Installed memory" is still reported wrongly on the dashboard. Well. I'll leave this hanging. Hopefully i'll get some pointers and tips on these issues as the holidays are over. For now; Merry xmas everyone.

Last night i downgraded Unraid. It's been all good since, knock on wood. A couple of things I've noticed today are: 1. network messages Syslog gives me these messages over and over: Dec 22 20:15:23 mothership kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Dec 22 20:15:23 mothership kernel: br0: port 1(eth0) entered listening state Dec 22 20:15:23 mothership kernel: br0: port 1(eth0) entered listening state Dec 22 20:15:25 mothership kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: Dec 22 20:15:25 mothership kernel: TDH <0> Dec 22 20:15:25 mothership kernel: TDT <1> Dec 22 20:15:25 mothership kernel: next_to_use <1> Dec 22 20:15:25 mothership kernel: next_to_clean <0> Dec 22 20:15:25 mothership kernel: buffer_info[next_to_clean]: Dec 22 20:15:25 mothership kernel: time_stamp <104f363f0> Dec 22 20:15:25 mothership kernel: next_to_watch <0> Dec 22 20:15:25 mothership kernel: jiffies <104f367e9> Dec 22 20:15:25 mothership kernel: next_to_watch.status <0> Dec 22 20:15:25 mothership kernel: MAC Status <40080083> Dec 22 20:15:25 mothership kernel: PHY Status <796d> Dec 22 20:15:25 mothership kernel: PHY 1000BASE-T Status <3c00> Dec 22 20:15:25 mothership kernel: PHY Extended Status <3000> Dec 22 20:15:25 mothership kernel: PCI Status <10> Probably related, there appears to be packets dropped on my NICs: My network is set up like this: 2. DMAR Syslog also gives these messages repeatedly: Dec 22 20:15:42 mothership kernel: dmar: DMAR:[DMA Read] Request device [04:00.0] fault addr 100000000 Dec 22 20:15:42 mothership kernel: DMAR:[fault reason 06] PTE Read access is not set Dec 22 20:15:42 mothership kernel: dmar: DRHD: handling fault status reg 3 Dec 22 20:15:42 mothership kernel: dmar: DMAR:[DMA Read] Request device [04:00.0] fault addr ffff2000 Dec 22 20:15:42 mothership kernel: DMAR:[fault reason 06] PTE Read access is not set Dec 22 20:15:42 mothership kernel: dmar: DRHD: handling fault status reg 3 Dec 22 20:15:42 mothership kernel: dmar: DMAR:[DMA Read] Request device [04:00.0] fault addr fffec000 Dec 22 20:15:42 mothership kernel: DMAR:[fault reason 06] PTE Read access is not set Dec 22 20:15:42 mothership kernel: dmar: DRHD: handling fault status reg 3 Dec 22 20:15:42 mothership kernel: dmar: DMAR:[DMA Read] Request device [04:00.0] fault addr fffc8000 Dec 22 20:15:42 mothership kernel: DMAR:[fault reason 06] PTE Read access is not set Dec 22 20:15:42 mothership kernel: dmar: DRHD: handling fault status reg 3 Dec 22 20:15:42 mothership kernel: dmar: DMAR:[DMA Read] Request device [04:00.0] fault addr ffe8e000 Dec 22 20:15:42 mothership kernel: DMAR:[fault reason 06] PTE Read access is not set It puzzles me, as 'device [04:00.0]' does not appear at all under 'System devices': I find that a SCSI device have a somewhat similar address, but this isn't the same as "04:00:0", is it?: [4:0:0:0] disk ATA WDC WD30EFRX-68E 0A82 /dev/sde 3. PCI sound card suddenly in another IOMMU group than before This is more of a curiousity and annoyance than a real problem. I'm about try fixing this by changing card slots, but I'd thought I'd mention it anyway: Back when I first set up my Unraid server, I purchased this card to pass it through to my planned VM, as I figured passing the onboard sound probably would have undesireable outcome on other components on my motherboard: 05:00.0 Audio device: Creative Labs SB Recon3D (rev 01) All was good from the get go. I used it on my original 6.1.9 build and tjen later onto my 6.3.5 build (in a new VM). Last night, after downgrading, my VM (both old and newly created) would not boot with this card passed through. After taking a closer look at the 'System devices', I noticed that the card now had been assigned into an IOMMU-group with lots of other devices: /sys/kernel/iommu_groups/7/devices/0000:00:1b.2 /sys/kernel/iommu_groups/7/devices/0000:00:1b.3 /sys/kernel/iommu_groups/7/devices/0000:03:00.0 /sys/kernel/iommu_groups/7/devices/0000:04:01.0 /sys/kernel/iommu_groups/7/devices/0000:05:00.0 These other devices are: 00:1b.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Root Port #19 (rev f1) 00:1b.3 PCI bridge: Intel Corporation Sunrise Point-H PCI Root Port #20 (rev f1) 03:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04) 04:01.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) I suspect this change in IOMMU-grouping are a result of me updating the motherboard BIOS while I still was running Unraid 6.3.5, but then again; Why wouldn't this have prohibited me running my VM then, as it is now? 4. Wrong amount of memory reported Noticed this now as I already had created this thread. Dashboard reports 65GB of memory. In reality I have 32GB. Have my downgrade magically duplicated my RAM, making my sweet box even more gnarly?:p Seriously; What is happening? Sorry for the long post. Trying to be thorough and get everything running as nice as possible. Suggestions on how to resolve one or more of my numbered problems are more than welcome. Edit: For the record, I'm running my system with PCIe ACS Override setting enabled. I am under the impression that this is required for me to pass GPU and so forth through to my VM. If I'm wrong, please let me know.

@johnnie.black You, sir, are a god amongst men! I´m up and running. You were right about the VM and docker messing up, but I should be able to recreate everything.

@johnnie.black Slight hickup. Upon booting 6.1.9, it seems my network is unreachable. My towers static ip has always been 192.168.1.2. When I experienced this earlier, I just had another reboot to fix it. Now that isn't working either. Strange...

Awesome! I have work to do=)

@johnnie.black Recreating the VM is no problem. My biggest worry is having the array mixed up. But am I correct in assuming that the files on /boot which are not being overwritten should lay there as is? Or should all files be removed from /boot, and then only the files from "previous" be copied onto /boot?

@ashman70In my other thread I got in touch with @trinikojak, who are experiencing what seems to be the same instability issues as I am. We're both running Gigabyte motherboards. He has apparently already upgraded to 6.4, but the system hangs are still occuring. I'd like to go the other way, back to good old 6.1.9. @johnnie.black So I can continue according to my plan?:) Nothing to fear, etc?

Currently running 6.3.5, and it has been very unstable on my rig since day one. Before the upgrade, I ran 6.1.9. Rock stable on the exact same hardware. After the upgrade I noticed a folder named "previous" on my Unraid USB-key. Guessing this is the complete copy of my old 6.1.9. My plan is: 1. Stop the parity check which is currently running 2. copy all content from my Unraid USB-key onto another computer for backup 3. Stop the array 4. Copy the files from the previous folder and overwrite the files on /boot, leaving the rest of the files on /boot as they are 5. reboot Unraid and pray 6. Do a new parity check 7. boot my VM and play:) Questions: Am I going about this the right way? Is it even possible reverting all the way from 6.3.5 to 6.1.9? Are there any problems I should be aware of prior to doing so? (Mind you, my hardware is the same now as it was back on 6.1.9, except for the GPU.)

Hi johnnie.black and trinikojak This is most interesting! The reason to our problems may very well be the same. Just for reference, this is my build: Model: Own build M/B: Gigabyte Technology Co., Ltd. - Z170XP-SLI-CF CPU: Intel® Core™ i5-6600 CPU @ 3.30GHz HVM: Enabled IOMMU: Enabled Cache: 256 kB, 1024 kB, 6144 kB Memory: 32 GB (max. installable capacity 64 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 1500 Kernel: Linux 4.9.30-unRAID x86_64 OpenSSL: 1.0.2k When reading that you have upgraded to v6.4 - yet still encounter instability - I'd rather go the other way; downgrading. As I stated in my first post, my system started acting very unstable the moment I did the upgrade from 6.1.9 to 6.3.5. Prior to upgrading, it was rock stable (with the exact same hardware, except for the GPU which was switched from Ati HD Radeon 5850 to EVGA GeForce 1060 3GB the same day). My system would have an uptime of several months at the time, running dockers and VMs with passthrough and whatnot. Also, to my knowledge there are no "Marvel" chipset/controllers on my motherboard. I may be wrong. I'll se if I can find any information on downgrading to 6.1.9 without jeopardizing my setup. Let's keep eachother up to speed on the development

Once again my tower locked up, this time while it was streaming Plex content to my appletv... Every time this happens - which are alarmingly frequent after upgrading to 6.3.5 - I lose control on my dedicated console keyboard and screen, as well as the network dropping. After a hard reboot I get my array up and running again, I find this in the Syslog: Dec 21 16:39:42 mothership kernel: ------------[ cut here ]------------ Dec 21 16:39:42 mothership kernel: WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x181/0x1dc Dec 21 16:39:42 mothership kernel: NETDEV WATCHDOG: eth0 (e1000): transmit queue 0 timed out Dec 21 16:39:42 mothership kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod mxm_wmi i2c_i801 i2c_smbus x86_pkg_temp_thermal coretemp i2c_core kvm_intel kvm ahci e1000 libahci video wmi backlight [last unloaded: md_mod] Dec 21 16:39:42 mothership kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.30-unRAID #1 Dec 21 16:39:42 mothership kernel: Hardware name: Gigabyte Technology Co., Ltd. Z170XP-SLI/Z170XP-SLI-CF, BIOS F22c 12/01/2017 Dec 21 16:39:42 mothership kernel: ffff88084ed83db0 ffffffff813a4a1b ffff88084ed83e00 ffffffff819aa12f Dec 21 16:39:42 mothership kernel: ffff88084ed83df0 ffffffff8104d0d9 0000013c4ed83e68 ffff880826ff0000 Dec 21 16:39:42 mothership kernel: ffff880826d2a800 ffff880826ff03a0 0000000000000003 0000000000000001 Dec 21 16:39:42 mothership kernel: Call Trace: Dec 21 16:39:42 mothership kernel: <IRQ> Dec 21 16:39:42 mothership kernel: [<ffffffff813a4a1b>] dump_stack+0x61/0x7e Dec 21 16:39:42 mothership kernel: [<ffffffff8104d0d9>] __warn+0xb8/0xd3 Dec 21 16:39:42 mothership kernel: [<ffffffff8104d13a>] warn_slowpath_fmt+0x46/0x4e Dec 21 16:39:42 mothership kernel: [<ffffffff815a848d>] dev_watchdog+0x181/0x1dc Dec 21 16:39:42 mothership kernel: [<ffffffff815a830c>] ? qdisc_rcu_free+0x39/0x39 Dec 21 16:39:42 mothership kernel: [<ffffffff815a830c>] ? qdisc_rcu_free+0x39/0x39 Dec 21 16:39:42 mothership kernel: [<ffffffff81090ccc>] call_timer_fn.isra.5+0x17/0x6b Dec 21 16:39:42 mothership kernel: [<ffffffff81090da5>] expire_timers+0x85/0x98 Dec 21 16:39:42 mothership kernel: [<ffffffff81090ea5>] run_timer_softirq+0x69/0x8f Dec 21 16:39:42 mothership kernel: [<ffffffff8103642b>] ? lapic_next_deadline+0x21/0x27 Dec 21 16:39:42 mothership kernel: [<ffffffff8109b347>] ? clockevents_program_event+0xd0/0xe8 Dec 21 16:39:42 mothership kernel: [<ffffffff81050f59>] __do_softirq+0xbb/0x1af Dec 21 16:39:42 mothership kernel: [<ffffffff810511fd>] irq_exit+0x53/0x94 Dec 21 16:39:42 mothership kernel: [<ffffffff81036e19>] smp_trace_apic_timer_interrupt+0x7b/0x88 Dec 21 16:39:42 mothership kernel: [<ffffffff81036e2f>] smp_apic_timer_interrupt+0x9/0xb Dec 21 16:39:42 mothership kernel: [<ffffffff81680172>] apic_timer_interrupt+0x82/0x90 Dec 21 16:39:42 mothership kernel: <EOI> Dec 21 16:39:42 mothership kernel: [<ffffffff815533e4>] ? cpuidle_enter_state+0xfe/0x156 Dec 21 16:39:42 mothership kernel: [<ffffffff8155345e>] cpuidle_enter+0x12/0x14 Dec 21 16:39:42 mothership kernel: [<ffffffff8107c545>] call_cpuidle+0x33/0x35 Dec 21 16:39:42 mothership kernel: [<ffffffff8107c727>] cpu_startup_entry+0x13a/0x1b2 Dec 21 16:39:42 mothership kernel: [<ffffffff81035482>] start_secondary+0xf5/0xf8 Dec 21 16:39:42 mothership kernel: ---[ end trace 83c675411c5afb19 ]--- Also, just below this message keeps occuring: Dec 21 16:39:42 mothership kernel: e1000 0000:04:01.0 eth0: Reset adapter Dec 21 16:39:42 mothership kernel: br0: port 1(eth0) entered disabled state Dec 21 16:39:42 mothership kernel: br0: topology change detected, propagating Dec 21 16:39:46 mothership kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Dec 21 16:39:46 mothership kernel: br0: port 1(eth0) entered blocking state Dec 21 16:39:46 mothership kernel: br0: port 1(eth0) entered listening state Dec 21 16:39:46 mothership kernel: dmar_fault: 215 callbacks suppressed Dec 21 16:39:46 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:46 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffc40000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: br0: port 1(eth0) entered learning state Dec 21 16:39:48 mothership kernel: br0: port 1(eth0) entered forwarding state Dec 21 16:39:48 mothership kernel: br0: topology change detected, sending tcn bpdu Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffcde000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffc20000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffd74000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffc4c000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr fff90000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ff61b000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffc2b000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ff5f1000 [fault reason 06] PTE Read access is not set Dec 21 16:39:48 mothership kernel: DMAR: DRHD: handling fault status reg 3 Dec 21 16:39:48 mothership kernel: DMAR: [DMA Read] Request device [04:00.0] fault addr ffde6000 [fault reason 06] PTE Read access is not set Dec 21 16:39:51 mothership kernel: dmar_fault: 4749 callbacks suppressed Whether it is relevant to my troubles, I do not know. I've just about had it with 6.3.5. If anyone would care to give me some pointers on how to get to the bottom of this, I am all ears. If downgrading to 6.1.9 (which I believe was automatically backup up onto my UnRaid-USB stick on upgrade) is an option, I'd also appreciate a guide on how to go about doing it.

Did some additional research. Ended up removing the docker and the appdata folder, reinstalled it and tried setting it up from scratch. Got the api working again by removing the "s" from the URL inside config -> downloaders, and changing the port from 8090 to 8080. SSL seems to be the suspect, perhaps because of certificate fu**up?

Anyone care to help me? I don't really know what has happened, but here goes: hydra cannot get the "categories" from sabnzbdvpn. When tailing the nzbhydra.log, it says "SSLError: [SSL: CERIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)" Though it could be wrong API-key, so i generated a new one in both dockers, but to no avail. It's also been so long since I first set this up, I cannot remember if I am supposed to put any certificates into certain folders or whatnot.

All good! Remounted the array normally now. Thank you for your swift reply and merry christmas!

Got the error with 'valuable metadata changes', but since drive is unmountable I decided just to do 'xfs_repair -vL /dev/md2'

Would need some pre-christmas magic. Long story short: - Tried to cleanly unmount my array for a reboot. Lost the gui. - Tried killing off smbd processes to finish the unmount and restarted the server from the console. - After reboot I got my the gui back. - Logged on through my smartphone and started the array. As the text "mounting array" popped up down in the left hand corner, I lost the connection to the gui again. Managed to SSH in and get the diagnostics. Anyone care to shed some light on this? (betting my SSD is crapping out, as that would explain some very strange VM problems i had earlier tonight) mothership-diagnostics-20171220-2237.zip

Today I upgraded BIOS to version F22C, released only 14 days ago. No hickups yet. Fingers crossed.

iCloud keeps me safe for now, and during the month I'll switch my 12/2MB-connection for 100MB syncronous fiber connection, at which point I intend to subscribe to some cloud backup solution for my entire archive.

Hello! TLDR version; After upgrading from Unraid 6.1.9 to 6.3.5 I have had several complete lockups of the unraid tower. I believe it is related to I/O to the array, as it tends to happen while I host 7Days2Die-server within my Win10 VM, while dockers run directly on my Unraid tower. Never had these problems prior to upgrading to Unraid 6.3.5 I still run the stock BIOS on my mainboard, but are strongly considering flashing it to a more recent release (Gigabyte GA-Z170XP-SLI). Would like some input on how to approach this. Long, detailed version: I build my one and only UnRaid-server about two years back. It´s basically a 10TB array (3 WD Red drives; 3+3+4TB) with one parity (also WD RED 4TB) and a 128GB SSD (HyperX Fury) cache. The hardware is: Gigabyte GA-Z170XP-SLI motherboard Corsair TX 750W PSU Intel Core I5-6600 Skylake CPU Crucial DDR4 2133MHz 32GB (4x8GB) Creative Soundblaster Audigy FX soundcard (passthrough to Win10 VM) A secondary PCI Intel Pro/1000GT NIC One monitor plugged directly into the motherboard VGA-output for Unraid console Another monitor connected to the PCI-express GPU for passthrough to Win10 VM. A keyboard for console. A keyboard and a mouse passed through to the Win10 VM. I´ve kept the amount of "server roles" on a minimum, only running a few dockers, the main one being PlexMediaServer. On top of this I´ve built a Win10VM with GPU-passthrough for work and gaming. This have all been running very very stable, and I cannot recall any scenario in which i had to force a restart on the original build running Unraid 6.1.9. Then, a couple of weeks back problems started: * A friend donated a used 'EVGA GeForce 1060 3GB', which I decided would replace my old trusty 'Ati Radeon HD5850'. One friday night I decided to start working on this, I decided to take the big leap from UnRaid 6.1.9 to 6.3.5 through the 'upgrade'-option under the Plugins-tab. At first reboot after this, I had no network connection to the tower. However another reboot seemed to fix that issue. * I then switched the GPUs, configured my VM accordingly and things seemed to work as it should. * The following days I tried building another VM, this time with osx with VNC-connection. (Although still not working, this is something I'm hellbent on accomplishing.) * Around this point I experienced my first real tower crash while working inside the Win10 VM desktop. Network connection was cut, and so I didn't have any other option than to push the reset button my tower - something I really hate doing. At this point I read that VMs should be configured with OVMF bios, not SeaBios. This should secure that my console monitor/keyboard/mouse would be operational even after the VM were booted, and should give me the possibility to read errors and safely reboot the tower if need be. * Well, last night I had a new crash just after a scheduled file backup from inside the VM to a mapped network drive on the array was finished. Complete lockup both inside the VM and on the console. As the crash occured, i noticed the console monitor flashing all sorts of text. When it stopped typing, this is the image i got from it before once again being forced to press reset: It seems lockups occur when the tower is doing some rather heavy read-write operations to the array. I tend to host a 7Days2Die-server inside the Win10 VM for my wife and a friend, and have always thought that hickups or crashes inside the VM would not affect the Unraid host itself. Last night I thought through this again, and then it occured to me that since the 7D2D-server is stored on the array and mapped inside my VM, the harddisk management or the intensity of read writes to the array could potentially crash the tower even if it was initiated within the VM itself. All in all I feel that the upgrade from 6.1.9 to 6.3.5 is the cause of the problems, or at least have given the problem means to have an devastating affect on my rig. I've tried googling for similar scenarios, but I have not found any cases which match my experiences or are close enough to my build. Last night I found a tip regarding Marvell sata controllers being a source of many headaches, but I haven't found any information suggesting that my mainboard have Marvell sata controller ports. One theory I do have - which I feel I just need an 'approving nod' from the experienced users on these forums on before pursuing - is that the introduction of Unraid 6.3.5 somehow touched upon a bit dodgy code in my BIOS and causes the system to lock up due to some IO-glitch of some sort. I am strongly considering upgrading the BIOS, as I am still running the BIOS that the motherboard came with (released in 2015). Either that, or I just need to downgrade back to Unraid 6.1.9. We keep the photos and homevideos of our children on the PlexMediaServer, and I need to trust the Unraid + online cloud backup keeping my data safe. Please, someone advice me on what to do. I have a dump of the Diagnostics (taken after the reboot) if anyone would like to have a look at them. For the record; I have done memtest. After 3 successfull passes i cancelled the test. Also, how important is it to use the most recent 'VirtIO-drivers' inside the VMs, and could old/faulty drivers cause complete crash of the Unraid host? (Edited for additional information/corrections.)