OrneryTaurus

Hey there. Can you tell me what model and VBIOS version you got on that Tesla P4 card? I recently picked one up and it isn't working. Thinking it might be a situation tied to certain VBIOS versions working and others being patched.

Hey there. I have the same card you're wanting to upgrade to. You'll need to change out your cables. The LSI 9211-8i uses Mini SAS SFF-8087 while the LSI 9305-24i uses Mini SAS HD SFF-8643 cables for connecting to the HBA. You won't lose your array setup, but it's always a good idea to take a screenshot of the drive layout and a backup of your USB prior to upgrading.

Hey everyone, I have a weird issue happen that I can use some guidance on. Starting today, I have been unable to access the unRAID web interface. First it was only my main computer but seems to have expanded to all computers on the same network and subnet. I am able to access my shares via SMB, and all dockers are operational. The only thing I can't access is the web interface and ssh. The web interface seems to give a 302 error when I curl it. All browsers are affected to where it just spins and times out when trying to access. When I try to SSH, I get the following error: 'Couldn't agree a host key algorithm' I'm able to use my server's IPMI to access to command line which is how I pulled the diagnostics. I killed the ngnix service and started it. No change, no error with the configuration file either. I don't use the unraid ssl setup either. EDIT: Looks like BinHex's Deluge VPN docker container was causing a conflict somehow. Soon as I manually stopped it, the WebGUI was restored. smalls-diagnostics-20230429-1805.zip

Others in google searches have reported this card as not being compatible even with the PCIe bifurcation settings being available. You can try and make sure it's updated to the latest BIOS and see if that helps. If it doesn't, you can obtain a card like this: https://www.newegg.com/p/17Z-000F-002P9 which has it's own chip to handle the splitting.

Working great now, thank you!

Sounds like a plan, thanks!

Greetings! I tried to do a little forum searching but came up empty. I know there was an account upgrade performed today so the troubleshooting performed below was part of it. I went through and enabled MFA on my account and noticed my server was reporting offline. I attempted to login to the plugin with the correct credentials and it wouldn't work. I then signed out of the My Servers Plugin and uninstalled / reinstalled. Now, when I attempt to login on the plugin, it recognizes I'm authenticated but because I changed my email address at one point, it states it is registered to another email. Here is the error: Error: {"message":"Request failed with status code 406","data":{"error":"GUID already registered to another email (not matching [REDACTED])"}} I thought the My Servers Plugin was supposed to be registered to accounts and not emails? Any help would be appreciated Thanks!

It is my understanding that when a GPU is used with a VM, it gets exclusive usage of that GPU when active so neither docker containers or another VM can utilize it. When it comes to docker containers, a GPU can be used across multiple containers at the same time but that GPU is exclusive to docker containers when running. Awesome! Glad you were able to resolve the issue.

Do you have both your Crab and your Windows 11 VM running at the same time? Generally it's 1 GPU per VM but you can share 1 GPU amongst many Docker Containers. Additionally, you can't have a VM using a GPU when Docker Containers are using it and vise versa.

Perhaps this can help:

Hello unRAID community! I recently upgraded hardware and just ran into an issue last night where the server was unresponsive to ping. Upon further investigation of the syslog, it shows the following: Aug 23 02:18:51 Smalls kernel: ixgbe 0000:04:00.1: Adapter removed Aug 23 02:18:51 Smalls kernel: ixgbe 0000:04:00.1: Warning firmware error detected FWSM: 0xFFFFFFFF Aug 23 02:18:53 Smalls kernel: ixgbe 0000:04:00.0: Adapter removed Aug 23 02:18:53 Smalls kernel: ixgbe 0000:04:00.0: Warning firmware error detected FWSM: 0xFFFFFFFF I searched the forums before and noticed this has come up in past unraid versions so I ran the command suggested to find out what the firmware version is and here is the output from that. ethtool -i eth0 driver: ixgbe version: 5.15.46-Unraid firmware-version: 0x800003e2 expansion-rom-version: bus-info: 0000:04:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes ethtool -i eth1 driver: ixgbe version: 5.15.46-Unraid firmware-version: 0x800003e2 expansion-rom-version: bus-info: 0000:04:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes I have Dual LAN with Intel® X540 10GBase-T Ethernet Controller onboard according to the motherboard manufacturer (server information available in my signature if needed). Not sure what I need to do here to resolve this from occuring again. I've attached the logs that were captured prior to the shutdown (thanks to unRAID auto capturing upon shutdown). I know the firmware is pulled from https://sourceforge.net/projects/e1000/files/ixgbe stable/ which I see the most recent update is 2022-08-02 but given this is unRAID, I'm not sure if it would cause problems. Appreciate anyone taking the time to look at this Edit: I've since submitted a bug report for this issue in the bug report section. Hopefully it can get resolved smalls-diagnostics-20220823-0931.zip

