• Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About K1ng0011

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 11 days and 6 hours of uptime with host access to custom networks disabled. unRAID 6.9.2.
  2. This does not fix the problem but I am using it as a work around. Disabling "host access to custom networks" resolves any lockups for me. When I setup vlans I still had the issue. I prefer not to double NAT so I have always set my dockers network type to Host or Custom: br0 with a static IP. I just moved my two dockers that had static IPs to the bridge network type. This gives them a private IP on their own subnet. This allows the qbittorrent docker I have running with open vpn to still work and my other dockers to access qbittorrent. It allows everything to work without "host access to custom
  3. Is this the same thing as the global c-stste feature that people disable on AM4 motherboards in the bios?
  4. If you look at hoopsters post he reported macvlan call traces in unRAID version 6.5.0 which was released in 2018. This has been an issue for quite a long time. I have seen references that this issue might be related to docker itself and not unRAID but it seems like the issue has not been widespread enough to warrant unRAID reaching out to the people who maintain the docker software. I spent from December 2020 to February 2021 diagnosing this issue on my original motherboard. When I ended up removing my 10 Gig PCIE NIC ASUS XG-C100C from my motherboard the issue stopped. So somehow specific har
  5. Looks like others are now having the issue that I have struggled with. I have had the issue with two different motherboards and on versions of unRAID since 6.8.3. I swapped to a motherboard with IPMI and now I have the macvlan issue return. I resolved the issue on my MSI Pro Carbon x370 by removing my 10 gig PCIE NIC and using the onboard NIC. All of my dockers are currently in host mode or br0.2 with a static IP. I had six days of uptime and then just this morning I had another macvlan call trace come up. Since I installed my new motherboard in I check my logs every morning before I go to wor
  6. Just disabling the VLAN on the NIC did not stop the issue. The dockers that need separate IP addresses I have built onto another VLAN I will watch the logs for a week or so to see if the call traces come back again or not.
  7. Swapped my motherboard out for a ASRockRack X470D4U2-2T to use IPMI with dual 10 gig NICs and the call trace issue has returned. I am going to follow the following post and disable the "Enable VLANs:" setting under my 10 gig NIC and we will see if that makes a difference or not. Unraid 6.9.2 Router: UDM-Pro Switch: USW-Pro-24-PoE
  8. Thank you for taking the time to troubleshoot and diagnose this issue. I would have been lost without this thread. I had a thread open for two months diagnosing my call trace issues. I found out that it is related to my 10gig PCIE NIC that I was using. I removed the NIC and all of my problems have went away. My server was going as far as to completely lock up requiring a hard reset.
  9. No further issues after installing my plugins. I does appear that this is related somehow related to my PCIE 10 gig NIC (ASUS XG-C100C). The problems stopped when I removed it from my server. For reference at this point I have had 30 days of uptime with no further hard locks, errors, or call traces.
  10. I am back. No further call traces, errors, or lockups. I have had the power supply idle control setting set to auto and the global c-states set to auto. This has not caused any further issues. I will install some plugins and see if that causes any issues. At this point I think the issue is related to my 10Gig NIC somehow. However I will install some plugins and report back in another two weeks.
  11. Well is has been about 15 days. No further call traces, errors, or lockups. I logged into the bios and set the power supply idle control setting back to the "auto" setting and I enabled the global c-states option by setting it also to auto. If there are no further errors or issues I will start to reinstall my plugins. I will update this post in two weeks unless I get an error or a hard lockup again.
  12. I was getting call trace errors every two days or so. As of this post I have had 7 days and 20 hours of uptime with no further call traces. I removed my 10 gig PCIE NIC and removed several plugins except the ones I have to have. I have had the "Host access to custom networks" setting enabled under the advanced docker settings along with dockers having their own IP addresses. I am going to let it run for another week. Then I will enable the "AMD Power Supply Idle Control" bios setting and the global C-States option. Let it run for another two weeks. After that I will reinstall my plugins and le
  13. My errors seem to be related to call traces. I am not experienced enough to tell you exactly what they mean but I do see a lot of network related events and I think it is relate to the MACVLAN issue some people can experience with some hardware. I have referenced another thread below where Hoopster reported similar issues. I have currently removed my 10gig PCIE NIC and I am running off my motherboard NIC. We will see if that makes any difference in the call traces. If that does not work I will disable all dockers with separate IPs. I am trying to narrow down what is causing the issue.
  14. Well that did not take as long as I thought. The server did not hard lock up. However I woke up this morning and my dockers stopped working. I looked at the logs and the only errors that I see are call traces. I will post a diagnostic later today. Based on they are showing it appears to be related to the NIC and possibly the macvlan. On some of my docker containers I do run a separate IP address than the host IP. I am not sure if this is due to the separate 10gig NIC I have and it has compatibility issues with macvlan or not. I think there are two options at this point that I can try. Disable
  15. Also I have a LSI 9201-16i. It was on an older firmware and bios F: B: I just loaded the newest bios and firmware on the LSI card. I dont think this has been causing my lockups but might as well rule it out a potential cause