Jerem

I'm writing to share an update about my experience with my ASUS ROG Strix X670E-E motherboard (paired with an AMD Ryzen 9 7900X processor - sorry I mentioned the wrong processor in my initial post) regarding BIOS voltage controls and the subsequent unhelpful support from ASUS. My goal was to apply a slight positive CPU voltage offset, as is a common recommendation for optimizing stability in some Unraid configurations. However, I discovered that the BIOS on my ASUS ROG Strix X670E-E only allows for negative voltage offsets, completely preventing me from applying the desired positive adjustment. I've had multiple discussions with ASUS technical support, and their responses have been inconsistent and ultimately unhelpful: Initial Misinformation: They initially told me that I needed to disable certain BIOS options to "unlock" the positive offset, which proved to be incorrect. Sudden Policy Change / Contradiction: Later, they claimed that the restriction on positive voltage offset was a "deliberate implementation by ASUS, heavily influenced by recent AMD AGESA updates for Ryzen 7000 series processors," citing a protective measure against potential hardware degradation due to a 1.30V SoC voltage cap. This explanation feels like "bullshit" to me, as it contradicts their earlier advice and seems like a cover-up for a poorly designed or implemented BIOS feature. Many other motherboards from different manufacturers allow for positive voltage offsets, and the justification provided by ASUS seems to indicate a fundamental misunderstanding or unwillingness to properly implement standard voltage control features for Ryzen 7000 series CPUs. It appears their development team is out of touch with enthusiast needs and proper BIOS functionality. Given this ongoing frustration and the apparent lack of understanding or willingness to truly help from ASUS support, I've decided to replace the motherboard. I've just ordered a cheaper MSI motherboard (MSI MAG B650 Tomahawk) from Amazon, and I intend to report back on its stability with Unraid once I've made the swap. My hope is that MSI's BIOS is more stable and properly implemented. This experience has led me to conclude that I will never purchase another ASUS product. The BIOS is poorly designed, and the overall hardware feels gimmicky, especially when compared to competitors who seem to offer more stable and functional solutions at a lower price point. I regret not paying more attention to common forum sentiments about this brand. Has anyone else experienced similar issues with ASUS motherboards or encountered such contradictory and unhelpful support regarding voltage offsets for Ryzen 7000 series CPUs?

Thanks. My server is already behind a beefy UPS, so it is not the issue root cause in my case.

Thank you @JorgeB. I am going to try increasing the CPU voltage supply as suggested by your comment below and revert to this forum after a few weeks. "NEW: If you are having random reboots with Ryzen 5000 series, particularly the higher-end models of 5950X and 5900X, it may help to increase the CPU voltage supply, see: https://wiki.archlinux.org/title/Ryzen#Random_reboots "