Interesting! I'll definitely consider this. I think my case might have something I can tie down to.

Thanks! I like having my USB internally as well. Just prepping for potential issues with the internal USB 3.0 plug lol Update: No issues with the USB 3.0 port on the motherboard so far! - 08/18/2022

Thanks for the suggestion! I'm upgrading to a Supermicro X10DRi-T, I'll give the USB 3.0 plug a shot. If the USB doesn't like it, I'll look into something like this!

My forum search fu seems to escape me today. I'm about to upgrade my hardware and noticed the new motherboard only has a USB 3.0 port instead of a USB 2.0 port like the previous one. I have a USB 2.0 header I can plug in to, and was wondering if someone has done something similar. I'd like to avoid plugging in to this header using a cable if possible. I see Amazon has this: https://www.amazon.com/Cablecc-Motherboard-Female-Adapter-Vertical/dp/B07YD444GC/ which is what I would be going for (only need a single port though). I was wondering if someone is already using something similar without issues that they can recommend. Thanks in advance!

I had the same thing happen when I went from 6.10.1 to 6.10.3 - The nvidia plugin had to be deleted and re-installed. once that was done, I would get this error. An extra reboot (likely so the NVidia driver can load properly) fixed it and I was able to re-add the Plex docker container from the old template.

Thanks @JorgeB I will take a look at doing that the first chance I get

