thrroow

Okay finally figured it out. I had another semi-broken eth port connected that I used as a fallback in the past. For some strange reason during my upgrades, the eth0 switched which mac address it was mapped to. Swapping those in network settings fixed the issue.

Alright. I will break out the compressed air and some more CAT6 cables and keep trying things. The reason I was suspicious this was something else is the switch it is directly connected says 10G (as do lights on both sides of the connection) Also tried it in a different 1Gbps switch and it said negotiated to 1Gbps too (while still 100Mb in UNRAID)

eth0 looks more accurate, thanks. Still doesn't solve the problem. I fear it's something in the BIOS, which has been quite the pain in the past. Settings for eth0: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Auto-negotiation: on Port: Twisted Pair PHYAD: 0 Transceiver: internal MDI-X: Unknown Supports Wake-on: umbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes

Did a small overhaul today and added some more drives and swapped around some SATA connections. Added a PCIe for 4 more SATA ports and removed a 4x1Gb networking card (I wasn't using it for anything). I turn the server back on and start clearing the drives, all is well. No problems at all. I notice web traffic seems slow in/out of the server and check the dashboard -- sure enough it says `eth0100 Mbps, full duplex, mtu 1500`. I thought it was the cable that became unseated but I tried other cables. I also checked my switch via lights & in software and both confirm the link speed is 10Gb. I feel like I am missing something obvious, but I am not sure what else to check. How can the link speed be 10Gb on the hardware, but only show 100Mb in unraid? I have the GA-7PESH2 motherboard and am using the builtin 10Gb Intel networking. Never had this problem until this upgrade. Here's the latest syslog, no mention of failing to negotiate at 1 or 10Gb before this Apr 15 21:52:57 Tower root: Verifying package rclone-2022.01.20-bundle.txz. Apr 15 21:52:57 Tower root: Installing package rclone-2022.01.20-bundle.txz: Apr 15 21:52:57 Tower root: PACKAGE DESCRIPTION: Apr 15 21:52:57 Tower root: Package rclone-2022.01.20-bundle.txz installed. Apr 15 21:52:57 Tower root: plugin: running: anonymous Apr 15 21:52:59 Tower kernel: ixgbe 0000:05:00.0 eth0: NIC Link is Up 100 Mbps, Flow Control: RX/TX Apr 15 21:52:59 Tower kernel: br0: port 1(eth0) entered blocking state Apr 15 21:52:59 Tower kernel: br0: port 1(eth0) entered forwarding state Apr 15 21:53:00 Tower ntpd[1939]: Listen normally on 2 br0 192.168.1.99:123 Apr 15 21:53:00 Tower ntpd[1939]: new interface(s) found: waking up resolver Apr 15 21:53:02 Tower root: Local rclone binary up-to-date ifconfig: br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.99 netmask 255.255.255.0 broadcast 0.0.0.0 ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet) RX packets 3848501 bytes 5309227708 (4.9 GiB) RX errors 0 dropped 939 overruns 0 frame 0 TX packets 1790718 bytes 571169498 (544.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ethtool: ethtool br0 Settings for br0: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Unknown! (255) Auto-negotiation: off Port: Other PHYAD: 0 Transceiver: internal Link detected: yes

I can only get 2 of the 4 ports to pass through to this VM. I have tried with the ACS override on/off, and with multifunction on/off (2 groups of 2 or 4 individual devices). Any ideas? I had no special settings and all 4 devices individually assigned (no multi) to a VM in 6.8.3, but didn't work when I upgraded to 6.9.0-rc1 for some reason. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> IOMMU group 17: [111d:8018] 03:00.0 PCI bridge: Microsemi / PMC / IDT PES12N3A 12-lane 3-Port PCI Express Switch (rev 0e) IOMMU group 18: [111d:8018] 04:02.0 PCI bridge: Microsemi / PMC / IDT PES12N3A 12-lane 3-Port PCI Express Switch (rev 0e) [8086:10d6] 05:00.0 Ethernet controller: Intel Corporation 82575GB Gigabit Network Connection (rev 02) [8086:10d6] 05:00.1 Ethernet controller: Intel Corporation 82575GB Gigabit Network Connection (rev 02) IOMMU group 19: [111d:8018] 04:04.0 PCI bridge: Microsemi / PMC / IDT PES12N3A 12-lane 3-Port PCI Express Switch (rev 0e) [8086:10d6] 06:00.0 Ethernet controller: Intel Corporation 82575GB Gigabit Network Connection (rev 02) [8086:10d6] 06:00.1 Ethernet controller: Intel Corporation 82575GB Gigabit Network Connection (rev 02) -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \ -device vfio-pci,host=0000:05:00.0,id=hostdev0,bus=pci.1,multifunction=on,addr=0x0 \ -device vfio-pci,host=0000:05:00.1,id=hostdev1,bus=pci.1,addr=0x0.0x1 \ -device vfio-pci,host=0000:06:00.0,id=hostdev2,bus=pci.3,addr=0x0 \ -device vfio-pci,host=0000:06:00.1,id=hostdev3,bus=pci.4,addr=0x0.0x1 \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ the above gives me:

I have upgraded to 6.9.0-rc1 and the new Nvidia drivers to keep hardware transcoding. For some reason a certain patch doesn't work, but I don't really need more than several streams at once, so no big deal. However, if I'm transcoding 3 streams, and someone goes to try and use a 4th one, it just constantly buffers / is just a black frame. Is this expected behavior? I would imagine Plex would realize that the card is at the transcode limit and fallback to CPU?

Let me give a short series of events, because this is clearly something that I did. Current setup: 6 disks in array, 1 cache, 1 UD, Nvidia GPU for plex, 4 port NIC for pfSense VM Running out of room on my UD lately, so thought it was time to upgrade. Added a new one, changed the partition names (made the new drive named the same as the old one, after rsync), erased the old one. Everything still fine. Thought it was time to cleanup some other stuff, and change CPU pinnings, among other things. Why not? BTRFS disk corrupted itself around this time. Could have been my fault for resetting it while something was writing though. I changed the CPU pinning for pfSense VM. Updated the config. Couldn't remember if I had to edit the XML after I used to the GUI to update it (because of the passed through NIC). It starts, but VERY slow. No data passing through the internet. Weird. I'll change back to the old CPU assignments. Now start up again, and it gives me the EFI console screen. The "exit, continue" did not work. Tried an older vdisk1.img of pfSense that I had, still same thing. Tried creating a new Seabios VM and using pfSense's vdisk. No disk detected. Went back through old guide and saw that my syslinux.cfg did not have a line that would ignore the NIC on boot, so that it could be passed through. Added that line and rebooted. Kernel panic. Rebooted again, and booted up ("login:") but no web GUI. \\tower is accessable but only shows a share for \flash. At this point I am minorly panicking. It's been probably a year since I've had any sort of problem near this scale. I take the USB out, make a backup onto a laptop. Erase it, put a new unRAID on it, and copy over just the old /config. Exact same issue - no GUI, nothing is booting. I can ping the server just fine, just not http. So, unless my USB drive has completely bricked itself, it has to be something in my /config doing this, right? What are my next troubleshooting steps? tl;dr: messed with some settings, syslinux.cfg, rebooted, console boots normally and pings fine, but no web gui (or anything else)

wow that careless of me. Thanks for the headsup, changed credentials.

I've got a weird problem. After months of running fine and me not touching anything, rtorrent suddently stopped being able to be used by web interface. When I would click anything it would just say error. When I add a torrent it would fail. HOWEVER, sonarr/radarr/etc still could use it fine, so I never bothered fixing it. Now weeks later it won't boot at all. So I deleted the container, used a blank config folder - the only thing I kept is the wireguard folder. Both the old and new containers now just hang on "loading" and never even let me see the GUI. No response from sonarr/radarr. I'm not sure what else to try, I would assume deleting the container and remaking with a whole new data folder should remove almost anything I could have done to it?

It's started and stopped happening to me, at seemingly random intervals.

I believe it is this: Not sure why it would start just now, though

I actually used to have this problem, then it went away for months, now it's back. No significant hardware changes in that time.

When I transfer files to/from the array or use something like bittorrent to download files to the array (or really the cache SSD), between 3 and 5 of my threads will peg out at 100% usage in the unRAID dashboard. Checking top and htop shows that nothing is using that much CPU, however if I look at iotop or Netdata, I am showing very high IOWAIT times. It's like something is bogging down file transfers and it's crashing the entire system. After this goes on for a few seconds, all docker containers become unresponsive, VMs, and even unRAID dashboard. Attached is a picture with all containers and everything shut down except qbittorrent and 1 single torrent. CPU usage hasn't been nearly this high for such a task in the past. I had a similar problem in the last major version of unRAID, but upgrading seemed to have fixed it. It only now randomly re-appeared. Specs: 2x Xeon CPU 64gb memory 2x SSD cache drives in JBOD 9x HDD in array downloads set to save to cache first then get moved at a later date to array

I was in the middle of uploading several screenshots when I saw that the container volume mapping was /data/ (as it had been), but the within qbittorrent the /data/ location had changed to /downloads/. After changing it back to /data and restarting it, it now works! When or how did those settings get changed within qbittorrent? I definitely didn't touch any of those settings.

I misunderstood your question. Yes both those paths are the same in each docker, and I have all identical settings (even ports). I ran one, tried to download, stopped it, started the other, and tried the same download. And again, no paths or settings of any kind have changed in months. Another odd thing I noticed, is that sometimes public trackers work slowly (like RARBG ~400kbps). But trackers that should be faster (iptorrents, xspeeds, ubuntu, etc.) don't work at all. Also tested all of these on both docker containers and on a PC using the same VPN connection. In all cases it's only this particular docker that won't download. I was talking about deleting the container files, e.g., anything pulled down from the docker repository or any container data. Or might that not help?

No, both containers were changed to be exactly the same, including container mounted paths, settings, etc. Also, as others have mentioned, these setups used to work just fine. All of a sudden stopped working even though I haven't even opened up the webUI in months. I just noticed radarr/sonarr downloads were stacking up. Double checked with a manual Ubuntu torrent to make sure it wasn't a tracker or VPN issue. Is there a way to delete all container info etc. so that all of it will be re-downloaded? I can try that too.

I didn't change the folders it was pointing to, however, the other qbitvpn docker I downloaded and tried were also pointed at the same folders with no problems. I also made sure to use the exact same ovpn credential file between the two instances. I get around 40 to 60MB/s on my VPN, so it's definitely not overhead or losses. The one thing I didn't try was to get rid of the torrent backup folder because I'd rather switch clients than stop seeding hundreds of torrents.

Also having the same issues as everyone else with the very slow speeds that soonafter just reach 0kbps. I tried installing the other qbittorrentVPN and copied my appdata and torrents to it - same issues. I then deleted all the config/logs/etc - everything BUT the torrents I was downloading and restarted it. This worked and behaved normally. I tried to copy the same thing to binhex-qbittorrentvpn but it didn't help, still slow speeds with everything else being identical. I guess I'm switching dockers for the time being since they're basically identical, except one works

In terms of featureset, this is my favorite torrent client so far. But after a few minutes of use, it becomes painfully slow. Setup with just a normal config using a VPN (PIA). Saving to download directory which is downloading to a cache drive first. Dual xeon CPU, and never high CPU usage detected. Any troubleshooting ideas?

I don't know exactly when this problem started, but my build and configuration has remained the same for almost 1.5 years. The only thing that's changed recently is I added a pass-through GPU. Unraid 6.7.2 2x Xeon 48gb memory Intel 4 port nic 1050ti 2x SSD, 6x HDD pfsense in VM, no other VMs Every time I use something like qbittorrent, or do anything that reads/writes to the array I get a sharp spike in CPU usage. Sometimes IOWAIT shoots up to 40-50%, which brings everything to a crawl. I can also replicate this issue simply using SMB transfers. Any ideas what this might be or how to fix it without pulling out hardware one by one?

I've had this problem for a long time and asked about it here. A solution for a while was to unplug the card (literally pull it out of the server), and reboot, then put it back in, and reboot again. For some reason this got me booted. I had to reboot recently and the "trick" is no longer working. Does anyone have ANY idea how to troubleshoot this?? This is on a GA-7PESH2 Here is a picture of the Kernel panic

Problem is back on 6.6.6. It was good while it lasted.

Oh wow 6.6.7 is the only one that has this issue. Guess I'll still to previous versions, thanks.

In the thread you sent: Might as well give it a try. But other than trying different versions I'm not sure what else to do. Two different cards tried in 4 different slots, all with the same results.

I've tried the "root=sda" with no success, but I haven't tried any other versions. I suppose that's a next best step?