civic95man

you're accessing the webgui from a different computer or from unraid itself in gui mode? Try a different cable, try another computer on the SAME port of your router/switch. Just rule out all of the variables first.

Need new diagnostics to know for sure. Did the network cable get moved from one port to another? The interface assignments should be saved to /config/network-rules.cfg on your flash drive. So the interface assignments will remain static and shouldn't hop around from one (re)boot to the next. Might need to verify that file. Without knowing more about your setup, you should just be able to connect your cable into the eth0 assigned port.

network settings should show that Diagnostics show this for interface eth2: Settings for eth2: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes The rest show "link detected: no"

diagnostics show that interface eth2 link is active. Did everything jump ship to that?

Some board/cpu combinations can throw an MCE when brought up during a bootup. This may be the case here since it happens very early during the boot process. Try seeing if a new bios is available

Thats the correct place to look. Strange. You could try to delete both rsyslog.cfg and rsyslog.conf in the config directory on the flash drive and set up the "mirror syslog to flash" again. That will clear the syslog server settings and allow you to start over fresh. I guess you could also try to setup a remote syslog server on another computer and have unraid send it there. kiwi syslog server seems to be a popular choice.

verify "Settings" --> "Syslog Server" --> "Mirror syslog to flash" is set to "yes" so we can hopefully capture what happens if the system locks up again

they should be under "logs" on your flash drive yes, that should work. Do note that docker assigns IP addresses itself to the container, not from your network DHCP server. So you may want to setup a valid reserve pool on your DHCP/PFSense box and assign that to the network bridge in docker. That way you won't have address conflicts

Alright, well keep unraid on it's own static IP, use automatic ip assignment on dockers (all), and retest the stability to see what happens. Do you have log mirroring enabled or at least a monitor attached?

If you don't feel like messing with vlans right now and just want to test things out, you can try to disable the static IPs for just the dockers. It's best for unraid itself to keep a static IP and shouldn't be related to your call traces. is your pfsense setup on a vm?

From my experience, this is the cause of the call trace. My understanding is that if you don't have a static IP for your unifi-controller, you're going to have a hard time. I had issues setting it and my network up until I gave the controller a static IP. Same can be said for Plex. Some say that those call traces are harmless, others have had issues when they occur, such as system instability or lockups. Best to not risk it and just get those fixed. My solution to this was to isolate all of my dockers to a separate vlan. I *believe* those call traces are caused by broadcast packets which macvlan doesn't handle well but unifi doesn't seem to route them between vlans. This allowed me to keep the static IPs. As for the btrfs corruption, there may be a correlation between it and the call traces, or it could be something else unrelated. Good luck!

This may seem stupid but did you install both CPUs yourself, and I mean verify that they are both E5630? I read somewhere that someone acquired a second hand server with different CPUs fitted - and it still seemed to boot/work. Not even sure it its possible (also ready that the board can work with differing CPUs) so thats why I ask. It may be a long shot That would be a good starting point to see whats going on

is this dual socket/physical CPUs?

It really depends how you have the cores/threads assigned. It seems that unraid uses the first core (or thread) for it's tasks so that should always be left for unraid. After that, you can assign the rest to whatever you want. I'm sure you know this, but you should always assign threads with their corresponding cores to get the best performance. I always allocate my cores to my VMs from the bottom up

*Maybe* try the 6.9 Beta and see if the new kernel fixes this? I would personally try this either with an earlier beta, before the multiple pools were added, or try it on a spare flash drive to test everything out (or create a backup of your current flash drive and then upgrade to beta)

http://www.avaccess.com/c803.html I would do more research on that one but it's $160 on amazon in the US. Yes, you plug the "transmitter" into the USB and HDMI on your computer. Then plug the "receiver" into your monitor and USB devices (or would it be plugging your USB/Monitor into the receiver 🤔) at the remote location and connect the two with CAT6 cable. Now you "could" connect them to your existing network but as I said, you are sharing bandwidth with everything else in the house.

I've honestly never used one of these before but it is my next planned "upgrade" so that I can keep my server in a cooler part of the house and out of the way. AFAIK, they just sit on your network (plugged into a switch or directly connected to each other) and are "invisible" to other devices. I have heard of them slowing down and/or halting the network so if that is a concern then maybe run a dedicated CAT6 just for that.

You can get a KVM to IP converter. This will route the USB/HDMI to CAT5/6/etc IP traffic. Install one on your server and another at the remote location and connect them via the network. But keep in mind that some don't play very nicely with regular IP traffic so do some homework and the fix for the ryzen based servers are in that link (don't overclock/exceed RAM timings, BIOS settings)

sudo echo 1 > /sys/bus/pci/rescan This should force a complete bus scan and re-add the previously removed (disconnected) device. Shouldn't cause any issues with already attached devices. I'm not around a *nix box at the moment otherwise I would try this, but I wonder if this would work: sudo echo 1 > /sys/bus/pci/devices/0000:XX:XX.X/rescan I'm really curious if this will actually reduce your power consumption

You don't really say what you are currently transcoding from and to. I will assume that you are going from 1080 to 720 or SD. Either way, I would say that a video card would definitely help you out. I believe the P1000 is limited, or locked, to the number of streams, whereas the P2000 is unlimited - or limited only to what will fit into the memory. You shouldn't have any problem with 8-12 concurrent 1080 transcoding streams using the P2000. Video is much more demanding to transcode than audio so you should absolutely see a difference in performance. Keep in mind that you will need a plexpass to take advantage of hardware transcoding.

Try running memtest for a few passes (24 hours to be safe). if that passes then try booting unraid in safemode and see if it continues

Try recreating the flash drive

no, not that I know of. But you can manually assign one Because the VM is grabbing it, not unraid As far as I know, it would be a limitation of the Docker system

Maybe need to set the minimum free space to a larger value? Something greater than the largest file anticipated to be transferred

Sounds like the IP is being handed out by the docker network system since you have automatic assignment selected.