Greetings everyone! A while ago I posted about my server becoming unresponsive and at the time I was unable to capture diagnostics logs. Today it became unresponsive and I was able to capture logs via SSH. Reviewing the syslog, it seems a page fault of some sort happened shortly before I was unable to access things. The weird part was the WebGUI was inaccessible except for the Main tab (some of it would load but not the full page towards the bottom). Also, all dockers were running just fine. I did attempt to remove the primary network connection after the inaccessibility happened to determine if there was a fault with the primary. This did not resolve the issue. Any insight as to what the fault might mean? No changes have been made to the system except updating dockers. Here is the issue I have identified from the syslog: May 24 14:19:18 Smalls kernel: BUG: unable to handle page fault for address: fffff8efd25da188 May 24 14:19:18 Smalls kernel: #PF: supervisor read access in kernel mode May 24 14:19:18 Smalls kernel: #PF: error_code(0x0000) - not-present page May 24 14:19:18 Smalls kernel: PGD 0 P4D 0 May 24 14:19:18 Smalls kernel: Oops: 0000 [#1] SMP PTI May 24 14:19:18 Smalls kernel: CPU: 19 PID: 41800 Comm: node Tainted: P W O 5.10.28-Unraid #1 May 24 14:19:18 Smalls kernel: Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 3.4 06/30/2020 May 24 14:19:18 Smalls kernel: RIP: 0010:compound_head+0x0/0x11 May 24 14:19:18 Smalls kernel: Code: 89 06 31 c0 c3 48 8b 17 b8 01 00 00 00 48 f7 c2 9f ff ff ff 74 13 48 b8 98 0f 00 00 00 00 f0 7f 48 85 c2 0f 95 c0 0f b6 c0 c3 <48> 8b 57 08 48 89 f8 f6 c2 01 74 04 48 8d 42 ff c3 e8 ea ff ff ff May 24 14:19:18 Smalls kernel: RSP: 0018:ffffc9000c41fca0 EFLAGS: 00010282 May 24 14:19:18 Smalls kernel: RAX: 0000000000000001 RBX: 00001a1efab1c000 RCX: 0000000000000014 May 24 14:19:18 Smalls kernel: RDX: 0000003bbf497686 RSI: ffffea00612d77c0 RDI: fffff8efd25da180 May 24 14:19:18 Smalls kernel: RBP: ffffc9000c41fdd8 R08: fffff8efd25da180 R09: 7c00003bbf497686 May 24 14:19:18 Smalls kernel: R10: ffffffffffffffff R11: 000000000000000c R12: ffff88816d12f2e8 May 24 14:19:18 Smalls kernel: R13: 000fffe7b4a20162 R14: ffff8881227efc80 R15: ffff8892884213d8 May 24 14:19:18 Smalls kernel: FS: 00001539a27beb38(0000) GS:ffff88a03f9c0000(0000) knlGS:0000000000000000 May 24 14:19:18 Smalls kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 24 14:19:18 Smalls kernel: CR2: fffff8efd25da188 CR3: 000000119b2da002 CR4: 00000000001706e0 May 24 14:19:18 Smalls kernel: Call Trace: May 24 14:19:18 Smalls kernel: migration_entry_to_page+0x19/0x2e May 24 14:19:18 Smalls kernel: unmap_page_range+0x440/0x648 May 24 14:19:18 Smalls kernel: unmap_vmas+0x6c/0x9a May 24 14:19:18 Smalls kernel: ? lru_add_drain_cpu+0x23/0xf8 May 24 14:19:18 Smalls kernel: unmap_region+0xad/0x105 May 24 14:19:18 Smalls kernel: __do_munmap+0x27b/0x2f4 May 24 14:19:18 Smalls kernel: __vm_munmap+0x70/0xb0 May 24 14:19:18 Smalls kernel: __x64_sys_munmap+0x12/0x15 May 24 14:19:18 Smalls kernel: do_syscall_64+0x5d/0x6a May 24 14:19:18 Smalls kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 May 24 14:19:18 Smalls kernel: RIP: 0033:0x1539a36135a0 May 24 14:19:18 Smalls kernel: Code: 00 00 00 0f 05 48 89 c7 e8 8a 87 fe ff 5a c3 55 48 89 f5 53 48 89 fb 50 e8 85 ed 01 00 b8 0b 00 00 00 48 89 df 48 89 ee 0f 05 <48> 89 c7 e8 65 87 fe ff 5a 5b 5d c3 31 c0 83 fa 04 74 0c 48 63 d2 May 24 14:19:18 Smalls kernel: RSP: 002b:00001539a27be840 EFLAGS: 00000246 ORIG_RAX: 000000000000000b May 24 14:19:18 Smalls kernel: RAX: ffffffffffffffda RBX: 00001a1efab00000 RCX: 00001539a36135a0 May 24 14:19:18 Smalls kernel: RDX: 0000000000000000 RSI: 0000000000040000 RDI: 00001a1efab00000 May 24 14:19:18 Smalls kernel: RBP: 0000000000040000 R08: 0000153999e1db10 R09: 0000153999e1da50 May 24 14:19:18 Smalls kernel: R10: 0000000000000013 R11: 0000000000000246 R12: 00001a1efab00000 May 24 14:19:18 Smalls kernel: R13: 00001539a27be980 R14: 00001539a27be890 R15: 0000000000000000 May 24 14:19:18 Smalls kernel: Modules linked in: xt_mark nvidia_uvm(PO) xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle nf_tables vhost_net tun vhost vhost_iotlb tap xt_nat xt_tcpudp macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(PO) drm backlight agpgart ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding ixgbe mdio igb i2c_algo_bit sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm mxm_wmi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd ipmi_ssif glue_helper mpt3sas isci rapl libsas i2c_i801 raid_class intel_cstate intel_uncore nvme ahci scsi_transport_sas input_leds i2c_smbus nvme_core i2c_core libahci led_class wmi acpi_ipmi ipmi_si button [last unloaded: mdio] May 24 14:19:18 Smalls kernel: CR2: fffff8efd25da188 May 24 14:19:18 Smalls kernel: ---[ end trace ec73c4b0205b2e16 ]--- May 24 14:19:18 Smalls kernel: RIP: 0010:compound_head+0x0/0x11 May 24 14:19:18 Smalls kernel: Code: 89 06 31 c0 c3 48 8b 17 b8 01 00 00 00 48 f7 c2 9f ff ff ff 74 13 48 b8 98 0f 00 00 00 00 f0 7f 48 85 c2 0f 95 c0 0f b6 c0 c3 <48> 8b 57 08 48 89 f8 f6 c2 01 74 04 48 8d 42 ff c3 e8 ea ff ff ff May 24 14:19:18 Smalls kernel: RSP: 0018:ffffc9000c41fca0 EFLAGS: 00010282 May 24 14:19:18 Smalls kernel: RAX: 0000000000000001 RBX: 00001a1efab1c000 RCX: 0000000000000014 May 24 14:19:18 Smalls kernel: RDX: 0000003bbf497686 RSI: ffffea00612d77c0 RDI: fffff8efd25da180 May 24 14:19:18 Smalls kernel: RBP: ffffc9000c41fdd8 R08: fffff8efd25da180 R09: 7c00003bbf497686 May 24 14:19:18 Smalls kernel: R10: ffffffffffffffff R11: 000000000000000c R12: ffff88816d12f2e8 May 24 14:19:18 Smalls kernel: R13: 000fffe7b4a20162 R14: ffff8881227efc80 R15: ffff8892884213d8 May 24 14:19:18 Smalls kernel: FS: 00001539a27beb38(0000) GS:ffff88a03f9c0000(0000) knlGS:0000000000000000 May 24 14:19:18 Smalls kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 24 14:19:18 Smalls kernel: CR2: fffff8efd25da188 CR3: 000000119b2da002 CR4: 00000000001706e0 Any insight would be appreciated. Thank you Per the recommendation of the 'Need Help? Read Me First' post, I will be upgrading to unRAID v6.10.1 to see if that might fix it but was curious as to the page fault meaning for this specific issue. smalls-diagnostics-20220524-1557.zip

