Hawkins12 Posted October 20, 2021 Share Posted October 20, 2021 So I have been having problems with running Live TV through Plex and would swear up and down it was a Plex issue. I would check logs of Plex and constantly encounter issues where Live TV (communication between Plex and HD Homerun device) would stutter. I was believing this was a Plex/HD Homerun device but then I started thinking about my server dropping my mapped network drives among other "odd" occurances like when using PuTTy where it just seems to have trouble on the network. I decided to run Live TV while monitoring server logs and the second my live tv started stuttering, there are the logs that appear in Unraid. I am starting to believe this isn't a plex issue but some sort of network issue related to either Unraid or my hardware. I know this isn't the typical format of providing logs but I wanted to provide the specifics that occurs to the issue. I can provide additional diagnostics if necessary but wasn't sure if something stood out from the below. For reference, server ip is 192.168.1.119 (which I am sure is clear below). Thanks in advance fro your help. Oct 20 11:56:57 HawkinsUnraid kernel: pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:04:00.0 Oct 20 11:56:57 HawkinsUnraid kernel: igb 0000:04:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) Oct 20 11:56:57 HawkinsUnraid kernel: igb 0000:04:00.0: device [8086:1533] error status/mask=00004000/00000000 Oct 20 11:56:57 HawkinsUnraid kernel: igb 0000:04:00.0: [14] CmpltTO Oct 20 11:56:57 HawkinsUnraid kernel: bond0: (slave eth0): link status definitely down, disabling slave Oct 20 11:56:57 HawkinsUnraid kernel: device eth0 left promiscuous mode Oct 20 11:56:57 HawkinsUnraid kernel: bond0: now running without any active interface! Oct 20 11:56:57 HawkinsUnraid kernel: br0: port 1(bond0) entered disabled state Oct 20 11:56:57 HawkinsUnraid kernel: pcieport 0000:00:1c.5: AER: device recovery successful Oct 20 11:56:58 HawkinsUnraid dhcpcd[2125]: br0: carrier lost Oct 20 11:56:58 HawkinsUnraid avahi-daemon[12196]: Withdrawing address record for 192.168.1.119 on br0. Oct 20 11:56:58 HawkinsUnraid avahi-daemon[12196]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.119. Oct 20 11:56:58 HawkinsUnraid avahi-daemon[12196]: Interface br0.IPv4 no longer relevant for mDNS. Oct 20 11:56:58 HawkinsUnraid dhcpcd[2125]: br0: deleting route to 192.168.1.0/24 Oct 20 11:56:58 HawkinsUnraid dhcpcd[2125]: br0: deleting default route via 192.168.1.1 Oct 20 11:56:58 HawkinsUnraid dnsmasq[15575]: no servers found in /etc/resolv.conf, will retry Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: Deleting interface #4820 br0, 192.168.1.119#123, interface stats: received=28, sent=28, dropped=0, active_time=229 secs Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.0 local addr 192.168.1.119 -> <null> Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.4 local addr 192.168.1.119 -> <null> Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.8 local addr 192.168.1.119 -> <null> Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.12 local addr 192.168.1.119 -> <null> Oct 20 11:57:01 HawkinsUnraid kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Oct 20 11:57:01 HawkinsUnraid kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Oct 20 11:57:01 HawkinsUnraid kernel: bond0: (slave eth0): making interface the new active one Oct 20 11:57:01 HawkinsUnraid kernel: device eth0 entered promiscuous mode Oct 20 11:57:01 HawkinsUnraid dhcpcd[2125]: br0: carrier acquired Oct 20 11:57:01 HawkinsUnraid kernel: bond0: active interface up! Oct 20 11:57:01 HawkinsUnraid kernel: br0: port 1(bond0) entered blocking state Oct 20 11:57:01 HawkinsUnraid kernel: br0: port 1(bond0) entered forwarding state Oct 20 11:57:02 HawkinsUnraid dhcpcd[2125]: br0: rebinding lease of 192.168.1.119 Oct 20 11:57:06 HawkinsUnraid dhcpcd[2125]: br0: probing address 192.168.1.119/24 Oct 20 11:57:11 HawkinsUnraid dhcpcd[2125]: br0: leased 192.168.1.119 for 86400 seconds Oct 20 11:57:11 HawkinsUnraid dhcpcd[2125]: br0: adding route to 192.168.1.0/24 Oct 20 11:57:11 HawkinsUnraid dhcpcd[2125]: br0: adding default route via 192.168.1.1 Oct 20 11:57:11 HawkinsUnraid avahi-daemon[12196]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.119. Oct 20 11:57:11 HawkinsUnraid avahi-daemon[12196]: New relevant interface br0.IPv4 for mDNS. Oct 20 11:57:11 HawkinsUnraid avahi-daemon[12196]: Registering new address record for 192.168.1.119 on br0.IPv4. Oct 20 11:57:11 HawkinsUnraid dnsmasq[15575]: reading /etc/resolv.conf Oct 20 11:57:11 HawkinsUnraid dnsmasq[15575]: using nameserver 192.168.1.1#53 Oct 20 11:57:12 HawkinsUnraid ntpd[2200]: Listen normally on 4821 br0 192.168.1.119:123 Oct 20 11:57:12 HawkinsUnraid ntpd[2200]: new interface(s) found: waking up resolver Quote Link to comment
Hawkins12 Posted October 20, 2021 Author Share Posted October 20, 2021 I also figured it might be beneficial to show my Unraid network settings. See picture: I'll note I am confused why I have two Interfaces? I am in no way a technical expert with networking (equipment) but confused on why I have eth0 and eth1 that use the same MAC address. I did "Port Down" the eth1 interface as reflected in the image; however, I still got the issue noted above after that change. Quote Link to comment
Ford Prefect Posted October 21, 2021 Share Posted October 21, 2021 (edited) ...you are running a bonded interface, in active backup mode, build from your two Intel based NICs. Apparently one of these is having problems and when that happens, the active member of the bond will switch over to the other NIC. You need to find out what is actualy killing the link. Does this happen to only the first NIC or does this also happen to the other one? You could try by changing the enumeration, by swapping the MAC addresses for eth0 and eth1. unraid will normally use eth0 as the default, active NIC. The first line of your log indicates that this is not a cabling issue but an issue with your PCI(e) interface the NIC sits on. Also, the Address for both NICs indicate, that these are not on the same BUS address, hence not a DUAL card. Try to disable ASPM in BIOS for the NICS and/or PCIe. If the one(s) that fail are on a external card, try to use/deploy into a different slots. Edited October 21, 2021 by Ford Prefect Quote Link to comment
Hawkins12 Posted October 21, 2021 Author Share Posted October 21, 2021 (edited) 3 hours ago, Ford Prefect said: ...you are running a bonded interface, in active backup mode, build from your two Intel based NICs. Apparently one of these is having problems and when that happens, the active member of the bond will switch over to the other NIC. You need to find out what is actualy killing the link. Does this happen to only the first NIC or does this also happen to the other one? You could try by changing the enumeration, by swapping the MAC addresses for eth0 and eth1. unraid will normally use eth0 as the default, active NIC. The first line of your log indicates that this is not a cabling issue but an issue with your PCI(e) interface the NIC sits on. Also, the Address for both NICs indicate, that these are not on the same BUS address, hence not a DUAL card. Try to disable ASPM in BIOS for the NICS and/or PCIe. If the one(s) that fail are on a external card, try to use/deploy into a different slots. Thanks. I guess I'll check out Board BIOS settings. I'll note that this is not an external card. All NIC's would be integrated with the mobo. I have no separate cards. For reference the Mobo is a Supermicro X12SCZ-F. I know there is a bios update out there for it -- i'll contact Supermicro to see if it relates to the NIC's. I'm always hesitant on the bios updates. Also, I didn't know I had two NIC's. I took a quick look at the Mobo specs and guess you are right. It shows: Network Controllers: Single LAN with Intel® PHY I219LM LAN controller Single LAN with Intel® Ethernet Controller I210-AT Which actually makes sense because I have 3 network ports in the rear i/o: IPMI (Supermicro), LAN2, and LAN1. I am currently only using the LAN2 port. Would you also suggest switching to the LAN1 port and using that? Or wiring both up to the switch? Like i said, I am horrible with my knowledge of networking and am amateur at best :). Thanks for your help and time in responding! Note that LAN2 seems to be linked to the 5E:B5 mac address in my picture above. LAN1 is linked to 5E:B4 which again is not wired into my network switch. Edited October 21, 2021 by Hawkins12 Quote Link to comment
Ford Prefect Posted October 21, 2021 Share Posted October 21, 2021 Ah, yes...you are right. It is always the same NIC that is failing and then recovering again. It is the one named eth0, running the Intel igb driver, from your picture above. Check the bios, especially energy saving features (often called ASPM) and try disabling these...if possible, only for the NICs.You can test the second, if this will behave better, as it uses a different driver in Linux/unraid (e1000e).If you only want to deploy a single link (bond with active backup mode will allow for higher availability, as it will switch over in case of a problem) you could disable bonding in unraid config. Should you keep it, deploy both ports with a patch cable to your switch. Gesendet von meinem SM-G780G mit Tapatalk 1 Quote Link to comment
Hawkins12 Posted October 21, 2021 Author Share Posted October 21, 2021 3 hours ago, Ford Prefect said: Ah, yes...you are right. It is always the same NIC that is failing and then recovering again. It is the one named eth0, running the Intel igb driver, from your picture above. Check the bios, especially energy saving features (often called ASPM) and try disabling these...if possible, only for the NICs. You can test the second, if this will behave better, as it uses a different driver in Linux/unraid (e1000e). If you only want to deploy a single link (bond with active backup mode will allow for higher availability, as it will switch over in case of a problem) you could disable bonding in unraid config. Should you keep it, deploy both ports with a patch cable to your switch. Gesendet von meinem SM-G780G mit Tapatalk Thanks so much for these. Def. going to try these when i get home from business travel. Appreciate your help and time! Quote Link to comment
Hawkins12 Posted October 30, 2021 Author Share Posted October 30, 2021 On 10/21/2021 at 12:22 PM, Ford Prefect said: Ah, yes...you are right. It is always the same NIC that is failing and then recovering again. It is the one named eth0, running the Intel igb driver, from your picture above. Check the bios, especially energy saving features (often called ASPM) and try disabling these...if possible, only for the NICs. You can test the second, if this will behave better, as it uses a different driver in Linux/unraid (e1000e). If you only want to deploy a single link (bond with active backup mode will allow for higher availability, as it will switch over in case of a problem) you could disable bonding in unraid config. Should you keep it, deploy both ports with a patch cable to your switch. Gesendet von meinem SM-G780G mit Tapatalk So I am still testing this but I did not mess with bios settings just yet. I did plug another ethernet cord from the 2nd LAN spot to the switch and it seemed to have made a difference. I havent had the issue for two days. Perhaps i have a bad NIC? Quote Link to comment
Ford Prefect Posted October 30, 2021 Share Posted October 30, 2021 ...perhaps you just have a bad cable, really.Messing with the BIOS as you call it is only a browser tab away, the next time you boot that rig, as you have IPMI If that's a new motherboard, I doubt that there is a defective NIC, but you never know. Try ASPM disable on the NIC first.Gesendet von meinem SM-G780G mit Tapatalk Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.