Here’s what appears in the syslogs just before a crash when Unraid becomes unresponsive. Any help would be appreciated. The issue seems to occur mostly after I modify or add new Docker containers. It’s especially frustrating because my system is well-equipped—128GB RAM, a powerful AMD Ryzen 7 5700X (on an Unraid 7.0.1 setup), and CPU/RAM usage rarely exceeds 10%. I’ve also done the basics: disabled Ai Tweaker, ASPM, and C-states in BIOS, while enabling IOMMU and SR-IOV. Still, the problem persists, and it’s driving me nuts. Any insights would be greatly appreciated! Apr 26 15:36:17 Tower kernel: docker0: port 7(vethfd76cb9) entered blocking state Apr 26 15:36:17 Tower kernel: docker0: port 7(vethfd76cb9) entered disabled state Apr 26 15:36:17 Tower kernel: vethfd76cb9: entered allmulticast mode Apr 26 15:36:17 Tower kernel: vethfd76cb9: entered promiscuous mode Apr 26 15:36:18 Tower kernel: eth0: renamed from veth89c66ac Apr 26 15:36:18 Tower kernel: docker0: port 7(vethfd76cb9) entered blocking state Apr 26 15:36:18 Tower kernel: docker0: port 7(vethfd76cb9) entered forwarding state Apr 26 15:36:33 Tower kernel: docker0: port 10(vethede46a9) entered blocking state Apr 26 15:36:33 Tower kernel: docker0: port 10(vethede46a9) entered disabled state Apr 26 15:36:33 Tower kernel: vethede46a9: entered allmulticast mode Apr 26 15:36:33 Tower kernel: vethede46a9: entered promiscuous mode Apr 26 15:36:33 Tower kernel: eth0: renamed from veth94236f4 Apr 26 15:36:33 Tower kernel: docker0: port 10(vethede46a9) entered blocking state Apr 26 15:36:33 Tower kernel: docker0: port 10(vethede46a9) entered forwarding state Apr 26 15:45:51 Tower webgui: Successful login user root from 192.168.1.1 Apr 26 15:48:49 Tower webgui: Successful login user root from 192.168.1.49 Apr 26 15:59:22 Tower kernel: docker0: port 10(vethede46a9) entered disabled state Apr 26 15:59:22 Tower kernel: veth94236f4: renamed from eth0 Apr 26 15:59:22 Tower kernel: docker0: port 10(vethede46a9) entered disabled state Apr 26 15:59:22 Tower kernel: vethede46a9 (unregistering): left allmulticast mode Apr 26 15:59:22 Tower kernel: vethede46a9 (unregistering): left promiscuous mode Apr 26 15:59:22 Tower kernel: docker0: port 10(vethede46a9) entered disabled state Apr 26 15:59:23 Tower kernel: docker0: port 10(veth30670f0) entered blocking state Apr 26 15:59:23 Tower kernel: docker0: port 10(veth30670f0) entered disabled state Apr 26 15:59:23 Tower kernel: veth30670f0: entered allmulticast mode Apr 26 15:59:23 Tower kernel: veth30670f0: entered promiscuous mode Apr 26 15:59:23 Tower kernel: eth0: renamed from veth43b4507 Apr 26 15:59:23 Tower kernel: docker0: port 10(veth30670f0) entered blocking state Apr 26 15:59:23 Tower kernel: docker0: port 10(veth30670f0) entered forwarding state Apr 26 16:05:59 Tower kernel: docker0: port 16(vethc764422) entered blocking state Apr 26 16:05:59 Tower kernel: docker0: port 16(vethc764422) entered disabled state Apr 26 16:05:59 Tower kernel: vethc764422: entered allmulticast mode Apr 26 16:05:59 Tower kernel: vethc764422: entered promiscuous mode Apr 26 16:05:59 Tower kernel: eth0: renamed from vethdfab85a Apr 26 16:05:59 Tower kernel: docker0: port 16(vethc764422) entered blocking state Apr 26 16:05:59 Tower kernel: docker0: port 16(vethc764422) entered forwarding state Apr 26 16:41:47 Tower kernel: docker0: port 16(vethc764422) entered disabled state Apr 26 16:41:47 Tower kernel: vethdfab85a: renamed from eth0 Apr 26 16:41:47 Tower kernel: docker0: port 16(vethc764422) entered disabled state Apr 26 16:41:47 Tower kernel: vethc764422 (unregistering): left allmulticast mode Apr 26 16:41:47 Tower kernel: vethc764422 (unregistering): left promiscuous mode Apr 26 16:41:47 Tower kernel: docker0: port 16(vethc764422) entered disabled state Apr 26 17:17:31 Tower kernel: docker0: port 9(veth33e1621) entered disabled state Apr 26 17:17:31 Tower kernel: veth91e3459: renamed from eth0 Apr 26 17:17:31 Tower kernel: docker0: port 9(veth33e1621) entered disabled state Apr 26 17:17:31 Tower kernel: veth33e1621 (unregistering): left allmulticast mode Apr 26 17:17:31 Tower kernel: veth33e1621 (unregistering): left promiscuous mode Apr 26 17:17:31 Tower kernel: docker0: port 9(veth33e1621) entered disabled state Apr 26 17:17:35 Tower kernel: docker0: port 9(veth42fda09) entered blocking state Apr 26 17:17:35 Tower kernel: docker0: port 9(veth42fda09) entered disabled state Apr 26 17:17:35 Tower kernel: veth42fda09: entered allmulticast mode Apr 26 17:17:35 Tower kernel: veth42fda09: entered promiscuous mode Apr 26 17:17:35 Tower kernel: eth0: renamed from vethc72059d Apr 26 17:17:35 Tower kernel: docker0: port 9(veth42fda09) entered blocking state Apr 26 17:17:35 Tower kernel: docker0: port 9(veth42fda09) entered forwarding state Apr 26 17:17:41 Tower kernel: docker0: port 7(vethfd76cb9) entered disabled state Apr 26 17:17:41 Tower kernel: veth89c66ac: renamed from eth0 Apr 26 17:17:41 Tower kernel: docker0: port 7(vethfd76cb9) entered disabled state Apr 26 17:17:41 Tower kernel: vethfd76cb9 (unregistering): left allmulticast mode Apr 26 17:17:41 Tower kernel: vethfd76cb9 (unregistering): left promiscuous mode Apr 26 17:17:41 Tower kernel: docker0: port 7(vethfd76cb9) entered disabled state Apr 26 17:17:49 Tower kernel: docker0: port 10(veth30670f0) entered disabled state Apr 26 17:17:49 Tower kernel: veth43b4507: renamed from eth0 Apr 26 17:17:49 Tower kernel: docker0: port 10(veth30670f0) entered disabled state Apr 26 17:17:49 Tower kernel: veth30670f0 (unregistering): left allmulticast mode Apr 26 17:17:49 Tower kernel: veth30670f0 (unregistering): left promiscuous mode Apr 26 17:17:49 Tower kernel: docker0: port 10(veth30670f0) entered disabled state Apr 26 17:23:59 Tower nginx: 2025/04/26 17:23:59 [error] 2102661#2102661: *2092580 open() "/usr/local/emhttp/plugins/compose.manager/javascript/ace/mode-sh.js" failed (2: No such file or directory) while sending to client, client: 192.168.1.1, server: , request: "GET /plugins/compose.manager/javascript/ace/mode-sh.js HTTP/1.1", host: "unraid.jeremierenard.com", referrer: "https://unraid.jeremierenard.com/Settings/compose.manager" Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered blocking state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered disabled state Apr 26 17:30:56 Tower kernel: veth8b7ce82: entered allmulticast mode Apr 26 17:30:56 Tower kernel: veth8b7ce82: entered promiscuous mode Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered blocking state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered forwarding state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered disabled state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered blocking state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered disabled state Apr 26 17:30:56 Tower kernel: veth281aacc: entered allmulticast mode Apr 26 17:30:56 Tower kernel: veth281aacc: entered promiscuous mode Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered blocking state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered forwarding state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered disabled state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered blocking state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered disabled state Apr 26 17:30:56 Tower kernel: veth20a56fc: entered allmulticast mode Apr 26 17:30:56 Tower kernel: veth20a56fc: entered promiscuous mode Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered blocking state Apr 26 17:30:56 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered forwarding state Apr 26 17:30:57 Tower kernel: eth0: renamed from vethbdbf0b0 Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered disabled state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered blocking state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered forwarding state Apr 26 17:30:57 Tower kernel: eth0: renamed from vethcfe38cc Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered blocking state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 3(veth20a56fc) entered forwarding state Apr 26 17:30:57 Tower kernel: eth0: renamed from veth2c6f2d7 Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered blocking state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 2(veth281aacc) entered forwarding state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered blocking state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered disabled state Apr 26 17:30:57 Tower kernel: veth4efa799: entered allmulticast mode Apr 26 17:30:57 Tower kernel: veth4efa799: entered promiscuous mode Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered blocking state Apr 26 17:30:57 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered forwarding state Apr 26 17:30:57 Tower kernel: eth0: renamed from vethcfff6e4 Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered disabled state Apr 26 17:31:01 Tower kernel: vethcfff6e4: renamed from eth0 Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered disabled state Apr 26 17:31:01 Tower kernel: veth4efa799 (unregistering): left allmulticast mode Apr 26 17:31:01 Tower kernel: veth4efa799 (unregistering): left promiscuous mode Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(veth4efa799) entered disabled state Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered blocking state Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered disabled state Apr 26 17:31:01 Tower kernel: vethbd845b0: entered allmulticast mode Apr 26 17:31:01 Tower kernel: vethbd845b0: entered promiscuous mode Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered blocking state Apr 26 17:31:01 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered forwarding state Apr 26 17:31:01 Tower kernel: eth0: renamed from veth3d994e3 Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered disabled state Apr 26 17:31:04 Tower kernel: veth3d994e3: renamed from eth0 Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered disabled state Apr 26 17:31:04 Tower kernel: vethbd845b0 (unregistering): left allmulticast mode Apr 26 17:31:04 Tower kernel: vethbd845b0 (unregistering): left promiscuous mode Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(vethbd845b0) entered disabled state Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered blocking state Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered disabled state Apr 26 17:31:04 Tower kernel: veth78fbce4: entered allmulticast mode Apr 26 17:31:04 Tower kernel: veth78fbce4: entered promiscuous mode Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered blocking state Apr 26 17:31:04 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered forwarding state Apr 26 17:31:04 Tower kernel: eth0: renamed from veth870027e Apr 26 17:36:46 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered disabled state Apr 26 17:36:46 Tower kernel: vethbdbf0b0: renamed from eth0 Apr 26 17:36:46 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered disabled state Apr 26 17:36:46 Tower kernel: veth8b7ce82 (unregistering): left allmulticast mode Apr 26 17:36:46 Tower kernel: veth8b7ce82 (unregistering): left promiscuous mode Apr 26 17:36:46 Tower kernel: br-3e6c5ee2b13e: port 1(veth8b7ce82) entered disabled state Apr 26 17:36:46 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered disabled state Apr 26 17:36:46 Tower kernel: veth870027e: renamed from eth0 Apr 26 17:36:46 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered disabled state Apr 26 17:36:46 Tower kernel: veth78fbce4 (unregistering): left allmulticast mode Apr 26 17:36:46 Tower kernel: veth78fbce4 (unregistering): left promiscuous mode Apr 26 17:36:46 Tower kernel: br-3e6c5ee2b13e: port 4(veth78fbce4) entered disabled state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered blocking state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered disabled state Apr 26 17:36:47 Tower kernel: veth43c7006: entered allmulticast mode Apr 26 17:36:47 Tower kernel: veth43c7006: entered promiscuous mode Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered blocking state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered forwarding state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered blocking state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered disabled state Apr 26 17:36:47 Tower kernel: vethfedff53: entered allmulticast mode Apr 26 17:36:47 Tower kernel: vethfedff53: entered promiscuous mode Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered blocking state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered forwarding state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered disabled state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered disabled state Apr 26 17:36:47 Tower kernel: eth0: renamed from veth4e1e068 Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered blocking state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 1(veth43c7006) entered forwarding state Apr 26 17:36:47 Tower kernel: eth0: renamed from veth6675e92 Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered blocking state Apr 26 17:36:47 Tower kernel: br-3e6c5ee2b13e: port 4(vethfedff53) entered forwarding state Apr 26 17:56:18 Tower nginx: 2025/04/26 17:56:18 [error] 2102661#2102661: *2114957 open() "/usr/local/emhttp/plugins/compose.manager/javascript/ace/mode-sh.js" failed (2: No such file or directory) while sending to client, client: 192.168.1.49, server: , request: "GET /plugins/compose.manager/javascript/ace/mode-sh.js HTTP/1.1", host: "192.168.1.78", referrer: "http://192.168.1.78/Settings/compose.manager"

