Marshalleq

Members
 View Profile  See their activity

  • Posts

    968

  • Joined

  • Last visited

 Content Type 

Everything posted by Marshalleq

  1. Marshalleq
    Thanks good to know - I am not sure what's going on yet, there are other related issues that may be playing into it. For example my dual port Nic pings on both ports while only one port is plugged in. Neither are bonded and there is no shared bridge. I did see they're using the e1000e driver which according to intel is incorrect - it should be e1000 - so could be something there. But that's the PCI stuff and the problems I'm having is with the onboard. Anyway - I got so grumpy with it this morning that my chiropractor commented how tense I was 7 hours later - so clearly done enough of that today!
  2. Marshalleq
    I think random number generators are pretty standard in all *nix operating systems. I would guess it's not actually an Unraid specific thing, rather a linux specific thing. Someone else can chime in what they're actually used for, but suspect google will tell you that too. I think crypto stuff like ssh and ssl use it (or similar) for a start but someone may correct me.
  3. Marshalleq
    Can you confirm 100% routed traffic also goes through that? Maybe yours is a different scenario, I'm having a really hard time getting traffic to go away from my onboard ethernet. Even disabling it in the motherboard doesn't work. And when I move another interface to ETH0 it keeps the gateway on the new name for the onboard - so default route is now on eth2. I have even completely deleted the network config by removing the cfg file, assigned the correct interface to Eth0, ensured that the default route is going to ETH0 (not onboard) then upon reboot it reverts the default route back to the onboard (now ETH2). I had to put a dummy subnet on it to get it to work. 25+ years doing plenty of IT technical work at an enterprise level and Unraid is stumping me.
  4. Marshalleq
    I have my doubts if that will fully work, but I will try it tomorrow - thanks for pointing it out. I saw it 100 times today and didn't think of using it like that lol. My problem is I've got ETH0 selected correctly now, but the default gateway still insists on being the motherboard NIC. I ended up just putting a false private subnet on that to get around it, otherwise the whole server couldn't talk to the internet.
  5. Marshalleq
    According to the main intel NIC driver download page linked below, a dual port NIC should not have the e1000e driver, it should have the e1000 driver. If I'm reading correctly and I think I am. Therefore my dual port NIC is getting the wrong driver from Unraid. This might explain why I'm getting weird issues with this NIC on Unraid - I've just had both ports show up with the same Mac address a moment ago too - even though it lists them as different below that. https://downloadmirror.intel.com/20927/eng/e1000.htm
  6. Marshalleq
    Argh - I've just spent ages going through the options landing here, implemented it, wondering why the rules file was there already (thought maybe I put it there) then reading the last message is it's now native. Could someone should put this last comment about it now being native in the first post?
  7. Marshalleq
    It would appear as if the stub method no longer works in 6.7.0 RC7. Can anyone confirm if it works for them? Guess I'll try the udev method. Such a drama for something that should be easy.
  8. Marshalleq
    After now fiddling with default ethernet ports and realising this is one of the really not nice parts of Unraid, I thought I should create as a feature request as it appears nobody else has specifically requested the whole solution. It would be great if the GUI could be improved to include: 1 - Assign any interface to any user chosen network designation in the system e.g. ETH0/1/2 2 - Ports could be clearly disabled when required via software (presently they still show up if disabled in hardware - so it's confusing as hell and you're not sure exactly what Unraid will try and do) 3 - The links between port designations to bridges were clearer i.e. ETH0 -> BR1 displayed visually 4 - That the system didn't completely disable the network and lock you out requiring reboots from physical machine when these changes are made (frustrating as hell when trying to work on a headless system) 5 - A default port could be chosen other than ETH0 6 - A default bridge could be selected in the docker settings similar to what can already be done in the VM settings 7 - An existing bridge can have other interfaces in it and not have the ETH0 interface in it (Currently if adding eth1 to the eth0 bridge you cannot remove eth0 via the GUI) - you can create a new bridge but this then requires you change it individually on all the dockers etc) 8 - The host setting in docker has a way of assigning it to an interface / designation - (currently it's stuck to ETH0 causing me grief) 9 - A 'reset network to defaults' option via the GUI without having to delete the file on the USB Stick 10 - Ability to change default route properly - even after running udev rules to fix incorrect eth assignments, disabling cards in BIOS, and deleting the network config entirely, Unraid continues to insist that the original onboard NIC must have the default route. This shouldn't be this hard. I would say a sort of software switch GUI would be the ultimate way of designing this - QNAP does it so I'm sure there's a ton of already designed open source solutions out there, nevertheless from the above (even if I have gotten one or two of these wrong), there's a bit to improve on in my opinion, that I think could be done quite easily.. Changing these (I'm sure there are others) would make a marked improvement to the networking capabilities of Unraid, which with all due credit for the other features in Unraid in my opinion is quite poorly set up at present. Many thanks.
  9. Marshalleq
    Obviously I understand how possibly it might be required to reboot Unraid after a network reconfig, even if it is linux. However, what I don't think is right is that all network traffic is lost on a headless system after reconfiguring it to the point that I can't even reboot it without heading off to where the headless system is and pressing the power button. Even with multiple network cards where more than one has not changed, I cannot connect vi a browser, ssh or anything. In fact ping is lost across all interfaces. This isn't specific to this beta, but in my opinion should be fixed. One of two scenarios should happen: 1 - The network interfaces are changed requiring a reboot, but not changes happen until the reboot 2 - The network interfaces are changed not requiring a reboot and all changes happen without the reboot. This should be a piece of cake with linux! Thanks for reading.
  10. Marshalleq
    I'm getting quite a few of these on my system. Page Fault never sounds good to me. Log's attached. Apr 25 15:00:27 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000e0d77000 flags=0x0000] Apr 25 15:00:27 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000ff73d000 flags=0x0000] Apr 25 15:00:27 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000e0d76000 flags=0x0000] Apr 25 15:00:27 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000e0d75000 flags=0x0000] Apr 25 15:00:30 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000e0d77000 flags=0x0000] Apr 25 15:00:30 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f77c0000 flags=0x0000] Apr 25 15:00:30 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fb780000 flags=0x0000] Apr 25 15:00:30 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fe67f000 flags=0x0000] Apr 25 15:00:30 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f7ef0000 flags=0x0000] Apr 25 15:00:31 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f877f000 flags=0x0000] Apr 25 15:00:31 Obi-Wan kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=09:00.0 domain=0x0000 address=0x00000000f9000000 flags=0x0000] Apr 25 15:00:32 Obi-Wan kernel: amd_iommu_report_page_fault: 1 callbacks suppressed Apr 25 15:00:32 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fbea8000 flags=0x0000] Apr 25 15:00:33 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fe676000 flags=0x0000] Apr 25 15:00:33 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fe650000 flags=0x0000] Apr 25 15:00:33 Obi-Wan kernel: nvme 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fecb9000 flags=0x0000] Apr 25 15:00:33 Obi-Wan root: /etc/libvirt: 921.7 MiB (966504448 bytes) trimmed on /dev/loop3 Apr 25 15:00:33 Obi-Wan root: /var/lib/docker: 79.3 GiB (85107757056 bytes) trimmed on /dev/loop2 Apr 25 15:00:33 Obi-Wan root: /mnt/disks/SAMSUNG_MZ7KM960HAHP-00005_S2HTNYAG700753: 739.3 GiB (793801342976 bytes) trimmed on /dev/sdj1 Apr 25 15:00:33 Obi-Wan root: /mnt/cache: 118.6 GiB (127382278144 bytes) trimmed on /dev/nvme0n1p1 obi-wan-diagnostics-20190423-0509.zip
  11. Marshalleq
    OK, just uploaded so many logs recently lol. Thought I'd start with the is it normal and go from there. Yes latest bios on ASUS X299-A motherboard. I had been waiting for a CrashPlan block sync to finish. The system had only been running 3 or four days, however after a reboot and changing a few things the problem has stopped for now. Though I had noticed rebooting would temporarily fix my VM / GPU issues for a day or two getting progressively worse. To that end I'll monitor it and see what happens. The Threadripper motherboard is certainly more complex than my Ryzen 1800x one was. When the system was down I managed to add a second NIC to my machine which I've dedicated (non-passthrough) to my VM for now - though even that is behaving weird as per my other post. I've included my logs from before the reboot, will include more recent ones after the issue re-occurs. Thanks. obi-wan-diagnostics-20190423-0509.zip
  12. Marshalleq
    I've only just plugged this card back in, though I am now on a different computer. My setup is displaying peculiar behaviour as follows: Onboard NIC Eth0: Cable plugged in - ping works Dual Port NIC Eth1: Cable plugged in - ping works Dual Port NIC Eth2: Cable unplugged - ping works If I swap the port the cable is in: Onboard NIC Eth0: Cable Plugged in - ping works Dual Port NIC Eth1: Cable unplugged in - no rely from ping Dual Port NIC Eth2: Cable plugged in - no reply from ping Anyone have any bright ideas why an unplugged port responds to a ping? I don't think this is a hardware issue - seems more like a driver issue? I assume having the onboard ethernet mixed in this IOMMU Group would only matter if I wanted to pass it through to something, that this wouldn't be causing the interface to go up and down as it has been. IOMMU group 15:[1022:43ba] 01:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset USB 3.1 xHCI Controller (rev 02) [1022:43b6] 01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset SATA Controller (rev 02) [1022:43b1] 01:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset PCIe Bridge (rev 02) [1022:43b4] 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [8086:1539] 05:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) [1b21:2142] 08:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller IOMMU group 18:[8086:105e] 0b:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06) IOMMU group 19:[8086:105e] 0b:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06) Many thanks for any advice.
  13. Marshalleq
    It’s onboard. I’m going to add a pci dual Nic by intel tomorrow though.
  14. Marshalleq
    Thanks. Yes, I think those are different as with yours there is not a primary network connection going down and up, whereas with mine, I think it is.
  15. Marshalleq
    When I start a windows VM (or seemingly any other VM), I get a lot of these errors (hundreds maybe thousands in a row) and the Tianocore bios takes ages to start up. Once it does, these errors seem to stop. Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: AER: Multiple Corrected error received: 0000:00:00.0 Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: device [1022:1453] error status/mask=000011c0/00006000 Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: [ 6] BadTLP Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: [ 7] BadDLLP Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: [ 8] Rollover Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: [12] Timeout Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: AER: Multiple Corrected error received: 0000:00:00.0 Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: device [1022:1453] error status/mask=000000c0/00006000 Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: [ 6] BadTLP Apr 24 20:05:26 Obi-Wan kernel: pcieport 0000:40:03.1: [ 7] BadDLLP Apr 24 20:05:26 Obi-Wan kernel: vfio_ecap_init: 0000:41:00.0 hiding ecap 0x19@0x900 Looking up what the PCI device is 000:40:03:1 is as follows: IOMMU group 26:[1022:1453] 40:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge I'm wondering if this is part of why my gaming VM is having issues, but otherwise generally can anyone comment on if this is normal or not? Thanks.
  16. Marshalleq
    I've already checked cables, changed the switch port, I still can't try a new NIC because CrashPlan and it's block sync is on it's third day sigh and stopping it would be beginning from the beginning! I think it will be finished tomorrow. I have my doubts about the switch being an issue, I can check on another linux box if it is having a similar issue, but I doubt it. Thanks for your input, will try card next.
  17. Marshalleq
    I've now powered down and up the switch (which didn't work), and have now just tried enabling flow control on the switch port - probably not working but because Unraid seems to have pause on in RX mode. Tomorrow will try another cable and another NIC. I'm thinking it's software though.
  18. Marshalleq
    So thinking through if this is normal or not and how to test it, I ran a ping with a timestamp. First the error (yet another one), then the ping. Apr 23 17:12:13 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Apr 23 17:12:13 Obi-Wan kernel: br0: port 1(eth0) entered disabled state Apr 23 17:12:15 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Apr 23 17:12:15 Obi-Wan kernel: br0: port 1(eth0) entered blocking state Apr 23 17:12:15 Obi-Wan kernel: br0: port 1(eth0) entered forwarding state Tue Apr 23 17:12:09 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=191 ttl=64 time=0.472 ms Tue Apr 23 17:12:10 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=192 ttl=64 time=0.440 ms Tue Apr 23 17:12:11 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=193 ttl=64 time=0.176 ms Tue Apr 23 17:12:12 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=194 ttl=64 time=0.194 ms Tue Apr 23 17:12:16 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=198 ttl=64 time=0.144 ms Tue Apr 23 17:12:17 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=199 ttl=64 time=0.274 ms Tue Apr 23 17:12:18 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=200 ttl=64 time=0.270 ms Tue Apr 23 17:12:19 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=201 ttl=64 time=0.416 ms You can see, while the NIC was down at 17:12:13 to 17:12:15, pings stopped (see 17:12:12 then 17:12:16. Coincidence? I don't think so. Whether this makes much of a difference to anything I don't know, but I could see in an online game how having the network down for four whole seconds might wreak some havoc.
  19. Marshalleq
    Apr 23 16:34:01 Obi-Wan kernel: mdcmd (248): spindown 0 Apr 23 16:34:03 Obi-Wan kernel: mdcmd (249): spindown 6 Apr 23 16:36:34 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Apr 23 16:36:34 Obi-Wan kernel: br0: port 1(eth0) entered disabled state Apr 23 16:36:36 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Apr 23 16:36:36 Obi-Wan kernel: br0: port 1(eth0) entered blocking state Apr 23 16:36:36 Obi-Wan kernel: br0: port 1(eth0) entered forwarding state I just got another one while typing this (am just doing a live tail on the syslog) - this one appears to be more about docker I think being a bridge. I am actually now unsure if these are normal ie part of just a docker restart or if the interface is actually restarting for the whole system? Apr 23 17:03:10 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Apr 23 17:03:10 Obi-Wan kernel: br0: port 1(eth0) entered disabled state Apr 23 17:03:12 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Apr 23 17:03:13 Obi-Wan ntpd[2659]: Deleting interface #58 br0, 192.168.43.10#123, interface stats: received=12, sent=12, dropped=0, active_time=5880 secs Apr 23 17:03:13 Obi-Wan ntpd[2659]: 192.168.43.3 local addr 192.168.43.10 -> <null> Apr 23 17:03:13 Obi-Wan ntpd[2659]: Deleting interface #59 br0, fe80::24d8:79ff:fe01:a2fc%9#123, interface stats: received=0, sent=0, dropped=0, active_time=5880 secs Apr 23 17:03:13 Obi-Wan kernel: br0: port 1(eth0) entered blocking state Apr 23 17:03:13 Obi-Wan kernel: br0: port 1(eth0) entered forwarding state Apr 23 17:03:15 Obi-Wan ntpd[2659]: Listen normally on 60 br0 192.168.43.10:123 Apr 23 17:03:15 Obi-Wan ntpd[2659]: Listen normally on 61 br0 [fe80::24d8:79ff:fe01:a2fc%9]:123 Apr 23 17:03:15 Obi-Wan ntpd[2659]: new interface(s) found: waking up resolver Diagnostics attached. obi-wan-diagnostics-20190423-0509.zip
  20. Marshalleq
    Did you ever figure out if this was a GPU? I have an issue where my GPU is freezing during a game a lot (for a few seconds (long enough for me to die)) and I have these errors in my log over and over. I'm on 6.7.0 RC7 so the issue has been around a while!
  21. Marshalleq
    Does anyone else work? Would be nice to see how much memory CrashPlan is using - that app is a serious memory hog! Bl**dy Java!
  22. Marshalleq
    Correction, it is now happening as CPU passthrough. Wasn't this morning. Oh well, something new to try and fix!
  23. Marshalleq
    Anyone else noticed this and found a fix? I thought I'd try gaming in an emulated environment so I can use the remaining cores when I don't have Windows on. However the fan noise is prohibitive. Doesn't happen when passing through the CPU to windows rather than emulation. Thanks.
  24. Marshalleq
    For completeness, re-saving using IT87 has now changed to the below. Probably to do with me using my Unraid USB from the 1800x and just chucking it straight not the thread ripper. So it seems tdie is now correctly named as the CPU temp, no idea why it didn't do this on the 1800x, but sure glad it does it on the Threadripper.
  25. Marshalleq
    I see on my thread ripper I actually have a few different options in the drop down list, than I did on the 1800x. According to the link below, tdie is the correct one to look at - so I guess I'll be changing to that! Thanks! https://www.guru3d.com/articles-pages/amd-ryzen-threadripper-2990wx-review,8.html