Of course it would be that simple lol. Totally overlooked that when scrambling. Thanks! I'll keep this in mind for what (hopefully) won't be a next time.

This morning was an interesting event. My server has been running flawlessly for months and then this morning I wake up to see my server can't be accessed via IP. I go into the console and I'm able to login. I had to get the server up and running so I pulled the syslog real quick and had to manually reboot (shutdown command hung). In the syslog, I see that there are several entries for stalls Apr 22 08:57:38 Smalls kernel: rcu: INFO: rcu_sched self-detected stall on CPU Apr 22 08:57:38 Smalls kernel: rcu: 16-....: (59999 ticks this GP) idle=b76/1/0x4000000000000000 softirq=103787593/103787593 fqs=14982 Apr 22 08:57:38 Smalls kernel: (t=60000 jiffies g=840289921 q=130361) Apr 22 08:57:38 Smalls kernel: NMI backtrace for cpu 16 The most recent changes made to this system are: 1) Installation of a PiHole docker container 2) Moving the DAC from one port to the other on the 10 gig network card yesterday (was working fine all day afterwards) 3) Removed the PiHole docker container this morning after the reboot since I was no longer using it Diagnostics were pulled after the reboot. Unfortunately I couldn't find the command line to run for diagnostics before I had to get the server back up. I guess my question is, if this happens again: 1) What is the command line to pull and anonymize diagnostics? 2) With the syslog being pulled before reboot, is there anyone who might know what the issue might be? Thanks in advance! syslog smalls-diagnostics-20220422-1125.zip

It did work as expected