thanks the problem has disappeared.

The "Fix Common Problems" plugin is finding the following problem "Out Of Memory errors detected on your server". The diagnostics are attached. Anybody has any tip on what I should have a look at? Thanks heaps. tower-diagnostics-20241225-1202.zip

Unraid has not crashed for 1 month and 10 days after I deactivated the ASPM in the BIOS! Thank you @JayDee73! ASPM deactivation was the key BIOS parameter that solved the issue. For reference, you can see in the screenshot attached all the BIOS parameters values that I end up changing compared to the BIOS default values.

Thank you very much. I have just deactivated the ASPM in the BIOS (C-state was already disabled in BIOS and I have not installed powertop in Unraid). I will continue to monitor the server and revert to this forum with updates.

Yes, this the Intel 2.5 Gb Ethernet NIC onboard the ROG STRIX X670E-E motherboard.

Thank you very much for your quick answer and for sharing the script! I give myself a few more weeks and I will continue to troubleshoot to see if there is a permanent fix and I will revert here if I find the solution. If I can't, I will definitely use the workaround script. Thanks again for sharing.

Hi @j5i7. Have you managed to fix the issue? I have exactly the same symptoms but I am not using a ASUS ROG STRIX B660-I GAMING WIFI BIOS 2012 10/11/2022 motherboard but instead I am using a ASUS ROG STRIX X670E-E GAMING WIFI, BIOS 2308 09/05/2024. I am tempted to try a dedicated PCIe ethernet card. These spodaric loss of conectivity are driving me nuts. Thanks.