Greetings everyone! I'm itching to upgrade my server in some way but can't decide which path would be ideal and provide the most benefit. My current server is being used primarily for plex, nextcloud + database, VMs, and a web host Here is my current server setup: OS unRAID 6.9.2 Pro FLASH Sandisk Cruzer Fit 16GB CASE Norco RPC-4220 PSU Corsair RM1000i 80+ GOLD MOTHERBOARD Supermicro X9DR3-F [BIOS v3.4/BMI v3.62] MEMORY IBM [Micron] 128GB PC3-12800 [DDR3 1600Mhz] ECC CPU Intel Xeon E5-2697 v2 [x2] | GPU nVidia Quadro P2000 HBA CARDS LSI 9201-16i / LSI 9240-8i EXP CARD ASUS Hyper M.2 V2 PARITY 14TB [x2] DATA 216TB [3x 10TB | 5x 12TB | 9x 14TB] SWAP 10TB CACHE POOLS Samsung EVO 970 Plus NVMe 500GB [x2] | Samsung EVO 980 NVMe 1TB [x2] The ideas I had for upgrading were: A) Purchase an LSI Logic Controller Card 9305-24i card along with cables. The thought process behind this is to reduce my dual HBA card setup into one card, reducing PCIe slot usage and boot times B) Update the CPU, Motherboard, and Memory to a newer architecture standard. My CPUs currently have a combined passmark of 23349 and I'd like to stay above that even if it means reducing down to a single CPU. I still need to maintain at least 4 PCIe slots (2 16x 2 8x) unless I upgrade to the card mentioned in option A, then it's 3 PCIe (2 16x 1 8x) with pcie bifurcation for ASUS Hyper M.2 V2 card compatibility. C) Upgrade the PSU to something that is better suited to handle 20 hard drives powered by PATA on the backplane. D) Upgrade the case to something that has more than 20 hard drives for additional storage space. Due to the video card and current LSI 9201-16i card I have, the case would need to be full sized for the PCIe slots (RIP the 36-bay supermicro dream, for now) Open to suggestions on which route (or routes) to take, or any additional upgrade suggestions to consider. Thanks for reading!

Awesome. Revised the steps: 1 ) Stop the array 2 ) Shutdown the system 3 ) Add the two new NVMe drives 4 ) Power on the system 5 ) Start the array 6 ) Format the two new 1TB NVMe drives using Unassigned Devices ---- Allows for a partition to be created, used in step 7 7 ) From a command line, type: btrfs replace start -f /dev/nvme0n1p1 /dev/nvme3n1p1 /mnt/cache ---- Old drive to new drive, p1 references the partition used 8 ) Monitor the replacement status by running btrfs replace status /mnt/cache from the command line 9 ) Repeat steps 7 and 8 for the second drive, targeting the other 500GB NVMe drive 10 ) Stop the array 11 ) Disable Docker service 12 ) Disable VM service 13 ) Unassign both cache drives from the cache pool 14 ) Start the array 15 ) Stop the array 16 ) Add each cache drive back into the pool (position doesn't matter, preference only) 17 ) Verify the "All existing data on this device will be OVERWRITTEN when array is Started" is NOT present 18 ) Start the array 19 ) Stop the array 20 ) Re-enable Docker service 21 ) Re-enable VM service 22 ) Start the array Optional 23 ) Stop the array 24 ) Shutdown the system 25 ) Remove the old cache drives 26 ) Power on the system 27 ) Start the array Thanks so much @JorgeB I'll give this a go in the next few days. I appreciate your time!

Awesome, thank you for that. Let me write my steps down that I will follow to make sure I understand the process laid out. I will be replacing 2 500GB NVMe drives with 2 1TB NVMe drives. 1 ) Stop the array 2 ) Shutdown the system 3 ) Add the two new NVMe drives 4 ) Power on the system 5 ) Start the array 6 ) Format the two new 1TB NVMe drives using Unassigned Devices ---- You mention any file system, assuming the btrfs replace command re-formats the drive. 7 ) From a command line, type: btrfs replace start -f /dev/NewNVMe1 /dev/OldNVMe1 /mnt/cache ---- This takes the new 1TB NVMe drive and replaces the target 500GB NVMe drive 8 ) Monitor the replacement status by running btrfs replace status /mnt/cache from the command line 9 ) Repeat steps 7 and 8 for the second drive, targeting the other 500GB NVMe drive 10 ) Stop the array 11 ) Disable Docker service 12 ) Disable VM service 13 ) Remove both cache drives from the cache pool 14 ) Start the array 15 ) Stop the array 16 ) Add each cache drive in the same position they were in based on cache drive replaced 17 ) Verify the "All existing data on this device will be OVERWRITTEN when array is Started" is NOT present 18 ) Start the array Step 16/17 is where I got a little confused reading the steps within the bug report, which prompted this forum post. My initial question in my head was "What's different about cache drives that allows you to completely 'forget' the pool and set it back up again?" Looking at the complete steps, I'm assuming that the pool configuration is kept regardless if it is set in unRAID?