Hi. I had an unraid server stable for several years running 7/7 - 365 . I recently upgraded to a new more powerful hardware based on an AMD CPU. I kept on getting weekly crashes when unraid becomes totally unresponsive on the network. I already did a few changes suggested on forums (Global c-state disabled, reduce frequency of RAM just in case as I am NOT doing any overclocking anyway) but the issues are stil ocurring. This is driving me nuts. That said when the server becomes totally unresponsive it still responds to me pressing the physical power shutdown and then does a graceful shutdown. Below is an extract of the syslog just when the unresponsiveness is triggered. Any help would be appreciated. log.txt

I have uninstalled the antivirus on both my local Win 11 PC and win 11 VM, and still have exactly the same intermittent RDP error.

I am running the free version of Bitdefender on both my local Win 11 PC and win 11 VM.

Unfortunately, the same RDP disconnections symptoms with the new Windows local user account are still occuring. What shall we try next?

Hi Jonathan. Thank you for your message. I have created a new user account on this Win 11 VM and I am testing with RDP. I will revert back with the results soon.

Unfortunately, I’m still experiencing persistent disconnections, despite the fact that the RDP is not permitted from the WAN. I’m not considering logging in as a different user because there’s only one user account (the admin account) on this Virtual Machine (VM), and it’s associated with my Microsoft account. Any other suggestions?

Thank you Jonathan. I will try your recommendations and reports back. I have just disabled the firewall rule on the PFsense that allows RDP on the WAN (It was only allowing traffic very specific IP addresses anyway that I specified). I will try to change the user too and report back.

Hello, I’ve been a successful Unraid user for years, and this is the first time I’ve encountered an issue that requires assistance. I’m currently running the latest version of Unraid, hosting multiple Docker containers and a Windows 11 VM. For years, I’ve been connecting to the Windows 11 VM via RDP on my LAN without any issues. I use this VM daily for about 8 hours to run Microsoft Office applications. However, I’ve recently started experiencing frequent RDP disconnections. The error message I receive is: “You have been disconnected because another connection was made to the remote computer. Error code: 0x3. Extended error code: 0x5.” I’ve checked the logs of my VM and didn’t find anything unusual. I also don’t suspect any issues with my PFsense DHCP server or my TP-Link switch. I would appreciate any suggestions or assistance in troubleshooting this issue. Thank you very much!

+1. I would love to use my PFsense router DHCP service for the Unraid Docker containers.